内存泄漏与GC算法是因果关系而非对立关系——GC仅回收不可达对象，而泄漏源于本该不可达的对象因引用未断开而持续可达；所有主流GC算法均依赖可达性分析，无法解决逻辑错误导致的泄漏。
内存泄漏和垃圾回收器（GC）算法不是对立关系，而是因果关系——GC算法本身无法阻止内存泄漏，但它的设计缺陷或使用不当，会放大泄漏后果。关键在于：GC只回收“不可达对象”，而内存泄漏的本质是“本该不可达的对象，因引用未断开而持续可达”。
GC算法不解决“逻辑错误”，只响应“可达性状态”
无论采用标记-清除、复制还是标记-整理，所有主流GC算法的判定依据都是可达性分析：从根节点（如全局变量、栈帧中的局部变量、活跃线程等）出发，能遍历到的对象视为存活，其余才被回收。
这意味着：
- 只要一个对象被某个长期存活的引用链意外持有（比如事件监听器没卸载、定时器没清除、闭包保留了DOM引用），它就始终“可达”，GC不会动它
- 引用计数法更危险——循环引用直接导致两个对象永远计数＞0，即使完全无业务用途也无法回收（现代JS引擎已弃用该法作主算法，但底层仍存在类似场景）
- 分代GC（如JVM新生代/老年代）可能让泄漏对象“幸存”得更久：短生命周期对象误入老年代后，触发Full GC频率低，泄漏内存长期滞留
不同算法对泄漏的“暴露速度”差异明显
GC策略会影响你发现内存泄漏的难易程度和时间窗口：
- 标记-清除：不移动对象，泄漏对象会一直占位，内存占用缓慢爬升，容易被监控工具捕获，但碎片化可能掩盖真实泄漏点
- 复制算法（如V8新生代Scavenge）：每次GC都拷贝存活对象，泄漏对象会被反复搬运，虽不增总内存，但增加CPU开销和晋升压力，可能提前触发老生代GC，间接暴露异常引用链
- 标记-整理：压缩内存后泄漏对象集中“浮出水面”，配合堆快照比对，更容易定位长期驻留对象及其引用路径
面试中要强调的实战认知
不能只背算法步骤，需结合工程现实回答：
- GC再先进，也救不了忘记
removeEventListener的代码；再高效的复制算法，也清不掉全局缓存里越积越多的用户数据 - 排查泄漏的第一步永远不是调优GC参数，而是用DevTools的Memory面板拍堆快照，筛选“Retained Size”大且多次快照中持续存在的对象，再逆向查它的GC Roots
- 真正健壮的设计，是在GC之外加一层“引用契约”：比如用WeakMap存储DOM关联数据、用AbortController控制请求生命周期、给定时器加自动销毁机制
说到底，GC是守门人，不是清洁工。它只按规则放行或拦截，而泄漏是开发者悄悄递过来的“合法但不该进来的访客”。
