JVM垃圾回收机制

1 对象存活分析

1.1 引用计数法

给对象中添加一个引用计数器，每当有一个地方引用它，计数器就加1；当引用失效，计数器就减1；任何时候计数器为0的对象就是不再被使用的。 这种方法很难解决对象之间相互循环引用的问题，所以很少有被使用。

1.2 可达性分析算法

将“GC Roots” 对象作为起点，从这些节点开始向下搜索引用的对象，找到的对象都标记为非垃圾对象，其余未标记的对象都是垃圾对象 。

GC Roots根节点：线程栈的本地变量、静态变量、本地方法栈的变量等等。

2 分代收集理论

根据对象存活周期的不同将内存分为几块，一般将java堆分为新生代和老年代，可以根据各个年代的特点选择合适的垃圾收集算法。

新生代GC非常频繁，里面对象非常不稳定，可能一次回收大量对象，所以可以选择复制算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。

老年代比较稳定，回收的可能性比新生代相对要小，可能一次GC只回收几个对象，而且没有额外的空间对它进行分配担保，所以可以选择“标记-清除”或“标记-整理”算法进行垃圾收集。

注意，“标记-清除”或“标记-整理”算法会比复制算法慢10倍以上。

3 垃圾收集算法

3.1 复制算法

核心思想就是将内存空间分为大小相同的两块，每次只使用其中一块，当这一块使用完之后，会将正在使用的内存中的存留对象复制到未被使用的内存块中去，之后去清除之前正在使用的内存块中所有的对象，反复去交换两个内存的角色，完成垃圾收集。这样就使每次的内存回收都是对内存区间的一半进行回收。

3.2 标记-清除法

就是分为标记和清除两个阶段：标记存活的对象， 统一回收所有未被标记的对象(一般选择这种)；或者标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象 。

当然这种方式也有很大的弊端，一个是空间碎片问题，垃圾回收后的空间不是连续的，会产生大量碎片，不连续的内存空间的工作效率要低于连续的内存空间；另一个是效率问题，如果需要标记的对象太多，效率不高。

3.3 标记-压缩法

标记压缩法（标记-整理法）在标记-清除法基础上做了优化，标记过程和标记-清除法一样，然后把存活的对象压缩到内存一端，对另一端的内存进行垃圾清理。

4 垃圾收集器

垃圾收集算法偏向于理论层面，而垃圾收集器则可以看作是对理论的具体实现。

4.0 垃圾回收的停顿现象（SWT）

垃圾回收器的任务是识别和回收垃圾对象进行内存清理，为了让垃圾回收器可以高效的执行，大部分情况下，会要求系统进入一个停顿的状态。停顿的目的是终止所有应用线程，只有这样系统才不会有新的垃圾产生，同时停顿保证了系统状态在某一瞬间的一致性，也有益于更好的标记垃圾对象。

4.1 Serial收集器

启动参数：-XX:+UseSerialGC（年轻代minor gc） -XX:+UseSerialOldGC（老年代full gc）

它会使用一条垃圾收集线程去完成垃圾收集工作，在进行垃圾收集工作的时候必须暂停其他所有的工作线程（ "Stop The World" ），直到它收集结束。

年轻代采用复制算法，老年代采用标记-整理算法。

Serial Old收集器是Serial收集器的老年代版本

4.2 Parallel Scavenge收集器

启动参数：-XX:+UseParallelGC（年轻代）-XX:+UseParallelOldGC（老年代）

Parallel收集器是Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其余和Serial收集器类似。

默认的收集线程数跟cpu核数相同，可以用参数-XX:ParallelGCThreads指定收集线程数，但是一般不推荐修改。

新生代采用复制算法，老年代采用标记-整理算法。

Parallel Old收集器是Parallel Scavenge收集器的老年代版本。

Parallel Scavenge收集器和Parallel Old收集器是JDK8默认的新生代和老年代收集器。

4.3 ParNew收集器

启动参数：-XX:+UseParNewGC

ParNew收集器跟Parallel收集器类似，区别主要在于ParNew可以和CMS收集器配合使用。

新生代采用复制算法，老年代采用标记-整理算法。

