最近，我在和一个朋友讨论为什么Java进程使用的内存比启动Java进程时设置的最大堆多。

代码创建的所有Java对象都是在Java堆空间内创建的，其大小由-Xmx选项定义。 但是一个Java进程由很多空间组成，而不仅仅是Java堆空间。 以下是组成Java进程的一些空格：

• 加载的库（包括jar和class文件）
• Java堆的控制结构
• 线程栈
• 生成的（JITed）代码
• 用户本机内存（在JNI中分配）
• … 更多…

在32位体系结构系统中，总进程大小不能超过4GB。 因此，一个32位的Java进程由许多空间（Java堆，本机内存（C-Heap）和其他空间）组成，并且其分配的空间不能超过4GB。

假设在32位生产系统上长时间运行具有-Xmx 1.5 GB（Java堆设置为1.5 GB）的Java应用程序服务器，并且已部署了许多应用程序。 一段时间后，客户希望在同一应用程序服务器上部署更多应用程序。 系统运营商了解，由于服务器将不得不处理更多的请求，因此还需要创建更多的对象并进行更多的处理。 因此，作为将来的解决方案，运营商决定将Java进程的最大堆增加到2 GB。

好的，这看起来是个好方法，但是实际上在此生产应用程序服务器上发生了什么？ （这是真实情况）。 应用程序服务器因OutOfMemoryError崩溃！ 您能考虑一下可能的原因吗？

我的第一个想法是2 GB的内存不足以支持所有这些应用程序。 不幸的是，问题出在别的地方。 您现在怎么看？ 我会帮你一点。

java.lang.OutOfMemoryError: requested 55106896 bytes for Chunk::new.

真正的原因是，对于本机（C-Heap）内存，需要已部署的（旧）应用程序太大。 在操作员增加堆大小（从1.5GB到2 GB）之前，他们没有监视旧应用程序所需的本机内存空间。 此操作的副作用是自动将Java进程本机内存的可用最大大小从2.5 GB减小到2GB。 由于旧的应用程序已经使用了如此大的本机内存，因此此更改会使服务器崩溃 ！！！

在这种情况下，唯一可以接受的解决方案是避免增加最大堆大小，部署新应用程序并减少吞吐量。 这不是一个完美的解决方案，但这是在这种情况下唯一可行的解​​决方案（因为我们的Java进程必须为32位）。

特别是在32位系统中，在增加Java堆大小之前，请注意Java进程本机内存的所需大小。 如果您处于这两个空间冲突的情况，那么解决方案可能并非如此简单。 如果您不能更改代码来克服这种情况，那么最常见的解决方案是移至最大进程大小限制太大的64位系统。

有四件事要记住：

• 进程大小的最大限制
• Java进程的大小不仅由Java堆组成
• 无法明确配置Java进程的本机（C-Heap）内存的大小，因为Java堆空间可以实现
• 应用程序所需的Java堆空间和本机（C堆）内存空间的大小仅由应用程序定义，并且这两个空间之间没有任何标准比率

参考：来自 Java的JCG合作伙伴 Adrianos Dadis的Java堆空间，本机堆和内存问题 ，集成和源博客的优点 。

翻译自: https://www.javacodegeeks.com/2013/01/java-heap-space-native-heap-and-memory-problems.html