最大化 AIX 上的 Java 性能，第 3 部分: 更多就是更好

核心提示： 堆回收如果应用程序生成大量的临时对象，如果可以设置足够小的堆，最大化 AIX 上的 Java 性能，第 3 部分: 更多就是更好(6)，则技巧 MEM001 将会很有帮助，其基本思路在于，请参见技巧 MEM007，您可能还希望尝试一下技巧 MEM001，如果堆增长到 200 MB 后触发一

堆回收

如果应用程序生成大量的临时对象，如果可以设置足够小的堆，则技巧 MEM001 将会很有帮助。其基本思路在于，如果堆增长到 200 MB 后触发一个 200 毫秒的 GC 周期，而不是增长到 1 GB 后触发一个 1500 毫秒的 GC 周期，则使用较小的堆效果会好得多，因为应用程序无论如何都不需要较大的内存占用空间。这当然是假设最大的堆大小始终满足用于长期分配所需的堆空间量。此技巧与 第 2 部分的技巧 CPU012 相同，但现在是集中于应用程序的内存占用空间，而不只是集中于应用程序的性能。

即使分配相当迅速，固定大小的堆通常也工作得很好。但是如果这些临时对象的大小通常相当大，则堆会很快变得零碎，从而导致假性 OOM。不适合使用技巧 MEM001 的另一个场景是固定 (Pinned) 对象正在导致碎片的情况。如果必须将对象固定在堆中，则将它们分配在堆中尽可能低的位置是有帮助的。但是除非非做不可，否则 Java 不会收集垃圾，因此只要有堆可用，就不会触发任何 GC 周期，并且这会转化为以导致碎片的方式分配固定对象。

较新版本的 Java 能够执行更好的碎片管理，并且可以使用新的开关来调整固定集群的大小（请参见 -Xk 和 –Xp）。但是如果您遇到堆碎片，技巧 MEM002 也许能满足您的所有需要。在许多情况下，堆扩展和收缩能够比压缩周期更好地消除堆中的空隙。堆碎片会严重影响应用程序的可伸缩性，技巧 MEM002 是在这些情况下使用的理想调整。

GC 活动

下面是基于 verbosegc 输出的简单指示信息。有关更多详细信息，请参阅“Fine-tuning Java Garbage Collection Performance”。

如果您在使用技巧 MEM002，并且在应用程序稳定时观察到太多的 GC，请参见技巧 MEM007。您可能还希望尝试一下技巧 MEM001，并确定它是否有帮助。