4.4 CMS收集器

启动参数：-XX:+UseConcMarkSweepGC（老年代）

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用，它是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。

CMS收集器是基于 “标记-清除”算法实现的，它的运作过程更加复杂一些。整个过程分为几个步骤：

1. 初始标记： 暂停所有的其他线程(STW)，并记录下gc roots直接能引用的对象，速度很快。

2. 并发标记： 并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程， 这个过程耗时较长但是不需要停顿用户线程， 可以与垃圾收集线程一起并发运行。因为用户程序继续运行，可能会有导致已经标记过的对象状态发生改变。

3. 重新标记： 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短。主要用到三色标记里的增量更新算法做重新标记。

4. 并发清理： 开启用户线程，同时GC线程开始对未标记的区域做清扫。这个阶段如果有新增对象会被标记为黑色不做任何处理。

5. 并发重置：重置本次GC过程中的标记数据。

与Parallel区别：

1. Parallel Scavenge收集器关注点是吞吐量，CPU执行垃圾收集的时间越短，吞吐量越高；CMS等垃圾收集器的关注的是减少用户线程的停顿时间，提高用户体验。

2. Parallel整体垃圾收集的时间短，所有线程集中精力去进行垃圾收集，但是全程STW；CMS执行垃圾收集过程中还要分配一些CPU资源给到应用程序，整体垃圾收集的时间长，但是STW时间缩短。

3. 如果内存不是很大，则使用默认的Parallel即可；如果内存较大，则推荐使用CMS，用户体验会更好。

CMS缺点：

1. 对CPU资源敏感，会和服务抢资源；

2. 无法处理浮动垃圾(在并发标记和并发清理阶段又产生垃圾，这种浮动垃圾只能等到下一次gc再清理了)；

3. 它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生，可以让jvm在执行完标记清除后再做整理；

4. 执行过程中的不确定性，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况，特别是在并发标记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就再次触发full gc，也就是"concurrent mode failure"，此时会进入stop the world，用serial old垃圾收集器来回收

CMS的相关核心参数

1. -XX:+UseConcMarkSweepGC：启用cms

2. -XX:ConcGCThreads：并发的GC线程数

3. -XX:+UseCMSCompactAtFullCollection：FullGC之后做压缩整理（减少碎片）

4. -XX:CMSFullGCsBeforeCompaction：多少次FullGC之后压缩一次，默认是0，代表每次FullGC后都会压缩一次

5. -XX:CMSInitiatingOccupancyFraction: 当老年代使用达到该比例时会触发FullGC（默认是92，这是百分比）

6. -XX:+UseCMSInitiatingOccupancyOnly：只使用设定的回收阈值(-XX:CMSInitiatingOccupancyFraction设定的值)，如果不指定，JVM仅在第一次使用设定值，后续则会自动调整

7. -XX:+CMSScavengeBeforeRemark：在CMS GC前启动一次minor gc，目的在于减少老年代对年轻代的引用，降低CMS GC的标记阶段时的开销，一般CMS的GC耗时 80%都在标记阶段

8. -XX:+CMSParallellnitialMarkEnabled：表示在初始标记的时候多线程执行，缩短STW

9. -XX:+CMSParallelRemarkEnabled：在重新标记的时候多线程执行，缩短STW;

（虚拟机参数：-、-X、-XX...其中X越多，说明该命令越不稳定，未来版本可能会废除；X越少越稳定，例如java -version。）

4.5 G1收集器

启动参数：-XX:+UseG1GC

内存划分

G1将Java堆划分为多个大小相等的独立区域（Region），JVM最多可以有2048个Region。

G1保留了年轻代和老年代的概念，但都是可以不连续的Region的集合，不再是物理上的整块内存划分。

Region的区域功能可能会动态变化，一个Region可能之前是年轻代，进行了垃圾回收之后可能又会变成老年代。

默认年轻代对堆内存的占比是5%，可以通过“-XX:G1NewSizePercent”设置新生代初始占比。在系统运行中，JVM会不停的给年轻代增加更多的Region，但是最多新生代的占比不会超过60%，可以通过“-XX:G1MaxNewSizePercent”调整。

