大家好，又见面了，我是你们的朋友全栈君。
CMS垃圾收集器的弊端：会产生内存碎片 && 需要预留空间。
这两个问题在处理时，很有可能会导致停顿时间过长，即CMS的停顿时间不可预知。
所以G1又可以理解为在CMS垃圾收集器上进行了”升级”。
G1垃圾收集器可以给你设定一个你希望Stop the world停顿时间，G1会根据这个时间尽量满足你。
在JVM堆中，堆的内存分布是以物理空间进行隔离——
但是在G1垃圾收集器中，堆的划分不再是物理形式，而是以逻辑的形式进行划分。
但是，分代的概念在G1中依旧奏效，比如，新对象一般会被分配到Eden区，经过15次Minor GC新生代的对象如果还存活，会移交到老年代等等…
以下为G1中【堆】的空间分布——
从图中可以发现，堆被划分了多个同等份的区域，在G1中每个区域叫Region。
在以前的垃圾收集器都是对堆进行物理划分，如果堆空间(内存)大的时候，每次进行【垃圾回收】都需要堆一整块大的区域进行回收，那收集的时间不好控制，而划分了多个小区域后，对【小区域】的回收就容易控制它的【收集时间】
在G1中，还有一种Humongous(大对象)区域，其实就是来存储特别大的对象(大于region内存的一半).一旦发现没有引用指向大对象，就可直接在年轻代的Minor GC中被回收。
G1的GC过程
在G1收集器中，可以主要分为有Minor GC(young GC)和Mixed GC，也有写特殊场景会发生full GC
Minor GC
G1的Minor GC触发时机与其他的垃圾收集器一样：
等Eden区满了之后，会触发Minor GC。Minor GC同样也是会发生Stop the world.
值得注意的是，在G1的世界里，新生代和老年代所占堆的空间是没那么固定的，会根据【最大停顿时间】进行调整。
这块要知道会给我们提供参数进行配置即可。根据参数动态地改变年轻代Region的个数可以控制Minor GC的开销
Minnor GC的回收过程：
- 根扫描
- 更新 && 处理Rset
- 复制对象
根扫描
与之前的CMS类似，可以理解为初始标记的过程
更新 && 处理Rset
Rset概念： 在CMS中Minor GC是通过【卡表】来避免全表扫描老年代的对象。因为Minor GC是回收年轻代的对象，但如果老年代有对象引用着年轻代，那这些被老年代引用的对象就不能被回收。
同样的，在G1中也存在这种问题。在CMS中叫卡表，G1解决【跨代引用】的问题的存储一般称为RSet
RSet存储在每个Region中，它记录着其他Region引用了当前Region的对象关系。
对于年轻代的Region，它的RSet只保存了来自老年代的引用，因为年轻代自己都要做Minor GC了。
对于老年代的Region，它的RSet只会保存老年代对它的引用，因为在G1收集器，老年代回收之前，都会先对年轻代进行回收，所以没必要保存年轻代的引用。
所以第二步就是：处理RSet的信息并且扫描，将老年代对象持有年轻代对象的相关引用到加入到GC Roots下，避免被回收。
复制对象
把扫描之后存活的对象往【空的Survivor区】或者【老年代】存放，其他的Eden区进行清除。
另外，在G1中还有另一个名字：CSet，Collection
Set，保存了一次GC中【将执行垃圾回收】的Region。CSet中的所有存活对象都会被转移到别的可用Region上
总结：扫描、处理跨Region引用，收集至CSet，复制清除、处理引用。
Mixed GC
当堆空间的占用率达到一定阈值后会触发Mixed GC(默认45%，由参数决定)。Mixed GC会依赖全局并发标记统计后的Region数据
全局并发标记：
- 初始标记（STW）
- 并发标记
- 最终标记（STW）
- 清理（STW）
从名字可以知道，Mixed GC是一个混合GC，Mixed GC一定会回收年轻代，并会采集部分老年代的Region进行回收。
初始标记
这个过程共用了Minor GC的Stop the world，复用了扫描GC Roots的操作。
在这个过程中，老年代和新生代都会被扫描
并发标记
这个阶段不会stop the world，GC线程与用户线程一起执行，GC线程负责收集各个Region的存活对象信息。从GC Roots往下追溯，查找这个堆存活的对象，比较耗时。
重新标记
与CMS一样，标记那些在并发标记阶段发生变化的对象。
清理
这个阶段也会stop the world，主要清点和重置标记状态，会根据停顿预测模型来决定本次GC多少Region.
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/134583.html原文链接：https://javaforall.net
