（三）学习JVM —— 垃圾回收器

（一）学习JVM ——运行时数据区域

（二）学习JVM —— 垃圾回收机制

（三）学习JVM —— 垃圾回收器

（四）学习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个步骤：

1. 初始标记 ( CMS initial mark )；
2. 并发标记 ( CMS concurrent mark )；
3. 从新标记 ( CMS remark )；
4. 并发清除 ( 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运做大体可分为如下几个步骤：

1. 初始标记 (Initial Marking)：仅仅只是标记一下GC Roots能直接关联到的对象，而且修改TAMS (Next Top at Mark Start)的值，让下一阶段用户程序并发运行时，能在正确可用的Region中建立新对象，这个阶段有一个很短的STW；
2. 并发标记 (Concurrent Marking)：是从GC Roots开始对堆中的对象进行可达性分析，找出存活的对象，这阶段耗时很长，可与用户程序并发执行。
3. 最终标记 (Final Marking)：该阶段是为了修正在并发标记阶段因用户程序继续运行而致使标记产生变化的那一部分标记记录，虚拟机将这段时间对象变化的记录在线程Remembered Set Logs里面，而后合并到Remembered Set中，这阶段要STW，可是可并行执行；
4. 筛选回收 (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 ——运行时数据区域

（二）学习JVM —— 垃圾回收机制

（三）学习JVM —— 垃圾回收器

（四）学习JVM —— 内存分配与回收策略