G1收集器对大对象的处理有所不同，G1有专门分配大对象的Region叫Humongous区，而不是让大对象直接进入老年代的Region中。在G1中，大对象的判定规则就是一个大对象超过了一个Region大小的50%，而且一个大对象如果太大，可能会横跨多个Region来存放。

Humongous区专门存放短期巨型对象，不用直接进老年代，可以节约老年代的空间，避免因为老年代空间不够的GC开 销。

执行过程

1. 初始标记（initial mark，STW）：暂停所有的其他线程，并记录下gc roots直接能引用的对象，速度很快 ；

2. 并发标记（Concurrent Marking）：同CMS的并发标记

3. 最终标记（Remark，STW）：同CMS的重新标记

4. 筛选回收（Cleanup，STW）：筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间(可以用JVM参数 -XX:MaxGCPauseMillis指定)来制定回收计划，这个阶段因为只回收一部分Region，时间是用户可控制的，停顿用户线程将大幅提高收集效率。不管是年轻代或是老年代，回收算法主要用的是复制算法，将一个region中的存活对象复制到另一个region中，这种不会像CMS那样回收完因为有很多内存碎片还需要整理一次，G1采用复制算法回收几乎不会有太多内存碎片。

G1收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的Region，比如一个Region花200ms能回收10M垃圾，另外一个Region花50ms能回收20M垃圾，在回收时间有限情况下，G1当然会优先选择后面这个Region回收。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限时间内可以尽可能高的收集效率。

可以由用户指定期望的停顿时间是G1收集器很强大的一个功能， 设置不同的期望停顿时间， 可使得G1在不同应用场景中取得关注吞吐量和关注延迟之间的最佳平衡。 不过设置的“期望值”必须是符合实际的，通常把期望停顿时间设置为100～300ms会是比较合理的。

G1垃圾收集分类

YoungGC

YoungGC并不是说现有的Eden区放满了就会马上触发，G1会计算下现在Eden区回收大概要多久时间，如果回收时间远远小于参数 -XX:MaxGCPauseMills 设定的值，那么增加年轻代的region，继续给新对象存放，不会马上做Young GC，直到下一次Eden区放满，G1计算回收时间接近参数 -XX:MaxGCPauseMills 设定的值，那么就会触发Young GC

MixedGC

不是FullGC，老年代的堆占有率达到参数(-XX:InitiatingHeapOccupancyPercent)设定的值则触发，回收所有的Young和部分Old(根据期望的GC停顿时间确定old区垃圾收集的优先顺序)以及大对象区，正常情况G1的垃圾收集是先做MixedGC，主要使用复制算法，需要把各个region中存活的对象拷贝到别的region里去，拷贝过程中如果发现没有足够的空region能够承载拷贝对象就会触发一次Full GC

Full GC

停止系统程序，然后采用单线程进行标记、清理和压缩整理，好空闲出来一批Region来供下一次MixedGC使用，这个过程是非常耗时的。(Shenandoah优化成多线程收集了)

G1收集器参数设置

-XX:+UseG1GC:使用G1收集器

-XX:ParallelGCThreads:指定GC工作的线程数量

-XX:G1HeapRegionSize:指定分区大小(1MB~32MB，且必须是2的N次幂)，默认将整堆划分为2048个分区

-XX:MaxGCPauseMillis:目标暂停时间(默认200ms)

-XX:G1NewSizePercent:新生代内存初始空间(默认整堆5%)

-XX:G1MaxNewSizePercent:新生代内存最大空间

-XX:TargetSurvivorRatio:Survivor区的填充容量(默认50%)，Survivor区域里的一批对象(年龄1+年龄2+年龄n的多个年龄对象)总和超过了Survivor区域的50%，此时就会把年龄n(含)以上的对象都放入老年代

-XX:MaxTenuringThreshold:最大年龄阈值(默认15)

-XX:InitiatingHeapOccupancyPercent:老年代占用空间达到整堆内存阈值(默认45%)，则执行MixedGC，比如我们之前说的堆默认有2048个region，如果有接近1000个region都是老年代的region，则可能就要触发MixedGC了

