JVMGC知识整理

CMS基于 标记-清除算法实现

G1的设计原则就是简单可行的性能调优

font color=\"#23263b\

新生代

垃圾收集器结构图

从GCROOTS开始向下遍历引用，将不可达的对象进行标记

初始标记(CMS initial mark) -stop the world

Full GC 触发场景

三色标记它只是标记还没有清除的操作，一般方式在需要并发标记时

概念补充

JVM GC 算法

Mix GC

Remembered Set的概念

单线程，一个CPU或一条收集线程去完成垃圾收集工作，收集时必须暂停其他所有的工作线程，直到它结束。是虚拟机运行在Client模式下的默认新生代收集器。

Humongous区域

Serial收集器 复制算法

ParNew收集器 复制算法

G1收集器

解决了效率问题，且没有内存碎片问题每次GC都将存活的对象放入另一个Survivor区，清楚当前的Survivor区。

从GC roots开始可达性算法可以知道根对象，所有的根对象会标为黑色。黑色：所有的引用都已经扫描过灰色：至少还有一个引用没有被扫描。白色：没被垃圾收集器扫描到

指用户线程与垃圾收集线程同时执行(但不一定是并行的，可能会交替执行)，用户程序再继续运行，而垃圾收集程序运行于另一个CPU上。

concurrent mode failure是在执行CMS GC的过程中同时有对象要放入老年代，而此时老年代空间不足造成的。CMS 收集器的预留空间问题导致

缺点

有大对象或大数组转入老年代时，老年代空间不足是触发

G1将新生代，老年代的物理空间划分取消了。

Serial Old收集器 标记-整理

存在的问题多线程的情况下会出现不稳定现象。多线程可能会破坏原有的引用链路。STW时间长

Parallel Old收集器 标记-整理

并发清除(CMS concurrent sweep)

promotionfailed是在进行Minor GC时，survivor space放不下、对象只能放入老年代，而此时老年代也放不下造成的。担保机制导致的

-XX:+UseG1GC -Xmx32g -XX:MaxGCPauseMillis=200其中-XX:+UseG1GC为开启G1垃圾收集器，-Xmx32g 设计堆内存的最大内存为32G，-XX:MaxGCPauseMillis=200设置GC的最大暂停时间为200ms。如果我们需要调优，在内存大小一定的情况下，我们只需要修改最大暂停时间即可。

垃圾收集器

效率不高。产生内存碎片。

GC是会触发Stop the world。阻塞所有用户线程，保证GC时不出现对象引用变更。

分代算法

Full GC

Parallel Scavenge 收集器的特点是它的关注点是吞吐量。高吞吐量则可以高效地利用CPU时间，主要适合在后台运算而不需要太多交互的任务

重新标记(CMS remark) -stop the world

并发收集，低停顿。

Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器。给Client模式下的虚拟机使用。新生代采用复制算法，暂停所有用户线程；老年代采用标记-整理算法，暂停所有用户线程；

CMS((Concurrent Mark Sweep)收集器 标记-清除

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

三色标记

young GC

将需要被清理的对象进行标记出来，然后将未被标记出来的所有对象进行移动，形成一个连贯的内存空间，然后从这个空间的尾部到内存边界的空间清除。

Parallel Scavenge收集器 复制算法

PermanetGeneration中存放的为一些class的信息等，当系统中要加载的类、反射的类和调用的方法较多时，Permanet Generation可能会被占满，在未配置为采用CMS GC的情况下会执行Full GC

并发标记(CMS concurrent mark)

标记算法的起始对象方法栈的对象引用、本地方法栈的对象引用、元空间的静态对象的引用、final对象的引用等

老年代

会有很多内存碎片，空间不够新生代过来的大对象时会提前触发FullGC

G1调优

STW

标记-复制

由于CMS运行时还需要给用户空间继续运行，则不能等老年代几乎被填满再进行收集，需要预留一部分空间提供并发收集时，用户程序运行。若预留内存不够用户使用，则出现一次Concurent Mode Failure失败。span style=\

如果一个对象占用的空间超过了分区容量50%以上，G1收集器就认为这是一个巨型对象。这些巨型对象，默认直接会被分配在年老代，但是如果它是一个短期存在的巨型对象，就会对垃圾收集器造成负面影响。为了解决这个问题，G1划分了一个Humongous区，它用来专门存放巨型对象。如果一个H区装不下一个巨型对象，那么G1会寻找连续的H分区来存储。为了能找到连续的H区，有时候不得不启动Full GC。

Minor GC

PS:存活的对象大于另一个S区的空间会走分配担保机制进入老年代

指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。

GC ROOT

并行Parelel

这是一个较为复杂的触发情况，Hotspot为了避免由于新生代对象晋升到旧生代导致旧生代空间不足的现象，在进行Minor GC时，做了一个判断，如果之前统计所得到的Minor GC晋升到旧生代的平均大小大于旧生代的剩余空间，那么就直接触发Full GC。

并发Concurrent

标记-整理

CMS垃圾收集器流程

标记-清除

优点

以最短回收停顿时间为目标的收集器

是Parallel Scavenge收集器的老年代版本，使用多线程和\"标记－整理\"算法。

CMS GC出现promotion failed Orconcurrent mode failure。

可以开启-XX:+UseCMSCompactAtFullCollection(默认开)，在CMS顶不住要FullGC时开启内存碎片合并整理过程。内存整理过程是无法并发的，空间碎片问题没了，但停顿时间变长。

在初始标之前，有一个安全区的概念，就是认为代码的执行区域内已经不会再发生对象引用变更了，只有这个时候才会进入到初始标记

统计得到的Minor GC晋升老年代的平均大小大于老年代的剩余空间

可达性标记

标记出需要回收的对象，标记完后统一回收

ParNew是Serial收集器的多线程版本。Server模式下默认新生代收集器，除了Serial收集器之外，只有它能与CMS收集器配合工作。

采用的三色标记法

CMS收集器对CPU资源非常敏感。默认启动的回收线程数是(CPU+3)/4. 当CPU 4个以上时，并发回收垃圾收集线程不少于25%的CPU资源。

不用单独的空间对每个代进行设置了，不用担心每个代内存是否足够。G1算法将堆划分为若干个区域（Region），它仍然属于分代收集器。新生代依然采用以前的方式进行GC。其次因为分区的原因，老年代上采用了类似复制算法的方式，将数据复制到另一个区中，完成清理工作，也没有了CMS的内存碎片问题。

eden survivor复制过程概述

存在的问题并发场景下，引用关系的变更产生的多标和漏标。解决办法：多标就是被用户线程断掉了引用，本次已经被标记为灰色或黑色。这其实浮动垃圾，下次清掉就好不用刻意处理。漏标：原本该被标记为可达的对象，被用户线程断开了引用重新被黑色对象引用。即用户线程还是需要该对象的，但是GC线程认为这个对象没有灰色对象的引用，因为被用户线程断了，所以无法将该对象标记，会导致被清除影响程序正确性。其次是因为GC线程恢复执行时不会重新从黑色对象开始向下检测可达性。解决办法：CMS:增量更新，将黑色对象新插入的白色对象引用记录下来，等标记结束重新扫描一遍这条黑色对象的链路。问题是会影响效率。G1:原始快照法，将被灰色对象断开的白色对象这样的关系记录下来，标记结束后，重新扫描一遍这个灰色对象的链路，会直接变成黑色。问题是会产生浮动垃圾。