【Java 8 GC 调优】引言

从小型桌面应用到大型服务器上的Web服务，有大量不同种类的应用程序使用了 Java SE 平台。为了支持多种多样的部署，Hotspot 这个 JVM 提供了多个垃圾收集器（GC），它们被设计成满足不同的需求。这是为了同时满足不同大小应用的重要组成部分。Java SE 会根据应用程序所运行的计算机类别，选择最合适的GC。但这可能并不是对每个应用的最优选择。用户，开发者，以及对性能目标有严格要求或有其它要求的管理员，可能需要显式地选择GC，并调整某些参数，来达到期望的性能水平。此文档提供了帮助执行这些任务的信息。首先，垃圾收集器的一般特性和基本调优选项会在 “Stop-the World” 系列中描述。然后介绍其它GC特点，及选择GC时应考虑的因素。
 

垃圾收集器（GC）是内存管理工具。它通过以下操作来实现自动内存管理：

• 把对象分配到新生代中，将老对象提升到老年代中。
• 在并发（并行）标记阶段找到老年代中的存活对象。
  当堆内存使用量超过默认阈值时，Hotspot 会触发标记阶段。
  《Concurrent Mark Sweep (CMS)》、《Garbage-First （G1）》
• 通过并行复杂活动对象，使它们更紧凑，来恢复可用内存。
  《并行GC》、《Garbage-First （G1）》

什么时候 GC 的选择会很重要？对某些应用来说，永远都不重要。也就是说，在 GC 所引发暂停的频率和持续时间适中的情况下，这些应用也能良好地运行。但是大量的应用并不是这种情况，尤其是那些有大量数据（几个GB）、很多线程、事务处理频度高的应用。
 

阿姆达尔定律：对于给定的问题，并行处理它的加速效果受限于问题中必须串行处理的部分。 这个定律意味着决大多数工作不能被完全并行化；总有某些部分是串行，无法从并行化中获益。这对于Java平台同样适用。尤其是 Java 1.4 之前的Oracle Java平台不支持并行GC，所以GC在多处理器系统中的影响会比其它并行应用更大。
 

下图“比较垃圾收集所花费时间的百分比”对一个理想的系统进行建模。除GC外，该系统拥有完美的扩展性。

• 红线表示此应用在单处理器系统中只花费了 1% 的时间用于垃圾收集；在32个处理器的系统中，其吞吐量损失超过 20%。
• 洋红色的线表示一个应用程序花费了 10% 的时间用于垃圾收集（在单处理器系统中这个耗时并不算多）；当扩展到32个处理器时，其吞吐量损失超过 75%。
  （多个处理器必须等待某一个处理器完成串行任务的处理）

 

这表明在开发小型系统时可忽略的速度问题会在扩展到大型系统时成为主要瓶颈。但是在减少这种瓶颈方面的小改进可以获得很大的性能提升。对于足够大的系统，选择一个合适的垃圾收集器，并在必要时对其进行调优是值得的。
 

串行收集器 通常适用于大多数“小型”应用程序（所需堆内存不超过100MB）。其它收集器有额外的开销或复杂性，这是特殊处理的代价。如果应用程序不需要其它收集器的特殊处理，请使用串行收集器。对于一个运行在多处理器上且使用了大量内存的大型多线程应用程序来说，串行收集器不是最佳选择。当应用程序运行在服务器类的机器上时，（Hotspot）默认使用并行收集器。
《Ergonomics》
 

此文档基于 Solaris 操作系统（SPARC平台板）上的 Java SE 8 编写。但是此文档中的概念与建议适用于所有支持的平台，包括 Linux、Microsoft Windows、x64平台版的Solaris、OS X。而且提及的命令行选项可在所有这些平台中使用，尽管某些选项的默认值在不同平台上可能不同。