-XX:G1MixedGCLiveThresholdPercent(默认85%) region中的存活对象低于这个值时才会回收该region，如果超过这个值，存活对象过多，回收的的意义不大。

-XX:G1MixedGCCountTarget:在一次回收过程中指定做几次筛选回收(默认8次)，在最后一个筛选回收阶段可以回收一会，然后暂停回收，恢复系统运行，一会再开始回收，这样可以让系统不至于单次停顿时间过长。

-XX:G1HeapWastePercent(默认5%): gc过程中空出来的region是否充足阈值，在混合回收的时候，对Region回收都是基于复制算法进行的，都是把要回收的Region里的存活对象放入其他Region，然后这个Region中的垃圾对象全部清理掉，这样的话在回收过程就会不断空出来新的Region，一旦空闲出来的Region数量达到了堆内存的5%，此时就会立即停止混合回收，意味着本次混合回收就结束了。

G1垃圾收集器优化建议

核心还是在于调节 -XX:MaxGCPauseMills 这个参数的值，在保证他的年轻代gc别太频繁的同时，还得考虑每次gc过后的存活对象有多少,避免存活对象太多快速进入老年代，频繁触发mixed gc.

适用场景

1. 50%以上的堆被存活对象占用

2. 对象分配和晋升的速度变化非常大

3. 垃圾回收时间特别长，超过1秒

4. 8GB以上的堆内存(建议值)

5. 停顿时间是500ms以内

Shenandoah可以看成是G1的升级版本，G1在筛选回收阶段没实现并发回收，不过到了Shenandoah就实现了并发收集。

4.6 ZGC收集器

ZGC是一款JDK 11中新加入的以低延迟为首要目标的一款垃圾收集器，没有分代，使用了读屏障、 颜色指针等技术来实现可并发的标记-整理算法。

启动参数：-XX:+UseZGC

内存划分

ZGC的Region具有大、 中、 小三类容量：

1. 小型区域（Small Region）：容量固定为2MB， 用于放置小于256KB的小对象。

2. 中型区域（Medium Region）：容量固定为32MB， 用于放置大于等于256KB但小于4MB的对象。

3. 大型区域（Large Region）：容量不固定，可以动态变化，但必须为2MB的整数倍， 用于放置4MB或以上的大对象。 每个大型Region中只会存放一个大对象，最小容量可低至4MB。 大型Region在ZGC的实现中是不会被重分配， 因为复制一个大对象的代价非常高昂。

执行过程

1. 并发标记（Concurrent Mark）

2. 并发预备重分配（Concurrent Prepare for Relocate）

3. 并发重分配（Concurrent Relocate）

4. 并发重映射（Concurrent Remap）

ZGC目标

1. 支持TB量级的堆。

2. 最大GC停顿时间不超10ms。

3. 奠定未来GC特性的基础。

4. 最糟糕的情况下吞吐量会降低15%。

ZGC存在的问题

ZGC最大的问题是浮动垃圾。

1.ZGC的停顿时间是在10ms以下，但是ZGC的执行时间是远远大于这个时间的。执行垃圾收集期间，由于对象分配速率很高，将创建大量的新对象，这些对象很难进入当次GC，所以只能在下次GC的时候进行回收；

2.ZGC没有分代概念，每次都需要进行全堆扫描，导致一些生命周期本该很短对象没能及时被回收。

目前办法是增大堆的容量，使得程序得到更多的喘息时间；需要引入分代收集，让新生对象都在一个专门的区域中创建，然后专门针对这个区域进行更频繁、更快的收集。

4.7 如何选择垃圾收集器

1. 优先调整堆的大小让服务器自己来选择

2. 如果内存小于100M，使用串行收集器

3. 如果是单核，并且没有停顿时间的要求，串行或JVM自己选择

4. 如果允许停顿时间超过1秒，选择并行或者JVM自己选

5. 如果响应时间最重要，并且不能超过1秒，使用并发收集器

6. 4G以下可以用parallel，4-8G可以用ParNew+CMS，8G以上可以用G1，几百G以上用ZGC

JDK 1.8默认使用 Parallel(年轻代和老年代都是)

