我们接着上面一篇继续学习JVM的基本知识。

对象存活判断

上篇中我们介绍过JVM垃圾回收综述中说过一次垃圾回收之后会有一些对象存活。这节我们介绍两个判断对象存活的算法。

判断对象存活有引用计数算法和可达性分析算法。

1、引用计数算法

给每一个对象添加一个引用计数器，每当有一个地方引用它时，计数器值加1；每当有一个地方不再引用它时，计数器值减1，这样只要计数器的值不为0，就说明还有地方引用它，它就不是无用的对象。

这种方法看起来非常简单，但目前许多主流的虚拟机都没有选用这种算法来管理内存，原因就是当某些对象之间互相引用时，无法判断出这些对象是否已死。如下图，对象1和对象2都没有被堆外的变量引用，而是被对方互相引用，这时他们虽然没有用处了，但是引用计数器的值仍然是1，无法判断他们是死对象，垃圾回收器也就无法回收。

2、可达性分析算法

了解可达性分析算法之前先了解一个概念——GC Roots，垃圾收集的起点，可以作为GC Roots的有虚拟机栈中本地变量表中引用的对象、方法区中静态属性引用的对象、方法区中常量引用的对象、本地方法栈中JNI(Native方法)引用的对象。 当一个对象到GC Roots没有任何引用链相连(GC Roots到这个对象不可达)时，就说明此对象是不可用的，是死对象。如下图：object1、object2、object3、object4和GC Roots之间有可达路径，这些对象不会被回收，但object5、object6、object7到GC Roots之间没有可达路径，这些对象就是死对象。

上面被判定为非存活的死对象(object5、object6、object7)并不是必死无疑，还有挽救的余地。进行可达性分析后对象和GC Roots之间没有引用链相连时，对象将会被进行一次标记，接着会判断如果对象没有覆盖Object的finalize()方法或者finalize()方法已经被虚拟机调用过，那么它们就会清除；如果对象覆盖了finalize()方法且还没有被调用，则会执行finalize()方法中的内容，所以在finalize()方法中如果重新与GC Roots引用链上的对象关联就可以拯救自己。当然，实际中一般不会这么做。

GC算法

接下来讲GC的算法，主要有标记-清除算法、复制算法、标记-整理算法、分代收集算法。

1、标记-清除算法

最基础的收集算法是“标记-清除”(Mark-Sweep)算法，分两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。

优点：不需要进行对象的移动，并且仅对不存活的对象进行处理，在存活对象比较多的情况极为有效。

不足：一个是效率问题，标记和清除两个过程的效率都不高；另一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能导致以后在程序运行过程需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一个的垃圾收集动作。

下面两张图从两个角度阐明了标记-清楚算法：

2、复制算法

为了解决效率问题，一种称为复制(Copying)的收集算法出现了，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块内存用完了，就将还存活着的对象复制到另外一块上，然后再把已经使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。代价是内存缩小为原来的一半。

复制算法过程如下面两张图表示：

商业虚拟机用这个回收算法来回收新生代。IBM研究表明98%的对象是“朝生夕死“，不需要按照1-1的比例来划分内存空间，而是将内存分为一块较大的”Eden“空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。当回收时，将Eden和Survivor中还存活的对象一次性复制到另外一个Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。Hotspot虚拟机默认Eden和Survivor的比例是8-1.即每次可用整个新生代的90%, 只有一个survivor，即1/10被”浪费“。当然，98%的对象回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够时，需要依赖其他内存(老年代)进行分配担保(Handle Promotion).

如果另外一块survivor空间没有足够空间存放上一次新生代收集下来的存活对象时，这些对象将直接通过分配担保机制进入老年代。

下面大概介绍一下这个eden survivor复制的过程。

Eden Space字面意思是伊甸园，对象被创建的时候首先放到这个区域，进行垃圾回收后，不能被回收的对象被放入到空的survivor区域。

Survivor Space幸存者区，用于保存在eden space内存区域中经过垃圾回收后没有被回收的对象。Survivor有两个，分别为To Survivor、 From Survivor，这个两个区域的空间大小是一样的。执行垃圾回收的时候Eden区域不能被回收的对象被放入到空的survivor(也就是To Survivor，同时Eden区域的内存会在垃圾回收的过程中全部释放)，另一个survivor(即From Survivor)里不能被回收的对象也会被放入这个survivor(即To Survivor)，然后To Survivor 和 From Survivor的标记会互换，始终保证一个survivor是空的。

为啥需要两个survivor？因为需要一个完整的空间来复制过来。当满的时候晋升。每次都往标记为to的里面放，然后互换，这时from已经被清空，可以当作to了。

