标记-清除算法先标记可达对象，再清除未标记对象内存，不移动对象但产生碎片；适用于老年代，现代JVM多作为Mark-Compact或G1的基础阶段。
标记-清除算法到底在干啥
它不移动对象，只做两件事：先遍历所有可达对象并打标（从 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 自行决定。在生产环境调用它，基本等于给系统埋雷。
立即学习“Java免费学习笔记（深入）”；
- 常见错误现象：本地测试时加了
System.gc()看似有效，上线后完全失效，甚至因频繁请求 GC 导致 STW 时间飙升 - 真正可控的方式只有 JVM 启动参数：
-XX:+PrintGCDetails -Xlog:gc*（JDK 10+）才能看清实际发生了什么 - 隐蔽陷阱：某些框架（如旧版 Netty、Log4j2 的某些配置）会隐式触发
System.gc()，需通过-XX:+DisableExplicitGC彻底屏蔽
