垃圾回收器详解

前言

        作为一个博客小白，均篇阅读量都是个位。突然发现了一个阅读量过百的，还是很快乐的，不光是自己学习，能分享给各位朋友也是一种很快乐的事情。或许大家更喜欢去看jvm的底层一些东西，其实 jdk 到现在的版本都已经到17了，里面很多内容都不怎么需要我们去调优了（当然是大部分开发情况下）了解jvm底层内容更多的是为了面试。我觉得，不管是面试，还是自己想去了解。当我们有一天真的遇到了各种各样得情况，还能想到我曾经看到过这么一篇有提到过，了解过这其中原理，小弟就很知足了。

        好了，闲话就不扯了，进入正题。关于垃圾回收器，大家也是经常听到过。但是具体有哪些。然后这些垃圾回收又是怎么回收得，可能就不咋个关注了。就像我刚才提到得一样，jvm其实默认给我们都做好了这些事情。我们平常在工作中也没有特别去指定什么垃圾回收。没关系，相信大家看完以后就会有一个想法，根据自己得实际情况去选择了。

垃圾回收算法

        

        Mark-Sweep（标记-清除）算法

                从字面看就能看出，分为两步：标记   清除 。这个是最简单的回收算法，最容易实现

       标记需要存活的对象，回收未被标记的对象（一般是这种），也可以标记不需要存活的对象

       回收标记的对象

                

         标记清除算法虽然简单，但是问题也是比较明显的

                1. 效率问题，如果需要标记的内容比较多，那么标记起来肯定慢（不管标记那种）

                2. 空间问题，清除后，会有大量的碎片出现（不连续的内存空间）

        Mark-Compact（标记-整理）算法     --  也叫压缩算法

                标记和前面的标记-清除算法一致。只是标记完了不是直接清除，将所有存活对象向一

        端移动，移动时可能就直接放到需要回收的位置，然后清除掉界外的对象。

                

         

        Copying（标记-复制）算法

                这个也比较简单，就是把内存分为两块，每次使用一半，这一半使用完了，就把需要保

        存的内容复制到另一半

                

                ps:  复制比标记清除和标记整理差不多要快十倍左右，只是用空间来换取时间

         Generational Collection（分代收集算法）

                目前的 jvm 都使用分代收集，但我感觉它不像个算法，更像是个使用方法（或者叫算

        法的算法，个人理解，有问题请指正），通过分代（年轻代，老年代）来使用上面的算法

        达到更高的效率

                上面三种算法都有对应的优缺点，我们结合我们的分代思想分析下：

        新生代里面90%以上的都是朝生夕死的对象，一般都是使用复制算法，用空间代价来换取

        时间代价，老年代里面的对象很多都是长期存活，而且相对来说占用容量也比较大，复制算

        法明显就不太适用，我们就只能选择，标记清除或者标记整理。一般是使用标记整理算法：

                老年代 Full GC 才会回收,Full GC不会太频繁（不然就该优化了）整理的那一点时间

        开销能接受，整理后也方便存放大对象到老年代，不然如果是标记清除，当老年代连续空间

        不够，仅仅是大对象造成的Full GC也没有必要

垃圾回收器

        讲收集器之前，我们来先了解一个收集器里面重要的东西叫  STW(stop the world)，从单词我们就可以读出 “暂停世界” 。jvm在回收垃圾时，暂停其他所有的工作线程，直至回收结束

        思考下为啥要stw? 不stw会带来什么后果？ stw又会造成什么影响？带着这个疑问我们再来看回收器都是在干嘛

 

serial 收集器(-XX:+UseSerialGC-XX:+UseSerialOldGC)

        也叫串行收集器，最老最基本的回收器了，单线程的回收，现在基本已经没用了。它的新生

代使用 复制算法 老年代使用 标记-整理 算法  流程如下图（结合图考虑下stw）：

        

parallel scavenge收集器

        (-XX:+UseParallelGC(年轻代),-XX:+UseParallelOldGC(老年代))

         serial 收集器的多线程版本，除了多线程回收（线程数默认和cpu核数一致），其他的东西都

和 serial 一样 算法 stw 等等，cpu是多核的时候效率比serial高

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

        jdk1.8默认使用的收集器就是这两个收集器：新生代 Parallel Scavenge 老年代 Parallel Old

        这两个收集器关注的是cpu的吞吐量，下面介绍的cms或g1等等关注的是停顿时间（用户体验）

        吞吐量是值cpu用于处理用户代码的时间，与cpu总消耗时间的比值

ParNew 收集器 (-XX:+UseParNewGC)

        和 parallel 收集器很类似，区别是ParNew 可以配合CMS收集器使用，实现真正意义的并发收集，在正式环境使用比较多的（基本都是配合 cms）

