JVM垃圾收集算法、对应收集器和选择建议

如果说垃圾收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。

到目前为止还没有最好的垃圾收集器出现，也没万能的垃圾收集器。实际使用中，根据具体应用场景选择合适的垃圾收集器。

1、垃圾收集算法

垃圾收集算法可以从高层次上归纳为四种主要类型：分代收集理论、标记-复制算法、标记-整理算法和标记-清除算法。

1.1、分代收集理论

大多对象在内存中只会存活很短的时间，JVM堆内存被分为新生代和老年代。新生代中又分为Eden区和两个Survivor区，新生代主要用于存放新建的对象，短期内未被回收的对象会晋升到老年代。

算法应用： JVM垃圾收集器的基础，所有垃圾收集器都基于这一理论实现。

1.2、标记-复制算法

标记-复制算法，将堆内存划分为两个相等的区域，将存活的对象从一个区域复制到另一个区域，回收未被复制的对象。

优点： 简单高效，尤其适用新生代，总是从空区域开始分配区域，不会产生内存碎片。

缺点： 需要两个相同大小的内存区域，导致内存利用率降低。

典型应用： Serial GC、Parallel GC和G1 GC的新生代部分。

1.3、标记-整理算法

标记-整理算法，首先标记所有的存活的对象，再将存活的对象向堆的一端移动，最后清理掉堆的另一端的空闲内存。

优点： 解决内存碎片问题，适合老年代内存管理。

缺点： 对象移动和引用更新会带来额外的开销。

典型应用： Serial GC，Parallel GC和G1 GC的老年代部分

1.4、标记-清除算法

标记-清除算法，先标记所有存活的对象，再清理未标记的对象。

优点： 实现简单，不需要额外的空间来移动对象。

缺点： 产生内存碎片。

典型应用： CMS GC的老年代部分。

2、垃圾收集器

2.1、新生代垃圾收集器

对象存活时间较短，大多数对象在创建后很快就会被回收，主要基于复制算法，该算法效率高、能快速回收短生命周期的对象。

Serial 收集器：

• 使用单线程进行垃圾收集，适用于单处理器环境
• 是最简单的收集器，使用 标记-复制算法 处理新生代
• 垃圾收集时会 Stop-The-World（暂停所有用户线程）
• 适合需要最小化内存管理开销的场景(如桌面应用程序)

ParNew 收集器：

• Serial 收集器的多线程版本
• 可以在多核环境下使用多线程进行垃圾收集
• 常与 CMS 收集器配合使用来回收新生代

Parallel Scavenge 收集器：

• 也叫做 “吞吐量优先” 收集器，适用于高吞吐量的场景
• 通过多线程进行垃圾收集，使用 标记-复制算法
• 强调在单位时间内完成尽可能多的任务
• 适合后台服务器应用程序

2.2、老年代垃圾收集器

老年代的对象存活时间较长，存活率高，常用算法是标记-整理算法或标记-清除算法，主要针对内存碎片化问题进行优化。

Serial Old 收集器：

• 使用 标记-整理算法
• 是 Serial 收集器 在老年代的版本
• 使用单线程，适用于单处理器环境

Parallel Old 收集器：

• 使用 标记-整理算法
• 是 Parallel Scavenge 收集器 的老年代版本
• 支持多线程并发回收
• 适合在多处理器环境下进行高吞吐量的垃圾回收

CMS（Concurrent Mark-Sweep）收集器：

追求低停顿，适合低延迟应用场景(如交互式应用程序)

CMS的工作过程【四个阶段】

① 初始标记： 暂停所有的其他线程(STW)，记录下gc roots直接能引用的对象，速度很快。

② 并发标记： 从GC Roots的直接关联对象开始遍历整个对象图，过程耗时较长，但不需要停顿用户线程，可以与垃圾收集线程一起并发运行。

③ 重新标记： 主要处理漏标问题，停顿时间比初始标记阶段稍长，但比并发标记阶段短，主要用到三色标记里的增量更新算法。

