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、我的公众号
敬请关注我的公众号：大象只为你，持续更新技术知识…