接上一篇博文，这篇博文讲下JVM中的G1垃圾收集器
G1在JDK1.7时引入，在JDK9时取代了CMS成为默认的垃圾收集器；
G1把Java堆划分为多个大小相等的独立区域Region，每个区域都可以扮演新生代（Eden和Survivor）或老年代的角色；同时，G1还有一个专门为大对象设计的Region，叫Humongous区。
- 补充：大对象的判定的规则是，如果一个大对象超过了一个Region大小的50%，比如每个Region是2M，只要一个对象超过了1M，就会被放入Humongous中；
这种区域化管理使得G1可以更灵活地进行垃圾收集，只回收部分区域而不是整个新生代或老年代；
那么，讲下G1收集器的大致运行过程吧；
大致可分为：
-
并发标记，G1通过并发标记的方式找出堆中的垃圾对象。并发标记阶段与应用线程同时执行，不会导致应用线程暂停；
-
混合收集，在并发标记完成后，G1会计算出哪些区域的回收价值最高（也就是包含最多垃圾的区域），然后优先回收这些区域。这种回收方式包括了部分新生代区域和老年代区域。
选择回收成本低而收益高的区域进行回收，可以提高回收效率和减少停顿时间；
-
可预测的停顿，G1在垃圾回收期间仍然需要STW，不过，G1在停顿时间上添加了预测机制，用户可以JVM启动时指定期望停顿时间，G1会尽可能地在这个时间内完成垃圾回收；
接下来，探讨对比下，为什么有了CMS，还要引入G1呢？
给出一张对比的表来回答这个问题吧！
| 特性 | CMS | G1 |
|---|---|---|
| 设计目标 | 低停顿时间 | 可以预测的停顿时间 |
| 并发性 | 是 | 是 |
| 内存碎片 | 是，容易产生碎片 | 否，通过区域划分和压缩减少碎片 |
| 收集代数 | 年轻代和老年代 | 整个堆，但区分年轻代和老年代 |
| 并发阶段 | 并发标记、并发清理 | 并发标记、并发清理、并发回收 |
| 停顿时间预测 | 较难预测 | 可配置停顿时间目标 |
| 容易出现的问题 | 内存碎片，Concurrent Mode Failure | 较少出现长时间停顿 |
由此对比，我们可以知道：
- CMS适用于对延迟敏感的应用场景，主要目标是减少停顿时间，但容易产生内存碎片。
- G1则提供了更好的停顿时间预测和内存压缩能力，适用于大内存和多核处理器环境。