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

核心提示： 基于特征的优化技巧下面我们将看一下典型应用程序的不同特征，您应该定位到与您的应用程序类似的行为（无论是设计上的还是观察到的），最大化 AIX 上的 Java 性能，第 3 部分: 更多就是更好(5)，并应用对应的技巧，除非明确指明，由于堆需求的增长而紧跟着进行堆扩展，在此情况下，否则术语&

基于特征的优化技巧

下面我们将看一下典型应用程序的不同特征。您应该定位到与您的应用程序类似的行为（无论是设计上的还是观察到的），并应用对应的技巧。除非明确指明，否则术语“堆”是指 Java 堆。

堆使用情况

对于大多数应用程序，使用固定与可变堆的决定是很容易做出的。任何具有或多或少的有限堆要求的应用程序都可以使用 技巧 MEM001，而任何会定期猛增堆使用量的应用程序使用技巧 MEM002 效果会更好。但是，如果应用程序逐渐地增长，或者如果您在考虑由于可变堆大小而导致的性能影响，则技巧 MEM001 也许仍然是可行的。位于 IBM developer kits - diagnosis documentation 的诊断指南包括一个有关如何调整 Java 堆大小的不错的内容。正如“Fine-tuning Java Garbage Collection Performance”所提到的，要遵循的规则是：分配应用程序需要的堆大小，但是决不多分配。但是在决定使用技巧 MEM001 之前，请参阅有关“堆回收”的部分。

堆增长速度

如果应用程序堆需要迅速增长，则技巧 MEM003 将会非常有用。能从快速内存增长中获益的应用程序类型是在工作日的特定时间具有内存需求高峰的应用程序。如果优化得当，堆扩展次数将会减少，因为每次扩展会将堆增长更大的量。

另一方面，如果希望控制堆增长速度，请参见技巧 MEM004。当您看到堆扩展相当大并且希望控制扩展增量时，这是非常有用的。此类情况非常罕见，因为 Java 通常会基于定义良好的规则来扩展堆，除非您首先使用技巧 MEM003，否则堆不会快速增长。不过在需要时使用技巧 MEM004 还是有用的。

如果应用程序堆只应该增长而决不会收缩，可以使用 技巧 MEM005 来强制实现此目的。GC 周期不断监视堆使用情况，并在看到分配的堆大于当前需求时收缩堆。毕竟，这就是使用可变大小的堆的本意。但是有时，您可能注意到在堆收缩后，由于堆需求的增长而紧跟着进行堆扩展。在此情况下，您可以要求 JVM 不要收缩堆。