JDK8垃圾回收调优指南--(1)说明

原文地址：Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide--Introduction。

从台式机上的小applet到大型服务器上的web服务，各种应用程序都使用Java。为了支持这种不同范围的部署，满足不同的要求，JVM提供了多个垃圾收集器。这是满足大型和小型应用程序需求的一个重要部分。Java SE根据运行应用程序的计算机选择最合适的垃圾收集器。然而，这种选择可能不是对每个应用程序都是最优的。
具有严格性能目标或其他需求的用户、开发人员和管理员可能需要显式地选择垃圾收集器，并调优某些参数，以实现所需的性能级别。本文档提供了帮助完成这些任务的信息。首先，在本系列的上下文中描述了垃圾收集器的一般特性和基本调优选项，stop-the-world收集器。然后给出了其他收集器的具体特性以及选择收集器时要考虑的因素。

垃圾收集器就是一个内存管理工具，通过以下操作实现自动内存管理：

• 将对象分配给年轻代，并将老的对象提升到老年代。
• 通过并发(并行)标记阶段在老年代中找到活动对象。当JVM中Java堆占用总量超过默认阈值时触发标记阶段。请参阅CMS和G1。
• 通过并行复制压缩活动对象来恢复空闲内存。请参阅并行收集器和G1。

什么时候垃圾收集器的选择很重要？对于一些应用，答案是永远都不重要。也就是说，应用程序可以在存在垃圾收集的情况下正常运行，暂停的频率和持续时间都不高。但是，对于大型应用程序，特别是具有大量数据(几个gb)、多线程和高事务率的应用程序，情况就不一样了。

Amdahl定律（给定问题的并行加速受问题的顺序部分的限制）意味着大多数工作负载不能完全并行化;有些部分总是顺序的，并不会从并行中获益。对于Java平台也是如此。特别是，针对Java SE 1.4之前的Java平台的Oracle虚拟机不支持并行垃圾收集，因此与其他并行应用程序相比，垃圾收集对多处理器系统的影响越来越大。

图1-1"比较垃圾收集花费时间百分比"为一个理想的系统建模，该系统除了垃圾收集（GC）之外是完全可伸缩的。红线是一个应用程序在单处理器系统上只花费1%的时间进行垃圾收集。这意味着32个处理器的系统的吞吐量损失超过20%。洋红色的线显示，对于垃圾收集时间占10%的应用程序（在单处理器应用程序中垃圾收集的时间不算多），当扩展到32个处理器时，超过75%的吞吐量会丢失。

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

串行收集器通常适用于大多数“小型”应用程序（在现代处理器上，这些应用程序需要高达100 MB的堆）。其他收集器有额外的开销或复杂性，这是专门化行为的代价。如果应用程序不需要特殊行为的收集器，则使用串行收集器。串行收集器在具有大量内存和两个或更多处理器的机器上运行的大型、多线程的应用程序中使用不被认为是最佳选择。当应用程序在这样的服务器机器上运行时，默认情况下选择并行收集器。参见人机工程学。

本文档是使用Solaris操作系统（SPARC平台版）上的Java SE 8作为参考开发的。但是，这里提出的概念和建议适用于所有受支持的平台，包括Linux、Microsoft Windows、Solaris操作系统（x64平台版）和OS X。此外，上面提到的命令行选项在所有受支持的平台上都是可用的，尽管某些选项的默认值在每个平台上可能不同。