携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第45天，点击查看活动详情
G1收集器
G1 GC是Jdk7的新特性之一、Jdk7+版本都可以自主配置G1作为JVM GC选项；作为JVM GC算法的一次重大升级、DK7u后G1已相对稳定、且未来计划替代CMS。 不同于其他的分代回收算法、G1将堆空间划分成了互相独立的区块。每块区域既有可能属于O区、也有可能是Y区，且每类区域空间可以是不连续的（对比CMS的O区和Y区都必须是连续的）。区别如下：
- G1在压缩空间方面有优势
- G1通过将内存空间分成区域（Region）的方式避免内存碎片问题
- Eden, Survivor, Old区不再固定、在内存使用效率上来说更灵活
- G1可以通过设置预期停顿时间（Pause Time）来控制垃圾收集时间避免应用雪崩现象
- G1在回收内存后会马上同时做合并空闲内存的工作、而CMS默认是在STW（stop the world）的时候做
- G1会在Young GC中使用、而CMS只能在O区使用
就目前而言、CMS还是默认首选的GC策略、可能在以下场景下G1更适合：
- 大量内存的系统提供一个保证GC低延迟的解决方案，也就是说堆内存在6GB及以上，稳定和可预测的暂停时间小于0.5秒。
- Full GC 次数太频繁或者消耗时间太长
- 应用在运行过程中会产生大量内存碎片、需要经常压缩空间
- 想要更可控、可预期的GC停顿周期；防止高并发下应用雪崩现象
- 对象分配的频率或代数提升(promotion)显著变化
- 受够了太长的垃圾回收或内存整理时间(超过0.5~1秒) 注意: 如果正在使用CMS或ParallelOldGC，而应用程序的垃圾收集停顿时间并不长，那么建议继续使用现在的垃圾收集器。使用最新的JDK时，并不要求切换到G1收集器。
- 内存模型：
G1堆由多个区（region）组成，每个区大小1M~32M，逻辑上区有3种类型，包括（Eden、Survivor、Old），按分代划分包括：年轻代（Young Generation）和老年代（Old Generation）。
如果从 ParallelOldGC 或者 CMS收集器迁移到 G1，可能会看到JVM进程占用更多的内存(a larger JVM process size)。 这在很大程度上与 “accounting” 数据结构有关，如 Remembered Sets 和 Collection Sets。 Remembered Sets 简称 RSets。跟踪指向某个heap区内的对象引用。 堆内存中的每个区都有一个 RSet。 RSet 使heap区能并行独立地进行垃圾集合。 RSets的总体影响小于5%。 Collection Sets 简称 CSets。收集集合, 在一次GC中将执行垃圾回收的heap区。GC时在CSet中的所有存活数据(live data)都会被转移(复制/移动)。集合中的heap区可以是 Eden, survivor, 和/或 old generation。CSets所占用的JVM内存小于1%。
