Java垃圾回收基础：标记清除与分代收集详解

本文深入剖析了Java垃圾回收的核心机制，重点解读标记-清除算法如何通过“标记可达对象+清除未标记内存”实现老年代回收，揭示其不移动对象却导致内存碎片的本质，以及由此引发的OutOfMemoryError陷阱；同时对比说明新生代为何偏好复制算法——源于对象“朝生夕死”的统计规律，并澄清SurvivorRatio等关键参数的真实含义与调优误区；进一步阐明分代收集并非静态划分，而是由对象年龄、晋升阈值和空间压力动态驱动，直击老年代增长快等常见问题的真正根源；最后破除System.gc()能强制回收的迷思，强调JVM自主决策权与日志诊断的重要性——所有这些机制都紧密关联着代码中对象的创建方式、引用持有逻辑与内存布局现实，理解它们，才能从GC日志的数字背后看见真实的应用行为。

标记-清除算法到底在干啥

它不移动对象，只做两件事：先遍历所有可达对象并打标（从 GC Roots 出发），再扫一遍堆，把没被打标的对象内存直接清掉。

• 常见错误现象：OutOfMemoryError: Java heap space 频发，但 jstat 显示老年代使用率不高——很可能是碎片太多，大对象申请不到连续空间
• 适用场景：老年代回收（存活对象多，复制成本高），但现代 JVM 几乎不单独用它，而是作为 Mark-Compact 或 G1 的基础阶段
• 性能影响：标记阶段耗时与存活对象数正相关；清除阶段耗时与整个堆大小正相关；最致命的是不整理内存，必然产生碎片

为什么新生代不用标记-清除而用复制算法

因为绝大多数对象“朝生夕死”，Eden 区一满就触发 Minor GC，此时存活对象通常不足 10%，复制比标记+清除快得多，且天然无碎片。

• 参数差异：-XX:SurvivorRatio=8 表示 Eden : Survivor = 8:1（两个 Survivor 合计占 1 份），不是 8:1:1 —— 这个比例直接影响对象晋升阈值和 GC 频率
• 容易踩的坑：把 Survivor 区调太小（如设成 1），会导致存活对象频繁“躲不过去”直接进老年代，引发不必要的 Major GC
• 真实代价：复制算法要预留一块空闲区，所以年轻代实际可用内存只有理论值的约 90%（Eden + 1 个 Survivor），不是 100%

分代收集不是凭空分的，是靠对象年龄和晋升规则驱动的

对象每熬过一次 Minor GC，年龄 +1；默认到 15 岁（-XX:MaxTenuringThreshold=15）就进老年代——但这只是上限，实际可能早得多。

• 关键触发条件：Survivor 空间不够存下本轮存活对象时，JVM 会按年龄从小到大批量晋升，哪怕年龄远低于 15
• 典型误判：看到老年代增长快，第一反应是“内存泄漏”，其实可能是 SurvivorRatio 不合理或对象创建节奏突变（比如批量读文件生成临时 DTO）
• 兼容性注意：ZGC/Shenandoah 等低延迟收集器弱化了分代概念，但 HotSpot 默认仍是分代设计，-XX:+UseSerialGC 或 -XX:+UseG1GC 会影响分代行为是否启用

别被 System.gc() 欺骗，它不等于立即回收

System.gc() 只是建议 JVM 执行 GC，是否执行、何时执行、用哪个收集器，全由 JVM 自行决定。在生产环境调用它，基本等于给系统埋雷。

• 常见错误现象：本地测试时加了 System.gc() 看似有效，上线后完全失效，甚至因频繁请求 GC 导致 STW 时间飙升
• 真正可控的方式只有 JVM 启动参数：-XX:+PrintGCDetails -Xlog:gc*（JDK 10+）才能看清实际发生了什么
• 隐蔽陷阱：某些框架（如旧版 Netty、Log4j2 的某些配置）会隐式触发 System.gc()，需通过 -XX:+DisableExplicitGC 彻底屏蔽

分代和标记-清除都不是抽象概念，它们直接对应着堆内存的物理布局、对象生命周期的统计规律，以及每次 GC 日志里那几行看似枯燥的数字。真正卡住人的，往往不是算法本身，而是没意识到：对象能不能活过一次 GC，取决于你代码里引用的持有方式，而不是 new 出来的那一刻。

到这里，我们也就讲完了《Java垃圾回收基础：标记清除与分代收集详解》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！