确定生产系统合适的Java堆大小不是一件容易的事。 在我的Java EE企业经验中，我发现由于Java堆容量和调整不足而导致的多个性能问题。

本文将为您提供5个技巧，这些技巧可以帮助您确定当前或新生产环境的最佳Java堆大小。 这些技巧中的一些对于预防和解决java.lang.OutOfMemoryError问题也非常有用。 包括内存泄漏。

请注意，这些技巧旨在“帮助您”确定适当的Java堆大小。 由于每个IT环境都是唯一的，因此您实际上处于最佳位置，可以精确地确定客户端环境所需的Java Heap规范。 其中一些技巧可能也不适用于非常小的Java独立应用程序，但是我仍然建议您阅读整篇文章。
未来的文章将包含有关如何为您的环境和应用程序选择正确的Java VM垃圾收集器类型的提示。

＃1 – JVM：您总是担心自己不了解的内容

您如何期望对您不了解的内容进行配置，调整和故障排除？ 您可能永远没有机会编写和改进Java VM规范，但是您仍然可以自由学习它的基础，以提高您的知识和故障排除技能。 有些人可能会不同意，但是从我的角度来看，认为Java程序员不需要了解内部JVM内存管理的想法是一种幻想。

对于Java和Java EE初学者来说，Java Heap调优和故障排除尤其是一项挑战。 在以下典型情况下查找：

–您的客户端生产环境经常面临OutOfMemoryError并造成大量业务影响。 您的支持团队承受着解决此问题的压力
–通过Google的快速搜索，您可以找到类似问题的示例，现在您认为（并假设）自己面临相同的问题
–然后抓取JVM -Xms和 -Xmx值来自另一个人的OutOfMemoryError问题案例，希望能快速解决客户的问题 –然后，继续对您的环境实施相同的调整。 2天后，您意识到问题仍在发生（甚至更糟或稍好一点）……斗争仍在继续……

什么地方出了错？

–您首先没有正确了解问题的根本原因
–您可能还没有从更深层次上正确地了解您的生产环境（规格，负载情况等）。 网络搜索是学习和共享知识的好方法，但您必须执行自己的尽职调查和根本原因分析 –您可能还缺少一些有关JVM及其内部内存管理的基本知识，从而使您无法将所有点连接在一起

我给您的＃1技巧和建议是学习和理解JVM的基本原理及其不同的内存空间。 这些知识很关键，因为它将使您能够向客户提出有效建议，并正确理解与将来的调整注意事项相关的可能影响和风险。 现在，在下面找到有关Java VM的快速高级参考指南：

Java VM内存最多分为3个内存空间：

• Java堆 。 适用于所有JVM供应商，通常在YoungGen（苗圃）和OldGen（租用）空间之间划分。
• PermGen （永久代）。 仅适用于Sun HotSpot VM（PermGen空间将在以后的Java 7或Java 8更新中删除 ）
• 本机堆 （C-Heap）。 适用于所有JVM供应商。

我建议您阅读以下每篇文章，包括有关HotSpot Java内存管理的Sun白皮书。 我也鼓励您下载并查看OpenJDK实现。

## Sun HotSpot VM http://javaeesupportpatterns.blogspot.com/2011/08/java-heap-space-hotspot-vm.html

## IBM VM http://javaeesupportpatterns.blogspot.com/2012/02/java-heap-space-ibm-vm.html

## Oracle JRockit VM http://javaeesupportpatterns.blogspot.com/2012/02/java-heap-space-jrockit-
vm.html

## Sun（Oracle）– Java内存管理白皮书 http://java.sun.com/j2se/reference/whitepapers/memorymanagement_whitepaper.pdf

## OpenJDK –开源Java实现 http://openjdk.java.net/

如您所见，Java VM内存管理比通过–Xmx设置可能的最大值要复杂得多。 您必须从各个角度考虑问题，包括您的本机和PermGen空间要求以及来自物理主机的物理内存可用性（和CPU内核数量）。

由于Java Heap和本机Heap处于竞争之中，因此对于32位JVM来说，它尤其棘手。 Java堆越大，本机堆越小。 尝试为32位VM（例如.2.5 GB +）设置较大的堆会增加本机OutOfMemoryError的风险，具体取决于您的应用程序占用空间，线程数等。64位JVM解决了此问题，但您仍然限于物理资源可用性和垃圾收集开销（大型GC收集的成本随大小而增加）。 最重要的是，越大并不总是越好，因此请不要假定您可以在单个16 GB 64位JVM进程上运行所有20个Java EE应用程序。