CMS收集器 (-XX:+UseConcMarkSweepGC(old))

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

        cms收集器相对前面的收集器流程就复杂多了，算法也有差异，是使用标记-清除算法

步骤：

1. 初始标记   暂停其他线程，记录下 gc roots 所有能直接引用对象如 Object o = new Object()，不往下找，速度很快

2. 并发标记  耗时较长，但不用stw。gc roots 遍历整个对象图，虽然过程也会有标记过的对象改变，但是用户无感

3. 重新标记 为了修正并发标记期间改动的标记记录，也会stw,比初始标记长一点，但是比并发标记时间短，主要用到三色标记（下文会有详解）

4. 并发清理  开启线程对标记过的清理，期间产生的对象不处理，下次gc在处理

5. 并发重置 重置本次gc的标记数据

               cms的优缺点：

        优点：

                并发收集，停顿低。对比前面的收集器，他能做到真正的并发收集，收集的时候用户线程也在同时走，用户对停顿几乎无感 , 虽然中途也有两个地方有stw（初始标记，重新标记，有stw的地方箭头都是实心的，后面的流程图也是一样），因为这两做的事情是很快速，所以基本感觉不到停顿

        缺点：

         1. 会和cpu抢资源

         2. 浮动垃圾 并发标记和并发清理阶段又产生的垃圾，只能等到下一次清理

         3. 标记清除算法，产生大量空间碎片，可以设置  XX:+UserCMSCompactAtFullCollection 

                可以让jvm执行完垃圾回收再做整理

         4. 并发失败。收集期间，又来一个放不下的对象,再次触发 Full GC，没办法，全部stw 

                用 serial 单线程来做了

CMS的相关核心参数:

G1 收集器 (-XX:+UseG1GC)

        G1(Garbage-First)是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器.以极高概率满足GC停顿时间要求的同时,还具备高吞吐量性能特征.

        1：分代概念不一样了，划分很多大小相等的独立区域（Region），最多有2048个格子，每个格子等于堆大小/2048  如：堆大小4096M  那么每个格子就是2M大小

        2：G1保留了年轻代和老年代的概念，但是物理不连续，年轻代默认占比 5% ，以堆4096为例，新生代默认200M，运行中不够就继续调整增大，最大不超过60%。年轻代也是分为eden区和两个Survivor区，比例也是8：1：1  。一个格子可能第一次是年轻代，回收了后变成老年代，随时变动

        3：多了一个大对象（巨型对象）概念   对象超过了格子大小的50%，就是大对象Humongous区 比如一个格子2M 对象超过1M，放Humongous，如果比2M还大，那就多个格子来存放

        

以上是G1对比前面回收1器的区别，下面我们看下它的流程是什么样的：

        1. 初始标记(STW) 暂停其他线程，记录下 gc roots 所有能直接引用对象，同cms 

        2. 并发标记  同cms并发标记

        3. 最终标记(STW)  同cms 重新标记

        4. 筛选回收(STW)  筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间(可以用JVM参数-XX:MaxGCPauseMillis指定)来制定回收计划，比如说老年代此时有1000个Region都满了，但是因为根据预期停顿时间，本次垃圾回收可能只能停顿200毫秒，那么通过之前回收成本计算得知，可能回收其中800个Region刚好需要200ms，那么就只会回收800个Region(CollectionSet，要回收的集合)，尽量把GC导致的停顿时间控制在我们指定的范围内。这个阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。不管是年轻代或是老年代，回收算法主要用的是复制算法，将一个region中的存活对象复制到另一个region中，这种不会像CMS那样回收完因为有很多内存碎片还需要整理一次，G1采用复制算法回收几乎不会有太多内存碎片。(注意：CMS回收阶段是跟用户线程一起并发执行的，G1因为内部实现太复杂暂时没实现并发回收，不过到了Shenandoah就实现了并发收集，Shenandoah可以看成是G1的升级版本)

        G1收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的Region(这也就是它的名字Garbage-First的由来)，比如一个Region花200ms能回收10M垃圾，另外一个Region花50ms能回收20M垃圾，在回收时间有限情况下，G1当然会优先选择后面这个Region回收。

 特点：

1. 并行与并发：G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短STW停顿时间。部分其他收集器原本需要停顿Java线程来执行GC动作，G1收集器仍然可以通过并发的方式让java程序继续执行。

2. 空间整合：与CMS的“标记--清理”算法不同，G1从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的。

3. 分代收集：虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念。

