最近一个运行了很久的程序出现了好几次OutOfMemory故障，造成大量业务都无法访问数据库的严重事故。事后通过加大堆内存暂时先优化了一下，顺便买了一本《Java性能权威指南》，研究了一下，发现其中的垃圾收集章节基本上能够解释所有的问题了。于是把该章节整理了一下，这些知识对于大多数的Java程序来说基本够用了。
1 垃圾收集概念
1.1 分代垃圾收集器
- 所有的GC算法都将堆分成了老年代和新生代。
- 所有的GC算法在清理新生代对象时，都使用了“时空停顿”（stop-the-world）方式
1.2 GC算法
JVM提供了4中不同的垃圾收集算法
- Serial垃圾收集器
- Throghput垃圾收集器
- CMS收集器
- G1垃圾收集器
- 这四种垃圾收集算法分别采用了不同的方法来缓解GC对应用程序的影响。
- Serial收集器常用于仅有单CPU可用以及当其他程序会干扰GC的情况（通常是默认值）。
- Throughput收集器在其他的虚拟机上是默认值，它能最大化应用程序的总吞吐量，但是有些操作可能遭遇较长的停顿。
- CMS收集器能够在应用县城运行的同时并行地对老年代的垃圾进行收集。如果CPU的计算能力足以支撑后台垃圾收集县城的运行，该算法能避免应用程序发生Full GC。
- G1收集器也能在应用线程运行的同时并发地对老年代进行收集，在某种程度上能够减少发生Full GC的风险。G1的设计理念使得它比CMS更不容易遭遇Full GC。
1.3 选择GC算法
GC算法的选择一方面取决于应用程序的特征，另一方面取决于应用的性能目标
GC算法与批量任务
- 使用Throughput收集器处理应用程序线程的批量任务能最大程度地利用CPU的处理能力，通常能获得更好的性能。
- 如果批量任务并没有使用机器上所有可能的CPU资源，那么切换到Concurrent收集器往往能取得更好的性能。
GC算法与吞吐量测试
- 衡量标准是响应时间或吞吐量，在Throughput收集器和Concurrent收集器之间选择的依据主要是多少空闲CPU资源能用于运行后台的并发县城。
- 通常情况下，Throughput收集器的平均响应时间比Concurrent收集器要差，但是在90%响应时间或者99%响应时间这几项指标上，Throughput收集器比Concurrent收集器要好一些。
- 使用Throughput收集器会超负荷地进行大量Full GC时，切换到Concurrent收集器通常能获得更低的响应时间。
CMS收集器和G1收集器之间的抉择
- 选择Concurrent收集器时，如果堆较小，推荐使用CMS收集器。
- G1的设计使得它能够在不同的分区（Region）处理堆，因此它的扩展性更好，比CMS更易于处理超大堆的情况。
2 GC调优基础
2.1 调整堆的大小
最大堆： -Xmx
最小堆： -Xms
- JVM会根据其运行的机器，尝试估算合适的最大、最小堆的大小。
- 除非应用程序需要比默认值更大的堆，否则在进行调优时，尽量考虑通过调整GC算法的性能目标，而非微调堆的大小来改善程序性能。
2.2 代空间的调整
-XX:NewRatio=N 设置新生代与老年代的空间占用比率 , 默认值为2
-XX:NewSize=N 设置新生代的初始大小
-XX:MaxNewSize=N 设置新生代的最大大小
-XmnN 将NewSize和MaxNewSize设定为同一个值得快捷方法
Initial Young Gen Size = Initial Heap Size / ( 1 + NewRatio )
- 整个堆范围内，不同代的大小划分是由新生代所占用的空间控制的。
- 新生代的大小会随着整个堆大小的增长而增长，但这也是随着整个堆的空间比率波动变化的（依据新生代的初始值和最大值）。
2.3 永久代和元空间的调整
- 永久代或元空间保存着类的元数据（并非类本体的数据）。它以分离的堆的形式存在。
- 典型应用程序在启动后不需要载入新的类，这个区域的初始值可以依据所有类都加载后的情况设置。使得优化的初始值能够加速启动的过程。
- 开发中的应用服务器（或者任何需要繁重重新载入类的环境）上经常能碰到由于永久代或元空间耗尽触发的Full GC，这时老的元数据会被丢弃回收。
2.4 控制并发
-XX:ParallelGCThreads=N 控制启动的线程数
默认情况下JVM会在机器的每个CPU上运行一个线程，最多同时运行8个。一旦达到这个上限，JVM会调整算法，每超出5/8个CPU启动一个新的线程，所以总的线程数就是（N：CPU数）
ParallelGCThreads = 8 + ((N - 8) * 5/ 8)
- 几乎所有的垃圾收集算法中基本的垃圾回收线程数都依据机器上的CPU数目计算得出。
- 多个JVM运行在同一台物理机上时，依据公司计算出的县城数可能过高，必须进行优化（减少）。
2.5 自适应调整
自适应调整就是JVM会根据调优的策略不断的尝试，寻找优化性能的机会，它进行性能调优的依据是以往的性能历史：这其中隐含了一个假设，即将来GC周期的状态跟最近历史GC周期的状况可能很类似。事实也证明，在多种负荷下这一假设都是合理的，即使某个时刻内存的分配发生突变的情况，JVM也能够依据最新的情况重新调整它的大小。
自适应调整作用主要在两个方面：
- 小型应用程序不需要为指定过大的堆而担心。
- 很多应用程序根本不需要担心它的堆的大小，如果需要使用的堆的大小超过了平台的默认值，可以放心的分配更大的堆，不用关心其他细节，JVM会自动调整堆和代的打小，依据垃圾回收算法的性能目标，使用优化的内存量。
-XX:-UseAdaptiveSizePolicy 关闭自适应调整功能（如果堆得最大最小值相同，新生代的初始值和最大值相同时也会被关闭）
总结：
- JVM在堆得内部如何调整新生代及老生代的百分比是由自适应调整机制控制的。
- 通常情况下，我们应该开启自适应调整，因为垃圾回收算法依赖于调整后的代的大小来达到它停顿时间的性能目标。
- 对于已经精细调优过的堆，关闭自适应调整能获得一定的性能提升。
3 垃圾回收工具
开启GC的日志功能
-verbose:gc
-XX:+PrintGC
-XX:+PrintGCDetails 会创建更详细的GC日志（推荐使用）
-XX:+PrintGCTimeStamps或者-XX:+PrintGCDateStamps(推荐使用) 便于我们更精确地判断几次GC操作之间的时间。
两者的差距在于前者相对于0（JVM启动时间）的值，而后者是实际的日期字符串（效率稍低）。
-Xloggc:filename 指定输出到文件
-XX:+UseGCLogfileRotation -XX:NumberOfGCLogfiles=N -XX:GCLogfilesSize=N可以控制日志文件的循环。
分析日志文件的工具：GC Histogram (http://java.net/projects/gchisto)
其他工具：
jconsole： 可以实时监控堆的使用情况。
jstat： 可以实时收集数据
jstat -gcutil process_id 1000
小结：
- GC日志是分析GC相关问题的重要线索；我们应该开启GC日志标志（即使在生产服务器上）。
- 使用PrintGCDetails标志能获得更详尽的GC日志信息。
- 使用工具能有效地帮助我们解析和理解GC日志的内容，尤其是在堆GC日志中的数据进行归纳汇总时，它们非常有帮助。
- 使用jstat能动态地观察运行程序的垃圾回收操作。
4 总结
对任何一个Java应用程序而言，垃圾收集的性能都是其构成整体性能的关键一环。虽然对大多数的应用程序来说，调优的工作仅仅是选择合适的垃圾收集算法，或者在需要的时候，增大应用程序堆空间。
自使用调整让JVM能够自动地调整它的行为，使用给定的堆，提供尽可能好的性能。
更复杂的应用往往需要额外的调优，尤其是针对特定GC算法的调优。