④ 并发清理： 开启用户线程，同时GC线程开始对未标记的区域做清扫，如果有新增对象会被标记为黑色不做任何处理。

CMS的优点： 大部分工作可以在用户线程运行时并发进行，减少垃圾收集时的停顿时间。

CMS的缺点： 产生内存碎片，有时需要额外的 Full GC 整理碎片。

2.3、新生代和老年代的统一收集器

同时管理新生代和老年代，旨在提供更加统一的垃圾回收体验。

G1（Garbage First）收集器：

• JDK 1.7 中引入，目标是替代 CMS 收集器
• 主要用于低停顿的场景，同时具备处理大堆内存的能力
• 将堆划分为多个大小相等的区域，不再区分严格的新生代和老年代
• 优先处理那些收集回报较高的区域
• 结合标记-复制和标记-整理算法，解决CMS内存碎片问题
• 具备并发回收能力，在应用程序运行时尽量减少停顿时间
• SATB （Snapshot-At-The-Beginning）技术，用于实现并发标记的准确性

SATB 实现原理

• 在并发标记阶段开始时，记录下堆中对象引用的一个快照（Snapshot）
• 通过这个快照，垃圾收集器可以保证在标记过程中
• 即使引用发生变化，也能正确识别出哪些对象是存活的

SATB 步骤

① 初始快照： 记录堆中所有对象的引用状态

② 引用更新： 在并发标记过程中，应用程序可能会更新对象的引用

③ 标记对象： 按照快照记录的状态，标记所有从 GC Roots 可达的对象

④ 结束标记： 所有标记的对象和新增引用对象，都被视为存活对象

SATB 优势

① 准确性： 在快照时存活的对象能会被正确标记为存活对象

② 性能： 仅在引用更新时需要记录旧引用，对应用程序的性能影响较小

③ 避免浮动垃圾： 有效减少因并发标记过程中的引用变化而导致的浮动垃圾

ZGC（Z Garbage Collector）：

JDK 11 中引入，超低延迟，能够在很短的停顿时间内管理非常大的堆，停顿时间：一般小于 10ms，堆：高达 16 TB。

使用染色指针(Colored Pointers)和 读屏障(Read Barriers)，实现了几乎完全的并发垃圾回收。核心目标是避免长时间的垃圾回收停顿，适用于需要大内存且要求极低延迟的应用场景。

ZGC 存在问题：

• 最大的问题是浮动垃圾
• ZGC的停顿时间在10ms以下，但执行时间大于这个值
• 期间创建的新对象，难进入当次GC，这些就是浮动垃圾

ZGC 浮动垃圾的解决方案： 增大堆的容量

ZGC 4种触发时机：

① 定时触发： 默认为不使用，可通过ZCollectionInterval参数配置

② 预热触发： 最多三次，在堆内存达到10%、20%、30%时触发，主要是统计GC时间，为其他GC机制使用。

③ 分配速率： 基于正态分布统计，计算内存99.9%可能的最大分配速率，内存将要耗尽之前触发GC。

④ 主动触发： 默认开启，配置参数ZProactive

Shenandoah 收集器：

Red Hat 推出，低停顿的垃圾收集器，和 ZGC 类似，追求在大堆内存场景下实现低于 10ms 的 GC 停顿时间。

2.4、如何选择垃圾收集器建议

• 优先调整堆的大小让服务器自己来选择
• 如果内存小于100M，使用串行收集器
• 如果是单核，且没有停顿时间要求，串行或JVM自己选择
• 如果响应时间最重要，且不能超过1秒，使用并发收集器
• 4G以下可以用parallel，4-8G可以用ParNew+CMS
• 8G以上可以用G1，几百G以上用ZGC
• JDK 1.8默认使用 Parallel(年轻代和老年代都是)

3、我的公众号

敬请关注我的公众号：大象只为你，持续更新技术知识…