标记-清除算法适合老年代对象存活率高、回收频率低的场景，因其不移动对象导致内存碎片，易因无法分配大对象而触发Full GC或OOM。
标记-清除算法适合什么场景？为什么它容易引发OOM
标记-清除算法（Mark-Sweep）是JVM最早采用的基础回收策略，适用于老年代中对象存活率高、回收频率低的场景。但它不移动对象，只标记+清除，导致大量内存碎片。当后续需要分配大对象（如字节数组、大集合）时，即使总空闲内存足够，也可能因缺乏连续空间而触发 Full GC，甚至直接抛出 java.lang.OutOfMemoryError: Java heap space。
- 典型表现：GC日志中频繁出现
concurrent mode failure（CMS下）或promotion failed（Parallel GC下） - 避免方式：不要长期持有大对象引用；对已知生命周期长的大对象，可考虑用
-XX:PretenureSizeThreshold直接分配到老年代，绕过新生代复制开销 - 注意：HotSpot 中 Serial Old 和 CMS 的老年代回收都基于此算法变体，但 CMS 后期已被弃用（JDK 14 起移除），新项目应避开
复制算法为什么只用在新生代？8:1:1比例怎么来的
复制算法（Copying）把Eden和两个Survivor区按 8:1:1 划分，本质是为适配“朝生夕死”特性——统计表明约98%的新生代对象在一次Minor GC后就不可达。只保留10%的 Survivor 空间，既够存放少量幸存对象，又避免浪费过多内存。
- 若 Survivor 空间不足，多余对象会通过
分配担保机制直接进入老年代，可能提前触发老年代GC - 实际中可通过
-XX:SurvivorRatio=6调整为 6:2:2，但盲目调大会增加复制成本，调小则加剧担保失败风险 - 注意：
G1和ZGC已不再使用传统复制算法，而是基于 Region 的增量式转移，所以-XX:SurvivorRatio对它们无效
标记-整理 vs 标记-清除：老年代到底该选哪个
标记-整理算法（Mark-Compact）在标记后将存活对象向一端滑动，再清理边界外内存，彻底解决碎片问题。而标记-清除只是清空“洞”，不整理。HotSpot 中 Serial Old 和 Parallel Old 默认用标记-整理，CMS 用标记-清除（因此必须配合压缩触发，如 -XX:+UseCMSCompactAtFullCollection）。
- 关键区别：标记-整理会带来额外移动开销（尤其是老年代对象多、引用关系复杂时），但换来的是稳定的大对象分配能力
- 如果你的应用大量使用
ByteBuffer.allocateDirect()或频繁创建byte[1024*1024]类型对象，强烈建议禁用 CMS，改用 Parallel Old 或 G1 - 一个易忽略点：
System.gc()触发的 Full GC 在默认配置下仍会执行整理（除非显式加-XX:+DisableExplicitGC），但不等于能替代合理对象生命周期设计
分代收集不是算法，而是策略：别把它和具体算法混淆
分代收集（Generational Collection）本身不是一种独立算法，而是对堆内存按对象年龄做逻辑分区（Eden、S0/S1、Old、Metaspace），再为不同区域绑定最适合的回收算法。比如新生代用复制，老年代用标记-整理——这是组合策略，不是单个算法。
立即学习“Java免费学习笔记（深入）”；
- 常见误解：以为“用了G1就不用分代”，其实 G1 仍是分代的（有
young-only阶段和mixed阶段），只是物理上不分区为固定年轻/老年代，而是动态识别回收收益高的 Region - 调优信号：如果
GC logs显示Young GC频次正常但Mixed GC占比过高，说明老年代对象晋升太快，应检查是否有缓存未设淘汰策略、Stream.collect() 误用等隐式长生命周期引用 - 最常被跳过的一步：没确认 JVM 实际启用的 GC 算法。用
java -XX:+PrintCommandLineFlags -version查看默认值，JDK 17+ 默认是G1，但很多遗留系统仍跑在 Parallel GC 上却没意识到
