GC调优入门笔记
想给项目代码做做调优但有许多疑惑，比如有哪些参数要调、怎么调、使用什么工具、调优的效果如何定量测量等。发现Oracle的这份资料不错，简洁直接，回答了我的许多问题，给了许多很实用的大方向上的指导。将其中精华记录下来，希望能给同样入门的朋友一些启示。
Garbage Collectors
垃圾收集器 (Garbage Collectors)是JVM中的内存管理工具。它的职责包括：
- 在年轻代为对象分配空间，并将存活比较久的对象移动到年老代；
- 在堆占用率超过某阈值时触发concurrent marking phase，在年老代找到存活的对象；
- 触发parallel copying，压缩活着的对象，释放垃圾空间。
看起来有点抽象，并且貌似没提到年轻代的垃圾收集，其实已经在第一条中提到了：“将存活比较久的对象移动到年老代”，这里隐含了对年轻代进行存活对象登记和收集的过程。简而言之，垃圾收集器的职责是：给对象分配内存；收集年轻代垃圾；收集年老代垃圾。
串/并行Garbage Collector的选择
一般来说，JVM会根据系统的物理配置等因素选择一个默认的垃圾处理器。但显然，不同的应用程序有不同的行为（如使用内存的频率、对象的平均存活时间）；也有不同的要求（如有界面的程序要求响应快速，而服务器端程序要求吞吐量高，能处理更多的请求）。所以，根据不同程序的特点，可能需要不同的垃圾处理器来管理。在此处，我们先从串/并行的角度浅浅地了解一下这个问题。
垃圾处理器可以粗略地分为串行进行和并行进行的，即垃圾处理这个过程在单线程还是多线程中进行；在Java SE 1.4之前的版本不支持并行。根据Amdahl's law （程序能够通过并行来加速的程度取决于程序中必须串行运行的部分），如果GC是串行进行的，则一个并行的应用程序的加速程度会受到GC的影响。假设我们通过增加处理器个数的方式来加速一个应用程序，那么随着处理器个数的增多，GC拖后腿的程度也越来越厉害，看下图：
ＧＣ时间所占的百分比随处理器个数的变化
这是一个数学模拟图，模拟了一个理想（完全并行）的应用程序的吞吐量受GC时间的影响。横轴代表处理器个数，纵轴代表吞吐量，不同颜色的曲线代表GC百分比不同的程序。红色曲线表示一条在单CPU下GC时间占1%的程序，在处理器个数增加到32个时，GC占整个程序运行时间的百分比竟超过了20%。
可以看到GC所占的时间百分比越大，拖后腿的程度就越厉害。这是一个很好理解的现象，因为GC是串行的，所以其运行时间不受处理器数量的影响。随着处理器的增多，应用程序本身的运行时间下降了，所以显得GC所占的时间百分比越来越大。
因此，在小系统上开发应用时可以忽略的一些GC小问题，当扩展到大型系统上时就会变得十分可观，甚至成为性能瓶颈。但是，此时在垃圾处理器上做一些小文章就有可能极大地增加性能。比如考虑到上图反映的现象，或许我们可以考虑换一个并行的垃圾处理器以提高吞吐量。
另一方面，小型应用如果不需要其他特殊的GC行为，通常使用串行垃圾处理器就够了，选择其他垃圾处理器可能反而会引入额外的复杂性和开销。
分代模型
在处理垃圾时，需要先找到所有活着的对象，然后将剩下的作为垃圾进行处理。“找到所有活着的对象”这个过程需要耗费的时间与活着的对象数量成正比，这样的话，如果应用中本来就维护了大量的存活对象，那么找到活着的对象需要耗费大量的时间。为了优化这个过程，JVM程序员们基于一些经验提出了分代收集的思想。在这些经验中，最重要的是分代假设，即大部分对象都只存活很短的时间。
对象寿命的典型分布图
上图中，横轴代表总的字节分配数，即时间轴；纵轴代表不同时间下存活的对象所占字节数。左边的尖峰代表分配空间没多久就可以回收的对象，比如在某个loop中临时分配的对象，它们的寿命只有一个loop的时间；最右边代表存活很久的那些对象，比如初始化时就存在且一直活到程序结束的对象；在这两极之间，有一些用于中间计算的对象，即左边的尖峰右边的这个包。
不同应用程序的对象寿命分布图是不一样的，但是许多应用的大致分布都符合上面这个图，这为分代收集奠定了一个很好的事实基础：大部分对象都在年轻时死去。
比如在一个公园里扫落叶，腾出空地让行人行走。有一些树掉叶子特别厉害，一小会儿地上就掉满了；而另外一些树每小时只掉一两片叶子。假设清洁工为了省力，每过一段时间就清扫一次，扫完了则回到椅子上休息。如果我是清洁工，肯定会选择集中打扫那些掉得厉害的树，而且可能会以比较高的频率打扫；至于那些掉得不厉害的树，只要偶尔看一下，等落满的时候再打扫就好了。如果每次都要把所有的树下打扫一遍，为了照顾那些掉得厉害的树我的打扫频率需要很高，我会很累，而且打扫时间也会变长，效率降低。
除了串行收集器和G1之外，其他收集器默认使用以下分代模型：
默认分代模型
模型分为年轻代和年老代，年轻代分为eden和两个survivor，virtual空间代表JVM向操作系统预订但还未实际分配的空间。
调优指标
maximum pause time
pause time是指垃圾处理器停止应用程序的运行，专注于空间释放时所花的时间。如果使用的是并行垃圾处理器，可以通过-XX:MaxGCPauseMillis=<nnn>这个命令行参数设定期望的最大pause time。（如果未设置，默认没有最大时间要求）
垃圾处理器会维护每次垃圾收集pause time的均值和方差，当均值与方差的和大于设置的MaxGCPauseMillis参数时，垃圾处理器会认为停留时间目标未达到，然后调整堆的大小和其它的有关参数来试图达到目标。
此处的maximum pause time和下面即将提到的throughput是一对相爱相杀的姐妹。通常减小堆size会优化pause time（扫描、处理时间减少），但是堆变小造成GC频率升高，从而导致throughput下降。对于这两者，垃圾处理器的处理方式是优先达到设置的pause time目标，其次再达到throughput目标。
throughput
吞吐量通过GC时间比例测量。 GC时间比例 = GC时间 / (GC时间 + 应用运行时间)，其中的GC时间包括所有代的GC时间。如果使用的是并行垃圾处理器，吞吐量可以通过-XX:GCTimeRatio=<nnn>设置，若<nnn>为19，则GC时间比例为1/(1+19)=5%，即垃圾处理的时间占总时间的5%。
如果GCTimeRatio未达到要求，垃圾收集器会增加年轻代和年老代的大小来降低GCTimeRatio。
footprint
内存占用（memory footprint）指程序运行时占用和引用的内存大小。
如果前面两个目标达到了，垃圾处理器会自动收缩堆，直至其中一个目标不再满足（一定是throughput，因为堆变小会使停留时间变短），然后再试图满足这个目标。
promptness
及时性 (promptness)定义为对象死去之后到对象所占用的内存可以使用之前的时间。这个指标对分布式系统通常比较重要。
一般调优策略
- 如果堆已经达到maximum heap size但throughput目标还未达到，说明设置的maximum heap size太小，可以尝试将其设为接近物理内存但还不至于导致内存交换的值。如果还是达不到throughput目标，说明这个throughput目标对于当前平台上的内存大小来说过高了。
- 如果throughput目标已经满足，但停留时间过长，则可以增加maximum pause time目标。但这样throughput目标有可能又得不到满足了，此时需要根据自己的判断作一个折中。
- 如上文所说，throughput与pause time对堆大小的要求相反，是一对相互竞争的指标。它们之间的相互竞争可能造成的结果是：即使应用程序已经在稳定运行了，堆大小仍然在上下振动。这表明垃圾处理器努力在两者之间寻找一个平衡。
度量
以上所说的throughput等指标需要根据应用的不同特性去测量。比如要测一个web server的throughput，可以用一个自己写的client load generator；测试Solaris系统上服务器的内存占用，可以用pmap这个命令；若要测GC的停留时间，则可以通过命令行参数-verbose:gc直接观察JVM的诊断输出。
总结
本文定性介绍了GC调优的一些初级概念，为实际调优奠定基础。但仅有这些模糊概念是远远不够的，在理论和实践上还会作出其它总结，欢迎关注。
参考资料/推荐阅读
Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide 文中提到的资料，Oracle写的，具有官方指导意义
深入理解Java虚拟机 推荐看第4-5章，详细讲解了调优工具的使用以及几个调优实例
高质量Java程序设计 推荐看第3章，作者用一个xml parser的例子给出了调优实战讲解，可惜本书不再再版，也未找到电子版
