（三）学习JVM —— 垃圾回收器
垃圾回收器
如图所示，常见的垃圾回收器有七种。
三种新生代回收器，三种老年代回收器，搭配起来可管理整个GC堆，具体如下（新生代回收器在前，老年代回收器在后）：
- Serial + Serial Old；
- Serial + CMS；
- ParNew + Serial Old；
- ParNew + CMS；
- Parallel Scavenge + Serial Old；
- Parallel Scavenge + Parallel Old；
还有一种全可兼顾的回收器G1。
下面对每种垃圾回收器做逐一进行介绍，并在最后对垃圾回收器的参数进行一个总结。
新生代回收器
Serial 回收器
Serial 回收器是一个单线程的收集器，它进行垃圾回收时，必须暂停其他所有的工作线程(Stop The World)，直到它收集结束。
途中灰色竖线就是安全点，而后进入STW，STW后由一条GC单线程做垃圾回收，然后恢复STW。
Serial的优点是它的简单和高效，对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。
Serial收集器对运行在Client模式下的虚拟机来说是一个很好的选择，比如用户的桌面应用等。
ParNew 回收器
ParNew回收器是Serial回收器的多线程版本。除了使用多条线程回收垃圾外，没有什么不同，进入STW后，由多条线程进行垃圾回收。它在Server模式下的虚拟机是首选。
但是在单CPU环境下，ParNew绝不会做的比Serial更好，甚至由于线程之间存在交互开销，都不能保证百分百可以超越Serial。
可以使用-XX:ParallelGCThreads参数限制垃圾回收的线程数。
Parallel Scavenge 回收器
Parallel Scavenge是一个新生代的收集器，它的关注点与其他收集器不同，其他收集器立志于所点垃圾回收时用户的等待时间，而Parallel Scavenge的目的是达到一个可控制的吞吐量(Throughput)。
所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值。
吞吐量 = 运行用户代码时间 / （运行用户代码时间 + 垃圾收集时间）
例如，虚拟机运行是100分钟，其中垃圾回收花掉1分钟，那吞吐量就是99%了。
Parallel Scavenge提供了连个参数用于精确控制吞吐量，分别是控制最大垃圾回收停顿时间的-XX:MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX:GCTimeRatio参数。
-XX:MaxGCPauseMillis参数需要一个大于0的值，垃圾回收器将尽可能地保证内存回收花费的时间不超过设定值，不过不要认为把该值设置小一点就能让垃圾收集速度变得更快，Parallel Scavenge GC停顿时间缩短是以牺牲吞吐量和新生代空间换取的，时间越短，收集次数越频繁，吞吐量越低。
-XX:GCTimeRatio参数的值需要一个大于0且小于100的整数，就是垃圾回收时间占总时间的比率，相当于是吞吐量的倒数。如果把数字设置成19，则垃圾回收时间占总时间的5% = 1 / (1 + 19)。
还有一个值得一提的参数，-XX:UseAdaptiveSizePolicy。这是一个开关参数，开启后虚拟机会根据当前系统的运行情况收集性能监控信息。不需要手动制定新生代大小(-Xmn)、Eden与Survivor的比例(-XX:SurvivorRatio)、晋升老年代的对象大小(-XX:PretenureSizeThreshold)等细节，动态调整这些参数以提供最合适的停顿时间和吞吐量，这种调节方式被成为GC自适应的调节策略(GC Ergonomics)。
老年代回收器
Serial Old 回收器
Serial Old 是 Serial 的老年代版本，它同样是一个单线程收集器，使用标记 & 整理算法。这个回收器主要也是在Client模式下使用，还有一个用途是给CMS回收器做后背预案。
Parallel Old 回收器
Parallel Old 是 Parallel Scavenge 收集器的老年代版本，使用多线程和标记 & 整理算法。
CMS 回收器
CMS ( Concurrent Mark Sweep ) 回收器是一种以获取最短回收停顿时间为目标的回收器。目前很大一部分的Java应用集中在互联网网站或B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。
CMS是基于标记 & 清除算法实现的，整个过程分4个步骤：
- 初始标记 ( CMS initial mark )；
- 并发标记 ( CMS concurrent mark )；
- 重新标记 ( CMS remark )；
- 并发清除 ( CMS concurrent sweep )；
其中，初始标记、重新标记这两个阶段需要STW。
初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快。并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间会比初始标记阶段稍长一些，但远比并发标记时间短。
使用CMS还需要了解它的不足之处，有以下3点不足：
CMS对CPU资源非常敏感。CMS默认开启回收线程数是 ( CPU数量 + 3) / 4，在4个CPU以上时，并发回收线程不少于25%的CPU资源，但随着CPU数量下降（譬如下降到2个），CMS对用户程序的影响就很大，在执行用户程序时还要分出50%的执行速度。
CMS收集器无法处理浮动垃圾 (Floating Garbage)，可能出现"Concurrent Mode Failure"失败导致另一次Full GC的产生。由于CMS并发清理借点，用户线程还在继续运行，就会有新垃圾不断产生，这些垃圾就被称为浮动垃圾。也是由于用户线程还在继续，就需要给用户线程预留足够的内存空间供其使用，因此在JDK1.5时期，CMS当老年代使用了68%的空间后就会被激活进行回收，JDK1.6时这个阀值提高到了92%。另外，CMS还提供了参数-XX:CMSInitiatingOccupancyFraction来设置阀值，但是设置的太高容易导致大量的"Concurrent Mode Failure"，出现时，CMS会启动后背预案，调用Serial Old进行一次回收。
收集结束时会有大量空间碎片产生。空间碎片过多时，将没有连续空间给大对象分配，往往会出现老年代还有很大剩余空间，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。为了解决这个问题，CMS收集器提供了一个-XX:+UseCMSCompactAtFullCollection开关参数，在CMS顶不住要进行FullGC时，会开启内存碎片的合并整理过程，内存整理的过程是无法并发的，所以时间会变长。另外，CMS还提供了一个参数-XX:CMSFullGCsBeforeCOmpaction，这个参数用于设置执行多少次不压缩的FullGC后，跟着来一次带压缩的FullGC（默认值为0，每次都压缩）。
G1 回收器
G1 (Garbage-First) 收集器是当今收集器技术，是一款面向服务端应用的垃圾回收器，它有如下特点：
- 分代回收：G1不需要与其他回收器配合就能独立管理整个GC堆；
- 可预测的停顿：G1除了最求低停顿外，还能建立可预测的停顿时间模型；
- 并行与并发：G1能充分利用多CPU、多核环境下的硬件优势来缩短STW；
- 空间整合：G1采用标记&整理算法实现垃圾回收；
分代回收
G1将整个堆划分为多个大小相等的独立区域 (Region)，虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离了，他们都是一部分Region的集合。
可预测的停顿
G1之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个堆中进行全区域的垃圾回收。G1根据各个Region里面的垃圾堆积的价值大小，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。
在G1中，Region之间的对象引用以及其他回收器中的新生代与老年代之间的对象引用，都是使用Remembered Set来避免全堆扫描的，G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否在其他Region之中，如果在，便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set之中。当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描页不会有遗漏。
并行与并发
如果不计算维护RememBered Set的操作，G1运作大致可分为以下几个步骤：
- 初始标记 (Initial Marking)：仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS (Next Top at Mark Start)的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象，这个阶段有一个很短的STW；
- 并发标记 (Concurrent Marking)：是从GC Roots开始对堆中的对象进行可达性分析，找出存活的对象，这阶段耗时很长，可与用户程序并发执行。
- 最终标记 (Final Marking)：该阶段是为了修正在并发标记阶段因用户程序继续运行而导致标记产生变化的那一部分标记记录，虚拟机将这段时间对象变化的记录在线程Remembered Set Logs里面，然后合并到Remembered Set中，这阶段要STW，但是可并行执行；
- 筛选回收 (Live Data Counting and Evacuation)：该阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划；
垃圾回收器参数总结
垃圾回收相关的常用参数
| UseSerialGC | 虚拟机运行在Client模式下的默认值，使用Serial+Serial Old组合； |
|---|---|
| UseParNewGC | 打开此开关后，使用ParNew + Serial Old组合； |
| UseConcMarkSweepGC | 打开此开关后，使用ParNew + CMS + Serial Old组合； |
| UseParallelGC | 虚拟机运行在Server模式下的默认值，使用Parallel Scavenge + Serial Old组合； |
| UseParallelOldGC | 打开此开关后，使用Parallel Scavenge + Parallel Old组合； |
| SurvivorRatio | 新生代中Eden区域和Survivor区域的容量比值，默认为8，代表8:1:1； |
| PretenureSizeThreshold | 直接晋升老年代的对象大小，设置这个参数后，大于这个参数的对象将直接在老年代分配； |
| MaxTenuringThreshold | 晋升到老年代的对象年龄，经过一次MinorGC之后，年龄+1，超过这个值时进入老年代； |
| UseAdaptiveSizePolicy | 动态调整堆中各个区域的大小以及进入老年代的年龄； |
| HandlePromotionFailure | 是否允许分配担保失败，即老年代剩余空间不足应付新生代的整个区域所有对象都存活的极端情况； |
| ParallelGCThreads | 设置并行GC时进行内存回收的线程数； |
| GCTimeRatio | GC时间占总时间的比率，默认为99，允许1%的GC时间，仅在使用Parallel Scavenge收集器时生效； |
| MaxGCPauseMillis | 设置GC最大停顿时间，仅在使用Parallel Scavenge收集器时生效； |
| CMSInitiatingOccupancyFraction | 设置CMS收集器在老年代空间被使用多少后出发垃圾回收，仅在使用CMS收集器时生效； |
| UseCMSCompactAtFullCollection | 设置CMS在完成垃圾回收后是否要进行一次内存碎片整理，仅在使用CMS收集器时生效； |
| CMSFullGCsBeforeCompaction | 设置CMS在完成多少次垃圾回收后启动一次内存碎片整理，仅在使用CMS收集器时生效； |
（三）学习JVM —— 垃圾回收器