3、标记-整理算法

复制收集算法在对象成活率较高时就要进行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以，老年代一般不能直接选用这种算法。

根据老年代的特点，有人提出一种”标记-整理“Mark-Compact算法，标记过程仍然和标记-清除一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理端边界以外的内存。

下面两张图讲了这个算法的过程：

4、分代收集算法

当前商业虚拟机的垃圾收集都采用”分代收集“(Generational Collection)算法，这种算法根据对象存活周期的不同将内存划分为几块。一般把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代，每次垃圾收集时都发现大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率较高，没有额外的空间对它进行分配担保，就必须使用”标记-清理“和”标记-整理“算法来进行回收。

这种算法就是我们在前面JVM垃圾回收综述中讲述的内容。其本质是更为灵活的使用”标记-清理“和”标记-整理“算法。

常见的GC回收器

现在常见的垃圾收集器有如下几种

新生代收集器：Serial、ParNew、Parallel Scavenge

老年代收集器：Serial Old、CMS、Parallel Old

堆内存垃圾收集器：G1

如图所示：

0、垃圾收集时间

当程序运行时，各种数据、对象、线程、内存等都时刻在发生变化，当下达垃圾收集命令后垃圾收集器并不会立刻执行垃圾收集。为了搞明白垃圾收集器的工作原理，我们需要讲两个名词：安全点(safepoint)和安全区(safe region)。

安全点：从线程角度看，安全点可以理解为是在代码执行过程中的一些特殊位置，当线程执行到安全点的时候，说明虚拟机当前的状态是安全的，如果有需要，可以在这里暂停用户线程。当垃圾收集时，如果需要暂停当前的用户线程，但用户线程当时没在安全点上，则应该等待这些线程执行到安全点再暂停。

安全区：安全点是相对于运行中的线程来说的，对于如sleep或blocked等状态的线程，收集器不会等待这些线程被分配CPU时间，这时候只要线程处于安全区中，就可以算是安全的。安全区就是在一段代码片段中，引用关系不会发生变化，可以看作是被扩展、拉长了的安全点。

GC过程一定会发生STW(Stop The World)，而一旦发生STW必然会影响用户使用，所以GC的发展都是在围绕减少STW时间这一目的。

1、Serial 收集器

Serial是一款用于新生代的单线程收集器，采用复制算法进行垃圾收集。Serial进行垃圾收集时，不仅只用一条线程执行垃圾收集工作，它在收集的同时，所有的用户线程必须暂停(Stop The World)。 如下是Serial收集器和Serial Old收集器结合进行垃圾收集的示意图，当用户线程都执行到安全点时，所有线程暂停执行，Serial收集器以单线程，采用复制算法进行垃圾收集工作，收集完之后，用户线程继续开始执行。

适用场景：Client模式(桌面应用)；单核服务器。可以用-XX:+UserSerialGC来选择Serial作为新生代收集器。

2、ParNew 收集器

ParNew就是一个Serial的多线程版本，其它与Serial并无区别。ParNew在单核CPU环境并不会比Serial收集器达到更好的效果，它默认开启的收集线程数和CPU数量一致，可以通过-XX:ParallelGCThreads来设置垃圾收集的线程数。 如下是ParNew收集器和Serial Old收集器结合进行垃圾收集的示意图，当用户线程都执行到安全点时，所有线程暂停执行，ParNew收集器以多线程，采用复制算法进行垃圾收集工作，收集完之后，用户线程继续开始执行。

适用场景：多核服务器；与CMS收集器搭配使用。当使用-XX:+UserConcMarkSweepGC来选择CMS作为老年代收集器时，新生代收集器默认就是ParNew，也可以用-XX:+UseParNewGC来指定使用ParNew作为新生代收集器。

3、Parallel Scavenge 收集器

Parallel Scavenge也是一款用于新生代的多线程收集器，与ParNew的不同之处是，ParNew的目标是尽可能缩短垃圾收集时用户线程的停顿时间，Parallel Scavenge的目标是达到一个可控制的吞吐量。吞吐量就是CPU执行用户线程的的时间与CPU执行总时间的比值【吞吐量=运行用户代代码时间/(运行用户代码时间+垃圾收集时间)】，比如虚拟机一共运行了100分钟，其中垃圾收集花费了1分钟，那吞吐量就是99% 。比如下面两个场景，垃圾收集器每100秒收集一次，每次停顿10秒，和垃圾收集器每50秒收集一次，每次停顿时间7秒，虽然后者每次停顿时间变短了，但是总体吞吐量变低了，CPU总体利用率变低了。