JDK 1.9默认使用 G1

5 垃圾收集底层算法

5.1 三色标记

在并发标记的过程中，因为标记期间应用线程还在继续跑，对象间的引用可能发生变化，就会导致多标和漏标的情况。而三色标记就是把GC Roots可达性分析遍历对象过程中遇到的对象， 按照“是否访问过”这个条件标记成以下三种颜色（标记在对象头中的GC标记）：

• 黑色： 表示对象已经被垃圾收集器访问过， 且这个对象的所有引用都已经扫描过。 黑色的对象代表已经扫描过， 它是安全存活的， 如果有其他对象引用指向了黑色对象， 无须重新扫描一遍。 黑色对象不可能直接（不经过灰色对象） 指向某个白色对象。

• 灰色： 表示对象已经被垃圾收集器访问过， 但这个对象上至少存在一个引用还没有被扫描过。

• 白色： 表示对象尚未被垃圾收集器访问过。 显然在可达性分析刚刚开始的阶段， 所有的对象都是白色的， 若在分析结束的阶段， 仍然是白色的对象， 即代表不可达。

多标-浮动垃圾

在并发标记和并发清理过程中，由于应用程序继续执行，所以可能会导致部分GC Root被销毁，例如由于方法运行结束导致部分局部变量被销毁，但是这个GC Root引用的对象之前又被标记为非垃圾对象。这种在并发标记和并发清理阶段又产生垃圾，被称之为“浮动垃圾”，那浮动垃圾本轮GC不会回收，需要等到下一轮垃圾回收中才被清除， 浮动垃圾并不会影响垃圾回收的正确性。

另外，针对并发标记和并发清理开始后产生的新对象，通常的做法是直接全部当成黑色，本轮不会进行清除。这部分对象期间可能也会变为垃圾，这也算是浮动垃圾的一部分。

漏标-读写屏障

漏标会导致被引用的对象被当成垃圾误删除，这是严重bug，必须解决，有两种解决方案： 增量更新（Incremental Update）和原始快照（Snapshot At The Beginning，SATB）。

增量更新就是当黑色对象插入新的指向白色对象的引用关系时， 就将这个新插入的引用记录下来， 等并发扫描结束之后， 再将这些记录过的引用关系中的黑色对象为根， 重新扫描一次。 这可以简化理解为， 黑色对象一旦新插入了指向白色对象的引用之后， 它就变回灰色对象了。

原始快照就是当灰色对象要删除指向白色对象的引用关系时， 就将这个要删除的引用记录下来， 在并发扫描结束之后，再将这些记录过的引用关系中的灰色对象为根， 重新扫描一次，这样就能扫描到白色的对象，将白色对象直接标记为黑色(目的就是让这种对象在本轮gc清理中能存活下来，待下一轮gc的时候重新扫描，这个对象也有可能是浮动垃圾)

以上无论是对引用关系记录的插入还是删除， 虚拟机的记录操作都是通过写屏障实现的。

对于读写屏障，以Java HotSpot VM为例，其并发标记时对漏标的处理方案如下：

CMS：写屏障 + 增量更新

G1，Shenandoah：写屏障 + SATB

ZGC：读屏障

为什么G1用SATB？CMS用增量更新？

5.2 颜色指针

ZGC的核心设计之一。以前的垃圾回收器的GC信息都保存在对象头中， 而ZGC的GC信息保存在指针中，标记阶段会更新染色指针中的Marked 0、 Marked 1标志位。

每个对象有一个64位指针，这64位被分为：

• 18位：预留给以后使用；

• 1位：Finalizable标识，此位与并发引用处理有关，它表示这个对象只能通过finalizer才能访问；

• 1位：Remapped标识，设置此位的值后，对象未指向relocation set中（relocation set表示需要GC的Region集合）；

• 1位：Marked1标识；

• 1位：Marked0标识，和上面的Marked1都是标记对象用于辅助GC；

• 42位：对象的地址（所以它可以支持2^42=4T内存）。

 

5.3 读屏障

ZGC非常重要的特性。以前的GC都是采用写屏障，而ZGC采用了读屏障。