JVM垃圾回收算法详解：标记清除、复制与整理对比

JVM垃圾回收算法的选择并非孤立的技术决策，而是与内存碎片、对象生命周期、停顿时间及实际业务场景深度耦合的系统性权衡：标记-清除虽低停顿却易因内存“碎成纸屑”导致大对象分配失败和OOM；标记-复制凭借新生代极低存活率实现高效回收，但严重依赖Survivor空间合理配置；标记-整理能根治碎片却带来长STW；而现代G1、ZGC等已通过分区与局部整理打破传统三选一困局——真正关键的不是背算法名称，而是读懂GC日志中的pause时长、promotion failed、humongous allocation等信号，结合对象大小分布、晋升年龄直方图和线程缓冲复用模式，动态调优而非套用教条。

标记-清除算法为什么容易导致 OOM？

不是 GC 没干活，而是它清完垃圾后，内存被切成了一堆“小块”，就像把一整张纸撕成碎屑——总空间够，但拼不出一张 A4 大小的连续区域。new byte[1024 * 1024] 这样的大对象申请时，JVM 找不到连续空闲页，直接抛 OutOfMemoryError。

• 典型触发场景：老年代长期运行后频繁分配中等大小对象（如缓存 entry、JSON 解析 buffer）
• CMS 收集器在老年代就用标记-清除，一旦碎片率 >92%，会强制降级为 Serial Old（STW 时间飙升）
• 监控关键指标不是“已用内存”，而是 ConcurrentMarkSweep 日志里的 promotion failed 或 GC 日志中的 defrag 字样

为什么新生代必须用标记-复制？

因为新生代里 98% 的对象活不过一次 GC，复制存活对象的成本远低于遍历+清理全部对象。但这个算法有个硬约束：Survivor 区必须预留足够空间容纳所有幸存者，否则就会 Minor GC 失败并触发 Full GC。

• -XX:SurvivorRatio=8 表示 Eden:Survivor = 8:1:1，若 Survivor 不够用，对象直接“担保分配”进老年代，加速老年代膨胀
• 避免隐式扩容：不要在循环里 new StringBuilder() 而不复用，它内部 char[] 容易触发复制失败
• 验证方式：加 -XX:+PrintGCDetails，观察每次 Minor GC 后 PSYoungGen 区的 “used” 是否稳定在 10%~30%，突增说明对象存活率异常升高

标记-整理 vs 标记-清除：老年代选哪个更稳？

标记-整理（如 Serial Old、Parallel Old）会移动对象、消除碎片，但移动过程需要 STW；标记-清除（如 CMS）停顿短，但碎片不可控。现在 OpenJDK 17+ 默认的 G1 和 ZGC 其实都绕开了二选一——它们用分区+局部整理，既控停顿又防碎片。

• CMS 已在 JDK 14 被移除，别再为它调优；JDK 17 后默认是 G1，-XX:+UseG1GC 实际已冗余
• 如果还在用 Parallel GC，老年代用的是标记-整理，但它的整理是全堆级的，单次 STW 可能长达数秒，不适合低延迟服务
• 真正要注意的不是算法名，而是 GC 日志里 Pause 时间是否稳定：G1 的 mixed GC 若持续 >200ms，大概率是 Humongous 对象（≥½ region）太多，得查 humongous allocation 日志

ThreadLocal 真的能防碎片吗？

能，但只对特定模式有效：线程生命周期内反复分配同尺寸缓冲区。它本质是把“高频小对象创建”转为“单次分配 + 复用”，避开 Eden 区快速填满、Survivor 溢出、提前晋升这一连串连锁反应。

• 别滥用：ThreadLocal 不释放会导致内存泄漏，尤其在线程池场景下，务必配合 remove()
• 尺寸要合理：设成 new byte[4096] 比 1024 更友好——4KB 是多数 OS 内存页大小，减少跨页分配
• 替代方案更简单：用 ByteBuffer.allocateDirect() 做堆外缓冲，或直接上 org.apache.commons.io.IOUtils 的静态 buffer 池，比手写 ThreadLocal 更可靠

实际调参时，最常被忽略的是对象年龄阈值与晋升行为的耦合关系——-XX:MaxTenuringThreshold 设太高，小对象在 Survivor 待太久，浪费空间；设太低，又让本该回收的对象早早进老年代。这和算法选择一样，不是孤立参数，得看 GC 日志里每轮 Minor GC 后的 age 分布直方图。

好了，本文到此结束，带大家了解了《JVM垃圾回收算法详解：标记清除、复制与整理对比》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！