收集频率

每次停顿时间

吞吐量

每100秒收集一次

10秒

91%

每50秒收集一次

7秒

88%

可以通过-XX:MaxGCPauseMillis来设置收集器尽可能在多长时间内完成内存回收，可以通过-XX:GCTimeRatio来精确控制吞吐量。

如下是Parallel收集器和Parallel Old收集器结合进行垃圾收集的示意图，在新生代，当用户线程都执行到安全点时，所有线程暂停执行，ParNew收集器以多线程，采用复制算法进行垃圾收集工作，收集完之后，用户线程继续开始执行；在老年代，当用户线程都执行到安全点时，所有线程暂停执行，Parallel Old收集器以多线程，采用标记整理算法进行垃圾收集工作。

适用场景：注重吞吐量，高效利用CPU，需要高效运算且不需要太多交互。可以使用-XX:+UseParallelGC来选择Parallel Scavenge作为新生代收集器，jdk7、jdk8默认使用Parallel Scavenge作为新生代收集器。

4、Serial Old收集器

Serial Old收集器是Serial的老年代版本，同样是一个单线程收集器，采用标记-整理算法。

如下图是Serial收集器和Serial Old收集器结合进行垃圾收集的示意图：

适用场景：Client模式(桌面应用)；单核服务器；与Parallel Scavenge收集器搭配；作为CMS收集器的后备预案。

5、CMS(Concurrent Mark Sweep) 收集器

CMS收集器是一种以最短回收停顿时间为目标的收集器，以“最短用户线程停顿时间”著称。整个垃圾收集过程分为4个步骤：初始标记：标记一下GC Roots能直接关联到的对象，速度较快

并发标记：进行GC Roots Tracing，标记出全部的垃圾对象，耗时较长

重新标记：修正并发标记阶段引用户程序继续运行而导致变化的对象的标记记录，耗时较短

并发清除：用标记-清除算法清除垃圾对象，耗时较长

整个过程耗时最长的并发标记和并发清除都是和用户线程一起工作，所以从总体上来说，CMS收集器垃圾收集可以看做是和用户线程并发执行的。

CMS收集器也存在一些缺点：对CPU资源敏感：默认分配的垃圾收集线程数为(CPU数+3)/4，随着CPU数量下降，占用CPU资源越多，吞吐量越小

无法处理浮动垃圾：在并发清理阶段，由于用户线程还在运行，还会不断产生新的垃圾，CMS收集器无法在当次收集中清除这部分垃圾。同时由于在垃圾收集阶段用户线程也在并发执行，CMS收集器不能像其他收集器那样等老年代被填满时再进行收集，需要预留一部分空间提供用户线程运行使用。当CMS运行时，预留的内存空间无法满足用户线程的需要，就会出现“Concurrent Mode Failure”的错误，这时将会启动后备预案，临时用Serial Old来重新进行老年代的垃圾收集。

因为CMS是基于标记-清除算法，所以垃圾回收后会产生空间碎片，可以通过-XX:UserCMSCompactAtFullCollection开启碎片整理(默认开启)，在CMS进行Full GC之前，会进行内存碎片的整理。还可以用-XX:CMSFullGCsBeforeCompaction设置执行多少次不压缩(不进行碎片整理)的Full GC之后，跟着来一次带压缩(碎片整理)的Full GC。

适用场景：重视服务器响应速度，要求系统停顿时间最短。可以使用-XX:+UserConMarkSweepGC来选择CMS作为老年代收集器。

6、Parallel Old 收集器

Parallel Old收集器是Parallel Scavenge的老年代版本，是一个多线程收集器，采用标记-整理算法。可以与Parallel Scavenge收集器搭配，可以充分利用多核CPU的计算能力。如Parallel Scavenge中的两个垃圾收集器的搭配使用图。

适用场景：与Parallel Scavenge收集器搭配使用；注重吞吐量。jdk7、jdk8默认使用该收集器作为老年代收集器，使用 -XX:+UseParallelOldGC来指定使用Paralle Old收集器。

7、G1 收集器

上述的一些GC收集器通过并行与并发已经极大的减少了STW的时间，但是STW的时间还是会因为各种原因不可控，而G1提供的一个最大功能就是可控的STW时间。

G1通过把Java堆分成大小相等的多个独立区域，回收时计算出每个区域回收所获得的空间以及所需时间的经验值，根据记录两个值来判断哪个区域最具有回收价值，所以叫Garbage First(垃圾优先)。

