IBM 的 Java 诊断，第 5 部分: 使用 Health Center 优化应用程序

核心提示： 图 7. GC 开销展示表GC 性能改进策略GC 的性能影响可以通过几种方法降低，第一种方法是生成更少的垃圾，IBM 的 Java 诊断，第 5 部分: 使用 Health Center 优化应用程序(6)，应用程序是否创建对象并立即丢弃这些对象？字符串被反复连接并没有使用字符串缓冲？自动装箱（

图 7. GC 开销展示表

GC 性能改进策略

GC 的性能影响可以通过几种方法降低。第一种方法是生成更少的垃圾。应用程序是否创建对象并立即丢弃这些对象？字符串被反复连接并没有使用字符串缓冲？自动装箱（autoboxing）是否在后台创建无关的原语包装器吗？代码正在生成不需要的大对象吗？其他性能改进方法包括提高堆大小、调整保育室（nursery）大小（用于分代收集器）和尝试另一个 GC 策略。但是，使用这些技术时要小心。

例如，调优代码以改进 GC 时必须小心。某些明显的优化可能最终会导致更糟糕的性能。例如，通过重用现有对象实例来避免重复创建对象看起来很不错。但是，安全地管理对象池可能会导致同步开销。如果对象池大小没有正确调优，许多未使用的对象实例最终会被闲置，耗尽内存而不产生任何价值。然而，最严重的是，使用一个分代垃圾收集器（比如 gencon 策略所使用的）时，短期存在的对象根本收集不到，而长期存在的对象的收集成本则太昂贵。重复创建并丢弃对象的方法产生很小的性能开销，而持有现有对象实例以便重用的方法则为垃圾收集器增加大量的工作负担。

另一个 GC 调优陷阱是过度关注减小 headline GC 开销（参见 图 7），而忘记了总体目标是优化应用程序 的性能。尽管减小 GC 开销通常会提高应用程序性能，但也有例外情况。例如，使用 gencon 策略执行 GC 花费的时间通常比使用 optthruput 策略花费的时间更多。但是，由于 gencon 策略在堆中放置对象的特定方式，该策略支持更快的对象分配和更快的对象访问。由于应用程序通常花费很多时间来分配和访问对象，所以，对多数应用程序来说，在这个区域获取的性能改进（没有在 GC 开销中反映出来）超出了 GC 本身的额外成本。甚至还有更具戏剧性的例子：optavgpause 策略几乎能同时执行所有 GC 工作，只有非常短的 “stop-the-world” 暂停。这导致非常低的 GC 开销（通常低于 1%）和极好的应用程序响应性。但是，在应用程序吞吐量方面不如 optthruput 或 gencon 策略。