标记-清除算法核心挑战在于真实环境中的正确性、性能与可用性平衡：需靠写屏障应对并发漏标，用卡表优化跨代扫描，以三色标记保障精度，但内存碎片、全堆遍历停顿及硬件限制使其需大量工程补丁才能落地。
标记-清除算法虽是垃圾收集最基础的实现方式，但真正落地到生产级 JVM 中，远不止“先标记、再清除”这么简单。它的核心挑战不在逻辑本身，而在于如何在真实运行环境中兼顾正确性、性能与可用性。
并发场景下的对象引用漂移
当垃圾收集器在标记阶段与用户线程（Mutator）并发执行时，对象图可能动态变化。例如：一个已被标记为黑色的父对象，突然被用户线程修改引用，指向了一个尚未标记的白色子对象——这个子对象就会漏标，最终被错误回收。这是致命问题，不是“多清点一点”就能掩盖的。
为应对该问题，JVM 必须引入写屏障（Write Barrier）机制，在每次对象引用更新时插入检查逻辑。常见策略包括：
- 增量更新（Incremental Update）：当黑色对象新增对白色对象的引用时，立即将该白色对象重新标记为灰色，加入待处理队列
- 原始快照（SATB, Snapshot-at-the-Beginning）：在标记开始前记录所有可达对象快照，后续只基于该快照进行标记，新产生的引用关系暂不参与本轮回收
内存碎片引发的分配失败连锁反应
清除阶段只是释放未标记对象的内存，不移动存活对象，导致堆中空闲空间高度离散。一旦程序需要分配大对象（如大数组、缓存块），即使总空闲内存充足，也可能因找不到连续地址段而失败。
这种失败不会静默发生，而是直接触发：
- Promotion Failed：新生代对象无法晋升至老年代（因老年代碎片化）
- Concurrent Mode Failure：CMS 在并发清除阶段发现空间不足，被迫退化为 Full GC，带来长时间 STW
- 频繁的后备回收：JVM 可能提前启用标记-整理或备用收集器，增加调度开销
全堆遍历带来的停顿与吞吐损耗
标记和清除两个阶段都需扫描整个堆空间。堆越大，耗时越长；尤其在老年代占比高、对象存活率高的系统中，一次完整标记-清除可能持续数百毫秒。
这使得它难以满足低延迟要求，也限制了其适用范围：
- 初始标记和重新标记必须 STW，虽然时间短，但频率升高会影响响应毛刺（p99 latency）
- 并发标记虽不暂停应用，却与业务线程争抢 CPU，降低整体吞吐量
- 无法支持分区域精细控制，缺乏像 G1 那样的可预测停顿能力
三色抽象与实现精度的落差
三色标记法（白/灰/黑）是理论模型，但实际 JVM 实现受制于硬件与内存模型约束。例如：
- 对象头中用于标记的颜色位需与锁标志位、GC 标志位共用有限比特，存在位冲突风险
- 多核 CPU 下缓存一致性（cache coherency）可能导致某线程看到过期的颜色状态
- 部分 JVM（如 ZGC）改用读屏障 + 染色指针（colored pointer），绕开对象头限制，但这又带来指针解引用开销
这些挑战说明，标记-清除不是“过时”而是“受限”——它仍是 CMS 和 Serial Old 的底层骨架，但必须搭配写屏障、卡表（Card Table）、增量式处理等大量工程补丁才能稳定运行。现代 GC 的演进，本质上是在不断给这个古老算法打补丁，直到用分区、并发、压缩等新范式重构整个回收逻辑。
