标记-清除能回收循环引用对象，因其从根对象出发做可达性分析，不依赖引用计数；互相引用但不可达的对象在标记阶段被忽略，清除时直接回收。
为什么标记-清除能回收循环引用对象
因为标记-清除不依赖引用计数，而是从根对象（如全局变量、栈帧中的局部变量）出发做可达性分析。两个互相引用但外部再无任何路径可达的对象，在标记阶段不会被访问到，也就不会被打上“存活”标记；清除阶段自然会被一并回收。
这直接绕开了引用计数法的根本缺陷：objA.ref = objB 且 objB.ref = objA 时，两者的引用计数始终为 1，永远无法归零。
- 典型触发场景：Python 的
__del__方法存在、或容器对象（如list、dict）持有彼此的强引用 - PHP 默认开启 GC，但需满足条件才会启动标记-清除：比如未释放的循环引用节点数 ≥ 10000，或调用
gc_collect_cycles() - JavaScript V8 引擎中，标记-清除是主回收机制，而引用计数仅用于某些内部优化（如 DOM 节点），不作为主要判断依据
标记-清除带来的内存碎片问题怎么体现
清除阶段只释放未标记对象的内存块，不移动存活对象，也不合并空闲空间。结果就是堆内存里散落着大量小块空隙——它们单独看够用，合起来却无法满足一个大对象的分配请求。
例如在 Java 中，当老年代碎片化严重时，即使总空闲内存充足，也可能因无法找到连续空间而提前触发 Full GC；在 CPython 中，频繁的小对象分配+清除后，malloc 层可能被迫向系统申请新页，加剧 RSS 增长。
- 可通过
jstat -gc <pid></pid>观察OU（Old Used）和OC（Old Capacity）比值接近但FGC频繁，暗示碎片压力 - Python 可用
sys.getsizeof()+gc.get_objects()粗略估算对象分布，但无法直接观测碎片 - 避免长期持有临时容器（如反复
append后不清理的list）能减少“打孔式”释放模式
标记-清除的 Stop-The-World 开销在哪
标记阶段必须暂停应用线程，确保对象图不被修改；否则遍历途中对象关系变更，会导致漏标或误标。这个停顿时间与堆中存活对象数量正相关，而非总对象数——所以老年代越大、存活对象越多，STW 越长。
现代运行时会做优化，比如 JVM 的 G1 收集器采用并发标记（Concurrent Marking），但初始标记（Initial Mark）和最终标记（Remark）仍需 STW；Python 的 gc.collect() 默认就是全停顿的。
- Python 中可通过
gc.disable()临时关闭自动 GC，但需自行控制调用时机，否则可能 OOM - Node.js 可通过
--max-old-space-size=4096限制堆大小，间接缩短单次标记耗时 - 不要在高频循环里手动触发
gc.collect()，它本身就有可观开销
什么时候该考虑替代方案而不是依赖标记-清除
当业务对延迟极其敏感（如实时音视频、高频交易），或堆中长期存在大量中等生命周期对象（既不短命也不永久），纯标记-清除就容易陷入“频繁回收+碎片累积+STW 波动”的负循环。
这时更应关注分代设计与算法组合：新生代用复制算法（如 Python 的 generation 0），老年代用标记-整理（如 JVM 的 SerialOld 或 ZGC 的整理阶段），而非硬扛纯标记-清除。
- Java 应用若发现
G1 Evacuation Pause占比过高，说明复制成本上升，可评估切换至 ZGC - Python 服务若常驻内存 >2GB 且
gc.get_stats()显示 generation 2 回收频次上升，要考虑对象生命周期建模或引入弱引用 - 标记-清除不是银弹——它解决的是“能不能回收”，而分代+压缩解决的是“回收得快不快、稳不稳”
