最大化 AIX 上的 Java 性能，第 4 部分: 监视流量

核心提示： 此工具在前面引用的参考资料中作了介绍，更详细的研究超出了本文的范围，最大化 AIX 上的 Java 性能，第 4 部分: 监视流量(7)，特定于 Java 的技巧用于避免 I/O 和网络瓶颈的 Java 通用技巧归根结底是良好的设计，并且已经在多个地方做了清楚的文档说明， RMI 应用程序

此工具在前面引用的参考资料中作了介绍，更详细的研究超出了本文的范围。

特定于 Java 的技巧

用于避免 I/O 和网络瓶颈的 Java 通用技巧归根结底是良好的设计，并且已经在多个地方做了清楚的文档说明。不过还是看一下技巧 NI004 和技巧 NI005。

基于特征的优化技巧

下面让我们看一下典型应用程序的不同特征。您应该定位到与您的应用程序类似的行为（无论是设计上的还是观察到的），并应用对应的技巧。

网络密集型应用程序

对于网络密集型应用程序，您应该使用 netstat 来确保不存在丢弃的数据包等情况。AIX 5L Performance Tools Handbook 中的 netstat 和 netpmon 部分描述了在监视期间观察到故障时可执行的各种调整，因此这里就不再重复了。

如果怀疑网络吞吐量是瓶颈，技巧 NI001 对于确定是否存在问题会非常有用。此外，如果根本不使用 IPv6，也可以使用技巧 NI002。

如果您在考虑 AIX 和其他平台之间的应用程序性能差异，并且怀疑这种差异是由于所设置的套接字选项导致的，您可以查看一下技巧 NI004。

RMI 应用程序

如果应用程序是 RMI 客户机或服务器，您可能观察到 verbosegc 输出中有一些未做出说明的行。例如，下面的内容摘自某个 RMI 应用程序的 verbosegc 输出：

<GC(4057): GC cycle started Thu Apr 15 11:14:28 2004
<GC(4057): freed 254510616 bytes, 55% free (453352000/810154496), in 1189 ms>
　<GC(4057): mark: 991 ms, sweep: 198 ms, compact: 0 ms>
　<GC(4057): refs: soft 0 (age >= 32), weak 2, final 330, phantom 0>
<GC(4057): stop threads time: 10, start threads time: 260>
<GC(4058): GC cycle started Thu Apr 15 11:15:29 2004
<GC(4058): freed 267996504 bytes, 56% free (454445800/810154496), in 1243 ms>
　<GC(4058): mark: 1041 ms, sweep: 202 ms, compact: 0 ms>
　<GC(4058): refs: soft 0 (age >= 32), weak 0, final 253, phantom 0>
<GC(4059): GC cycle started Thu Apr 15 11:16:31 2004
<GC(4059): freed 248113752 bytes, 56% free (455754152/810154496), in 1386 ms>
　<GC(4059): mark: 1095 ms, sweep: 291 ms, compact: 0 ms>
　<GC(4059): refs: soft 0 (age >= 32), weak 0, final 263, phantom 0>