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

核心提示： 如果阅读过文章“Getting more memory in AIX for your Java applications”，您应该能够判断出上述配置是使用 LDR_CNTRL=MAXDATA=0x40000000，最大化 AIX 上的 Java 性能，第 3 部分

如果阅读过文章“Getting more memory in AIX for your Java applications”，您应该能够判断出上述配置是使用 LDR_CNTRL=MAXDATA=0x40000000。“Inuse”列中显示 4K 页的值，因此一个段（大小为 256 MB）在此列中的最大值将为 65536。正如上述输出所示，这个特定的应用程序在使用大量的本机堆；没有为段 3-5 打印范围的原因在于，尽管“Inuse”计数不是 65536，但是该段已经完全分配了。此外，如果没有使用 -r，可以认为既然段 6 的“Inuse”值为 37070，则该段只有 56% 的使用率。但是可以判断出，段 6 正在使用的实际地址范围是 0 到 50453，或换句话说该段差不多达到 77% 的使用率。这会对应用程序的大小调整具有重要的影响。

要注意的另一个有趣部分在于，通过 svmon 无法看到 Java 堆碎片。段 7 至 A 看起来已完全利用（对应 SID 的“Inuse”值为 65536），而段 B 正在使用前 45056 个页面。这只是告诉了您该堆的大小约为 1100 MB，但是还存在找到此信息的更容易方法（即查看 Java 的命令行参数！）。

特定于 Java 的技巧

Fine-tuning Java Garbage Collection Performance 介绍了 Java 堆的优化。在 1.4 以前的 Java 版本上，您可能需要调整某些环境设置才能使用超出 1 GB 的堆，“Getting more memory in AIX for your Java applications”对此进行了解释。

如果您了解 verbosegc 输出的各项意义，以及如何使用 svmon，对于 AIX 上的任何 Java 应用程序的大多数性能监视工作应该足够了。

存在若干有关 GC 优化的文章可以使用，因此基于您希望了解此主题的深度，您可以使用大量的信息。Diagnostics 页还指向一个总结 IBM Java 的 GC 是如何工作的文档，对于开发人员来说这应该特别有用。下面几个部分将坚持使用基于特征的优化方式，但是如果您希望更进一步研究任何特定的技巧，应该参考“IBM Garbage Collection and Memory Allocation techniques”一文，您可以从 http://www-106.ibm.com/developerworks/java/jdk/diagnosis/ 访问它。