＃2 –数据和应用程序为王：查看您的静态占用空间要求

您的应用程序及其关联数据将指示Java Heap占用空间要求。 静态内存是指“可预测的”内存需求，如下所示。

–确定要计划部署到单个JVM进程的多少个不同的应用程序，例如EAR文件，WAR文件，jar文件的数量。您部署到单个JVM的应用程序越多，对本机堆的需求就越高
–确定在运行时可能会加载多少个Java类； 包括第三方API。 您在运行时加载的类加载器和类越多，对HotSpot VM PermGen空间和与内部JIT相关的优化对象的需求就越高 –确定数据缓存占用空间，例如由应用程序（和第三方API）加载的内部缓存数据结构，例如从数据库缓存的数据，从文件读取的数据等。您使用的数据缓存越多，对Java Heap OldGen的需求就越高空间 –确定允许您的中间件创建的线程数。 这非常重要，因为Java线程需要足够的本机内存，否则将引发OutOfMemoryError。

例如，如果您打算在单个JVM进程上部署10个单独的EAR应用程序，而不是2个或3个，则将需要更多的本机内存和PermGen空间。未序列化到磁盘或数据库的数据缓存将需要从磁盘上获得额外的内存。 OldGen空间。

尝试合理估计静态内存占用量。 在进行真正的测量练习之前，这对于设置一些起点JVM容量数字非常有用（例如，技巧4）。 对于32位JVM，我通常不建议Java Heap大小大于2 GB（-Xms2048m，-Xmx2048m），因为您需要足够的内存用于PermGen，并需要足够的Java EE应用程序和线程本机堆。
此评估尤为重要，因为在单个32位JVM进程中部署的应用程序过多，很容易导致本机堆耗尽。 特别是在多线程环境中。

对于64位JVM，通常建议每个Java进程3 GB或4 GB的Java堆大小。

＃3 –商业流量设定规则：查看您的动态足迹需求

您的业​​务流量通常会决定您的动态内存占用量。 并发用户和请求会生成JVM GC“心跳”，由于频繁创建和废弃短期和长期存在的对象，您可以从各种监视工具中观察到它们。 从上面的JVM图表中可以看到，YoungGen与OldGen的典型比率是1：3或33％。

对于典型的32位JVM，Java Heap大小设置为2 GB（使用分代和并发收集器）通常将为YoungGen空间分配500 MB，为OldGen空间分配1.5 GB。

最小化主要GC收集的频率是获得最佳性能的关键方面，因此，了解并估算峰值量期间需要多少内存非常重要。

同样，您的应用程序和数据类型将决定您需要多少内存。 涉及大型和非序列化会话数据的购物车类型的应用程序（寿命长的对象）通常需要大型Java堆和大量OldGen空间。 无状态和XML处理繁重的应用程序（很多短期对象）需要适当的YoungGen空间，以最大程度地减少主要集合的频率。
例：

–您要部署5个EAR应用程序（约2000个Java类）（还包括中间件代码…）
–您的本机堆需求估计为1 GB（必须足够大以处理线程创建等）–您的PermGen空间估计为512 MB
–内部静态数据缓存估计为500 MB –在高峰时段，您的总预测流量为5000个并发用户 –每个用户会话数据占用量估计为500 K –仅会话数据所需的总占用空间为峰值容量以下的2.5 GB

如您所见，根据这种要求，您不可能将所有这些流量发送到单个JVM 32位进程。 一个典型的解决方案涉及在几个JVM进程和/或物理主机之间分配流量（技巧5）（假设您有足够的可用硬件和CPU内核）。

但是，对于此示例，由于对静态内存的需求很高，并且从长远来看要确保可扩展的环境，我还建议您使用64位VM，但是以较小的Java Heap作为起点，例如3 GB，以最大程度地减少GC成本。 您绝对希望为OldGen空间留出额外的缓冲区，因此我通常建议在大型采集后最多保留50％的内存，以保持Full GC的频率较低，并为故障转移方案提供足够的缓冲区。

