老年代不能用复制算法，因其需预留等量空闲空间且移动成本与高存活率（常超90%）正相关，导致空间浪费严重、停顿过长；标记-清除虽省空间但产生碎片，易致大对象分配失败；标记-整理通过紧凑迁移兼顾连续性与空间效率，成为主流选择。
老年代回收之所以复杂，核心在于对象存活率高、内存空间大、碎片敏感——标记-整理算法正是为应对这三重约束而成为主流选择。
为什么老年代不能用复制算法？
复制算法要求预留等量空闲空间，且移动成本与存活对象数量成正比。老年代通常占堆内存2/3以上，对象存活率常达90%以上。若用复制算法：
- 需额外准备数GB甚至数十GB的备用空间，严重挤压应用可用内存
- 每次GC都要移动90%以上的存活对象，时间开销远超标记过程本身
- 在大堆（如32GB+）场景下，一次复制可能耗时数百毫秒，停顿不可接受
标记-清除为何不够用？
标记-清除虽省空间、免移动，但会留下大量不连续空闲块：
- 当分配大对象（如1MB缓存数组、长字符串）时，即使总空闲内存充足，也可能因无连续空间而失败
- 频繁触发Full GC或被迫升级为标记-整理，反而增加整体开销
- 长期运行后碎片累积，可能导致“明明还有空间却OOM”的异常现象
标记-整理如何平衡效率与连续性？
它在保留标记-清除低空间开销优势的同时，通过一次紧凑化解决碎片问题：
- 标记阶段完全复用原有逻辑，无需额外设计
- 整理阶段按顺序将存活对象向一端迁移，天然形成大块连续空闲区
- 迁移完成后，新对象可直接用指针碰撞（bump pointer）快速分配，效率接近新生代
- 虽带来STW延长，但现代JVM（如SerialOld、ParallelOld、G1的mixed GC）已对移动和引用更新做了深度优化
实际部署中的关键考量
标记-整理不是“开箱即用”的银弹，需结合运行特征调整：
- 对象平均大小偏大时（如ORM实体、JSON解析结果），整理收益更明显
- 系统对延迟极度敏感（如金融交易），可选用CMS（标记-清除+并发碎片整理）或ZGC/Shenandoah（无STW移动）
- 堆过大（>64GB）且对象分布稀疏时，G1的分区整理策略比全局标记-整理更可控
- 避免过度依赖“永远不触发Full GC”的错觉——老年代晋升过快、元空间泄漏等仍会导致整理式GC不可避免
