标记-清除算法为什么无法满足生产环境的高效需求

标记-清除算法不整理内存，仅标记死亡对象并释放其空间，导致碎片化严重，无法满足生产环境对大对象分配和长期稳定性的要求。

标记-清除算法本身不追求“高效分配”，它追求的是“低暂停、易实现”——这恰恰与生产环境对内存利用率、大对象分配成功率和长期稳定性的要求相冲突。

它不整理，只打标，空闲空间越用越碎

算法执行后，存活对象原地不动，仅把死亡对象占用的内存块标记为空闲。这些空闲块散落在堆中各处，彼此隔离、无法合并。哪怕老年代还剩 400MB 空闲，最大连续块只有 64KB，一个 new byte[1024*1024]（1MB）对象就直接触发 OOM。

• 分配器必须遍历空闲链表或位图寻找足够大的连续区域，碎片越多，查找越慢
• CMS 收集器长期运行后常见 “concurrent mode failure”，本质就是碎片导致大对象无法分配，被迫退化为 STW 的 Serial Old 整理
• 日志里老年代使用率（O）显示才 70%，却频繁 Full GC，往往是碎片在背后作祟

它不移动，也不压缩，无法应对老年代真实压力

新生代靠复制算法天然防碎片，而老年代对象多、体积大、晋升频繁，又没有备用空间供复制。标记-清除在这种场景下只是“就地清场”，不挪动、不归并、不重排地址——等于把问题留给下一次分配。

• Parallel Old 虽默认带整理，但整理过程耗时长，可能引发秒级停顿，反而影响吞吐与响应
• G1 和 ZGC 已不再裸用标记-清除，而是把它拆解为“标记阶段基础 + Evacuation/重映射阶段整理”，清除只是中间一环
• 纯标记-清除在 JDK 中基本只作为教学模型或极简运行时（如某些嵌入式 JVM）的备选，不用于主流生产部署

它效率随堆增长而下降，且配置不当会加速恶化

标记需遍历整个堆的对象图，清除需扫描所有内存页；对象越多，标记与清除耗时越长。更关键的是，很多参数会悄悄把碎片“推”向老年代：

• -XX:SurvivorRatio=2 让 Survivor 区极易塞满，短命对象提前晋升
• -XX:MaxTenuringThreshold=1 导致对象活过一次 Minor GC 就进老年代
• 未启用压缩指针（-XX:+UseCompressedOops）或位图标记（UseBitmapMarking），会拖慢并发标记速度，延长碎片窗口期

它不是错，而是被现代 JVM 主动绕开的设计选择

今天没有哪家生产系统会把标记-清除当作主力回收策略来调优。它的价值在于：作为分代收集中的底层能力，支撑 G1 的 Remembered Set 扫描、ZGC 的染色指针标记、Shenandoah 的 Brooks Pointer 更新。真正起效的，永远是它之后的整理、复制或重映射动作。

换句话说：标记-清除负责“发现垃圾”，但生产环境要的是“腾出整块地”。后者，它做不到。