这里有几个重要的概念：Region(区域)：G1采用了分区(Region)的思路，将整个堆空间分成若干个大小相等的内存区域，每次分配对象空间将逐段地使用内存。因此，在堆的使用上，G1并不要求对象的存储一定是物理上连续的，只要逻辑上连续即可；每个分区也不会确定地为某个代服务，可以按需在年轻代和老年代之间切换。启动时可以通过参数-XX:G1HeapRegionSize=n可指定分区大小(1MB~32MB，且必须是2的幂)，默认将整堆划分为2048个分区。

Card(卡片)：在每个分区内部又被分成了若干个大小为512 Byte卡片(Card)，标识堆内存最小可用粒度所有分区的卡片将会记录在全局卡片表(Global Card Table)中，分配的对象会占用物理上连续的若干个卡片，当查找对分区内对象的引用时便可通过记录卡片来查找该引用对象(见RSet)。每次对内存的回收，都是对指定分区的卡片进行处理。

CSet(收集集合)：GC过程记录的可被回收的Region的集合。在CSet中存活的数据会在GC过程中被移动到另一个可用分区，CSet中的分区可以来自eden空间、survivor空间、或者老年代。

RSet(Remembered Set 记忆集合)：记录了其他Region中的对象引用本Region中对象的关系，属于points-into结构 (谁引用了我的对象)。作用是不需要扫描整个堆找到谁引用了当前分区中的对象，只需要扫描RSet即可。

Humongous regions：用来存放大于标准的Region内存50%的大对象区域，如果有些对象大于整个Region就会去找连续的Region保存，如果没有就会触发GC。

G1收集器与之前的收集器最大的不同就在于堆内存的划分，之前的收集器只区分新生代与老年代，而G1收集器则是把堆内存划分成多个独立的Region。

在上图中G1的Java堆中每个Region都有一个身份，每个Region有可能是eden、survivor、old，但是他们的身份仅仅是逻辑上的，是可以变化的，G1可以根据情况动态的调整各种Region的数量，通过控制回收的Region数量来控制STW的时间，以达到STW时间的可控制。

虽然G1收集器把Java堆化整为零成一个个Region，但是也不会进行所有Region进行收集，G1也分成了两种收集模式，两种模式如下：

Young GC: CSet就是所有年轻代里面的Region；

Mixed GC: CSet是所有年轻代里的Region加上在全局并发标记阶段标记出来的收益高的老年代Region；

Young GC过程：

阶段1：根扫描，静态和本地对象被扫描；

阶段2：更新RS，处理dirty card队列更新RS；

阶段3：处理RS，检测从年轻代指向老年代的对象；

阶段4：对象拷贝，拷贝存活的对象到survivorl/old区域；

阶段5：处理引用队列，软引用，弱引用，虚引用处理；

Mixed GC过程：

1、全局并发标记(global concurrent marking)

2、拷贝存活对象(evacuation)

全局并发标记包括5个步骤：

1、初始标记(initial mark，STW)：标记了从GCRoot开始直接可达的对象。

2、根区域扫描(root region scan)：G1 GC 在初始标记的存活区扫描对老年代的引用，并标记被引用的对象。该阶段与应用程序(非 STW)同时运行，并且只有完成该阶段后，才能开始下一次 STW 年轻代垃圾回收。

3、并发标记(Concurrent Marking)：G1 GC 在整个堆中查找可访问的(存活的)对象。该阶段与应用程序同时运行，可以被 STW 年轻代垃圾回收中断。

4、重新标记(Remark，STW)：该阶段是 STW 回收，帮助完成标记周期。G1 GC 清空 SATB 缓冲区，跟踪未被访问的存活对象，并执行引用处理。

5、清除垃圾(Cleanup)：在这个最后阶段，G1 GC 执行统计和 RSet 净化的 STW 操作。在统计期间，G1 GC 会识别完全空闲的区域和可供进行混合垃圾回收的区域。清理阶段在将空白区域重置并返回到空闲列表时为部分并发。

适用场景：要求尽可能可控GC停顿时间；内存占用较大的应用。可以用-XX:+UseG1GC使用G1收集器，jdk9默认使用G1收集器。

GC日志

每一种回收器的日志格式都是由其自身的实现决定的，换而言之，每种回收器的日志格式都可以不一样。但虚拟机设计者为了方便用户阅读，将各个回收器的日志都维持一定的共性。

GC日志是学GC调优之前的必备前置条件，所以我们必须学会。下面放两张网图，大家可以从中看到日志的每个节点：

young gc 日志:

Full GC日志:

查看原文