4. 可预测的停顿：这是G1相对于CMS的另一个大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段(通过参数"-XX:MaxGCPauseMillis"指定)内完成垃圾收集。

 ps：

        可以由用户指定期望的停顿时间是G1收集器很强大的一个功能，设置不同的期望停顿时间，可使得G1在不同应用场景中取得关注吞吐量和关注延迟之间的最佳平衡。不过，这里设置的“期望值”必须是符合实际的，不能异想天开，毕竟G1是要冻结用户线程来复制对象的，这个停顿时间再怎么低也得有个限度。它默认的停顿目标为两百毫秒，一般来说，回收阶段占到几十到一百甚至接近两百毫秒都很正常，但如果我们把停顿时间调得非常低，譬如设置为二十毫秒，很可能出现的结果就是由于停顿目标时间太短，导致每次选出来的回收集只占堆内存很小的一部分，收集器收集的速度逐渐跟不上分配器分配的速度，导致垃圾慢慢堆积。很可能一开始收集器还能从空闲的堆内存中获得一些喘息的时间，但应用运行时间一长就不行了，最终占满堆引发FullGC反而降低性能，所以通常把期望停顿时间设置为一两百毫秒或者两三百毫秒会是比较合理的。

G1的GC

        YoungGC

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

        MixedGC

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

        FullGC

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

G1参数设置

G1的优化建议

        假设参数-XX:MaxGCPauseMills（目标暂停时间）设置的值很大，导致系统运行很久，年轻代可能都占用了堆内存的60%了，此时才触发年轻代gc。那么存活下来的对象可能就会很多，此时就会导致Survivor区域放不下那么多的对象，就会进入老年代中。或者是你年轻代gc过后，存活下来的对象过多，导致进入Survivor区域后触发了动态年龄判定规则，达到了Survivor区域的50%，也会快速导致一些对象进入老年代中。所以这里核心还是在于调节-XX:MaxGCPauseMills这个参数的值，在保证他的年轻代gc别太频繁的同时，还得考虑每次gc过后的存活对象有多少,避免存活对象太多快速进入老年代，频繁触发mixedgc.

适合使用G1的场景

        1.50%以上的堆被存活对象占用

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

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

        4.8GB以上的堆内存(建议值)

        5.停顿时间是500ms以内

ZGC收集器(-XX:+UseZGC)

        这个收集器简单说明下特点就好，详细运行流程就不细说了，估计一般也不怎么用到

        特点或目标：

        1. 支持TB量级的堆（所以大家一半是不会用到的，没几个互联网公司有用这么大的堆）

        2. 最大GC停顿时间不超10ms,几十G，几百G都是10ms以下（有点牛）

        3. 未来gc特性奠定基础（官网抄的，有点自吹的意思吧，不过等大了有可能）

        4. 最糟糕的情况下吞吐量会降低15%，停顿时间足够优秀。吞吐量通过扩容分分钟解决

        5. 不分代（暂时的）

 它的格子（Region）有大有小，2M  32M  还有一个动态变化（2的倍数）

 使用了读屏障、颜色指针等技术来实现可并发的标记-整理算法的

缺点：

        ZGC最大的问题是浮动垃圾。ZGC的停顿时间是在10ms以下，但是ZGC的执行时间还是远远大于这个时间的。假如ZGC全过程需要执行10分钟，在这个期间由于对象分配速率很高，将创建大量的新对象，这些对象很难进入当次GC，所以只能在下次GC的时候进行回收，这些只能等到下次GC才能回收的对象就是浮动垃圾。

总结

        再回头看下这些垃圾回收器，可以看到都是一个优化的过程，从单线程到多线程，再到并发无感回收，关键点就在cpu吞吐量 和 用户体验两个点上。相信看完大家也能明白前面的问题中的STW的问题了。

        关于如何选择垃圾回收器

                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   1.9默认使用G1

补充：三色标记

        在并发标记的过程中，使用三色标记来操作

        黑色：

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

        灰色：

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

        白色：

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

       三色标记会有两个重要的问题出现：多标和漏标

多标:  解决方案-浮动垃圾

        在并发标记过程中，如果由于方法运行结束导致部分局部变量(gcroot)被销毁，这个gcroot引用的对象之前又被扫描过(被标记为非垃圾对象)，那么本轮GC不会回收这部分内存。这部分本应该回收但是没有回收到的内存，被称之为“浮动垃圾”。浮动垃圾并不会影响垃圾回收的正确性，只是需要等到下一轮垃圾回收中才被清除。另外，针对并发标记(还有并发清理)开始后产生的新对象，通常的做法是直接全部当成黑色，本轮不会进行清除。这部分对象期间可能也会变为垃圾，这也算是浮动垃圾的一部分。

漏标：解决方案-读写屏障

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

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

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

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

        写屏障，就是赋值前后记录一下（类似Aop）

一个想过得更好的码农---邋遢道人