在大多数情况下，除非您需要大量的数据缓存以实现适当的性能（这对于门户（媒体）繁重的应用程序是典型的），否则业务流量将占用您的大部分内存。 太多的数据缓存会产生一个黄色标记，您可能需要早于稍后重新访问某些设计元素。

＃4 –不要猜测，要衡量！

此时，您应该：

–了解基本的JVM原理和内存空间
–对所有应用程序及其特征（大小，类型，动态流量，无状态对象与有状态对象，内部内存缓存等）有深入的了解和了解。
–对每个应用程序的业务流量（并发用户数等）以及每个应用程序都具有很好的视图或预测–如果需要是否需要64位VM以及从哪个JVM设置开始，可以有一些想法 –一些想法，如果您需要多个JVM（中间件）进程

但是，等等，您的工作尚未完成。 尽管以上信息至关重要，并且对您提出“最佳猜测” Java Heap设置非常有用，但它始终是最好的，建议您通过适当的性能分析，加载和性能模拟应用程序行为并验证Java Heap内存需求测试。
您可以学习和利用JProfiler之类的工具（未来的文章将包括有关JProfiler的教程）。 从我的角度来看，学习如何使用事件探查器是正确了解应用程序内存占用量的最佳方法。 我用于现有生产环境的另一种方法是使用Eclipse MAT工具进行堆转储分析。 堆转储分析功能非常强大，它使您可以查看和了解Java Heap的整个内存占用量，包括与类加载器相关的数据，并且在任何内存占用量分析中都必须进行此练习。 特别是内存泄漏。

Java分析器和堆转储分析工具使您能够了解和验证应用程序的内存占用量，包括检测和解决内存泄漏。 负载和性能测试也是必须的，因为这将允许您通过模拟预测的并发用户来验证较早的估计。 它还将暴露您的应用程序瓶颈，并允许您进一步微调JVM设置。 您可以使用诸如Apache JMeter之类的工具，这些工具非常易于学习和使用，也可以探索其他商业产品。

最后，我经常看到Java EE环境运行良好，直到基础架构的一部分开始出现故障（例如硬件故障）为止。 突然，环境以减少的容量运行（JVM进程的数量减少），并且整个环境崩溃了。 发生了什么？

有许多情况可能导致多米诺骨牌效应，但是JVM调优和处理故障转移 （短期额外负载）的能力非常普遍。 如果您的JVM进程以80％+的OldGen空间容量运行并且具有频繁的垃圾回收，那么您如何期望处理任何故障转移方案？

前面执行的负载和性能测试练习应该模拟这种情况，并且应该适当地调整调整设置，以便Java Heap有足够的缓冲区来在短期内处理额外的负载（额外的对象）。 这主要适用于动态内存占用量，因为故障转移意味着将一定百分比的并发用户重定向到可用的JVM进程（中间件实例）。

＃5 –分而治之

至此，您已经执行了数十次负载测试迭代。 您知道您的JVM不会泄漏内存。 您的应用程序内存占用空间无法再减少。 您尝试了几种调优策略，例如使用10 GB +的大型64位Java堆空间，多个GC策略，但仍然找不到可接受的性能级别？

根据我的经验，我发现，在当前的JVM规范下，适当的垂直和水平扩展会涉及为每个物理主机以及跨多个主机创建几个JVM进程，从而为您提供所需的吞吐量和容量。 如果将您的应用程序列表分为几个逻辑孤岛（具有各自的JVM进程，线程和调整值），则您的IT环境也将具有更高的容错能力。
这种“分而治之”的策略涉及将您的应用程序流量拆分到多个JVM进程，并将为您提供：

–减少了每个JVM进程的Java堆大小（静态和动态覆盖）
–降低了JVM调整的复杂性
–减少了每个JVM进程的GC经过和暂停时间 –增强的冗余和故障转移功能 –与最新的云和IT虚拟化策略保持一致

最重要的是，当您发现自己花费太多时间来调整单个大象的64位JVM进程时，就该重新审视您的中间件和JVM部署策略并利用纵向和横向扩展优势了。 这种实施策略对硬件的负担更大，但从长远来看确实会有所回报。

请提供任何评论，并分享您对JVM Heap调整大小和调整的经验。

参考： Java EE支持模式和Java教程博客中的JCG合作伙伴 Pierre-Hugues Charbonneau提供了5个有关适当的Java堆大小的技巧 。