深入理解G垃圾收集器.docxVIP

深化理解G1垃圾收集器 2021-09-23 G1 GC是Jdk7的新特性之一、Jdk7+版本都可以自主配置G1作为JVM GC选项；作为JVM GC算法的一次严重升级、DK7u后G1已相对稳定、且将来方案替代CMS、所以有必要深化了解下： 不同于其他的分代回收算法、G1将堆空间划分成了相互独立的区块。每块区域既有可能属于O区、也有可能是Y区，且每类区域空间可以是不连续的（对比CMS的O区和Y区都必需是连续的）。这种将O区划分成多块的理念源于：当并发后台线程查找可回收的对象时、有些区块包含可回收的对象要比其他区块多很多。虽然在清理这些区块时G1仍旧需要暂停应用线程、但可以用相对较少的时间优先回收包含垃圾最多区块。这也是为什么G1命名为Garbage First的缘由：第一时间处理垃圾最多的区块。 平常工作中大多数系统都使用CMS、即便静默升级到JDK7默认仍旧接受CMS、那么G1相对于CMS的区分在： G1在压缩空间方面有优势 G1通过将内存空间分成区域（Region）的方式避开内存碎片问题 Eden, Survivor, Old区不再固定、在内存使用效率上来说更机警 G1可以通过设置预期停连忙间（Pause Time）来把握垃圾收集时间避开应用雪崩现象 G1在回收内存后会马上同时做合并空闲内存的工作、而CMS默认是在STW（stop the world）的时候做 G1会在Young GC中使用、而CMS只能在O区使用 就目前而言、CMS还是默认首选的GC策略、可能在以下场景下G1更适合： 服务端多核CPU、JVM内存占用较大的应用（至少大于4G） 应用在运转过程中会产生大量内存碎片、需要经常压缩空间 想要更可控、可预期的GC停顿周期；防止高并发下应用雪崩现象 一次完整G1GC的具体过程： G1在运转过程中次要包含如下4种操作方式： YGC（不同于CMS） 并发阶段 混合模式 full GC （一般是G1消灭问题时发生） YGC： 下面是一次YGC前后内存区域是示意图： 图中每个小区块都代表G1的一个区域（Region），区块里面的字母代表不同的分代内存空间类型（如[E]Eden,[O]Old,[S]Survivor）空白的区块不属于任何一个分区；G1可以在需要的时候任意指定这个区域属于Eden或是O区之类的。G1 YoungGC在Eden布满时触发，在回收之后全部之前属于Eden的区块全变成空白。然后至少有一个区块是属于S区的（如图半满的那个区域），同时可能有一些数据移到了O区。 目前淘系的应用大都使用PrintGCDetails参数打出GC日志、这个参数对G1同样有效、但日志内容颇为不同；下面是一个Young GC的例子： 23.430: [GC pause (young), 0secs]...[Eden: 1286M(1286M)-0B(1212M)Survivors: 78M-152M Heap: 1454M(4096M)-242M(4096M)][Times: user=0.85 sys=0.05, real=0.23 secs] 上面日志的内容解析：Young GC实际占用230毫秒、其中GC线程占用850毫秒的CPU时间E：内存占用从1286MB变成0、都被移出S：从78M增长到了152M、说明从Eden移过来74MHeap:占用从1454变成242M、说明这次Young GC一共释放了1212M内存空间很多情况下，S区的对象会有部分晋升到Old区，另外假如S区已满、Eden存活的对象会直接晋升到Old区，这种情况下Old的空间就会涨 并发阶段： 一个并发G1回收周期前后内存占用情况如下图所示： 从上面的图表可以看出以下几点：1、Young区发生了变化、这意味着在G1并发阶段内至少发生了一次YGC（这点和CMS就有区分），Eden在标记之前已经被完全清空，由于在并发阶段应用线程同时在工作、所以可以看到Eden又有新的占用2、一些区域被X标记，这些区域属于O区，此时仍旧有数据存放、不同之处在G1已标记出这些区域包含的垃圾最多、也就是回收收益最高的区域3、在并发阶段完成之后实际上O区的容量变得更大了（O+X的方块）。这时由于这个过程中发生了YGC有新的对象进入所致。此外，这个阶段在O区没有回收任何对象：它的作用次要是标记出垃圾最多的区块出来。对象实际上是在后面的阶段真正开头被回收 G1并发标记周期可以分成几个阶段、其中有些需要暂停应用线程。第一个阶段是初始标记阶段。这个阶段会暂停全部应用线程-部分缘由是这个过程会执行一次YGC、下面是一个日志示例： 50.541: [GC pause (young) (initial-mark), 0sec