标记-清除算法性能开销主要来自标记阶段（时间随存活对象线性增长）和清除阶段（需线性扫描整个堆，与垃圾量无关），且不整理内存导致碎片化，引发频繁GC和分配失败。
标记-清除算法在处理大量对象时，性能开销主要来自两个阶段的遍历行为和内存管理特性，不是对象数量本身直接导致“慢”，而是其固有设计带来的可扩展性瓶颈。
标记阶段耗时随存活对象线性增长
标记过程必须从 GC Roots（如栈变量、全局对象、活跃句柄等）出发，递归遍历所有可达对象并打标。若堆中存活对象多（例如老年代长期驻留的缓存、单例、静态集合），即使垃圾比例很高，标记时间仍取决于“活对象数”，而非“死对象数”。这意味着：大量对象 + 高存活率 → 标记时间显著上升。
- 每次标记都要访问对象头（Header）并递归扫描引用字段，深度嵌套或宽引用图会放大访问开销
- 并发标记虽可减少 STW（Stop-The-World）时间，但需额外写屏障（Write Barrier）维护一致性，增加运行时负担
- 在 CMS（Concurrent Mark-Sweep）等早期实现中，标记不彻底可能引发 remark 阶段重扫，进一步拖慢整体周期
清除阶段效率低且无法跳过碎片整理
清除阶段需线性扫描整个堆内存区域，逐个检查对象是否被标记。它不做移动、不压缩、不跳过——哪怕99%是垃圾，也要走完全部地址空间。
- 扫描范围等于堆总大小，与实际垃圾量无关；堆越大，清除越久
- 不整理内存，导致空闲块离散。后续分配大对象时，即使总空闲内存充足，也可能因找不到连续空间而提前触发下一次 GC
- 频繁触发 GC 又反过来加剧标记/清除的调用频率，形成“GC 螺旋”——尤其在内存压力持续升高时
对比其他算法凸显短板
面对海量对象场景，标记-清除的劣势在横向对比中更明显：
- 复制算法（如新生代 Eden+Survivor）只复制存活对象，清除即清空整块内存，时间复杂度接近 O(存活对象数)，适合高死亡率区域
- 标记-整理算法虽也需标记，但整理阶段通过滑动压缩把存活对象紧挨排列，既解决碎片，又为下次分配预留大片连续空间，避免反复扫描
- 现代 JVM（如 ZGC、Shenandoah）用读屏障+并发转移替代传统标记-清除，把大部分工作移出 STW，大幅缓解大规模堆下的停顿问题
实际影响不止于“慢”，还牵连稳定性
性能开销不只是响应延迟——它会连锁影响系统可靠性：
- 长时间 STW 可能导致服务超时、心跳失败、连接断开，对实时性要求高的场景尤为敏感
- 碎片积累后，小对象分配尚可应付，但日志批量写入、图片解码、序列化缓冲等操作容易因分配失败触发 Full GC，加剧抖动
- 某些语言运行时（如 Python 的 gc.collect()）允许手动触发标记-清除，若在高频路径中滥用，会人为放大开销
