v8引擎不使用引用计数机制，而是采用基于可达性的标记-清除与分代回收（新生代scavenge、老生代mark-sweep/mark-compact）；其弃用引用计数主因是无法解决循环引用导致的内存泄漏、高频计数开销大、难以协同增量标记与内存压缩等现代gc优化策略。
V8 引擎实际上并不使用引用计数机制作为其垃圾回收（GC）的主算法。这是关键前提——它没有“V8 的引用计数机制弊端”，而是明确弃用了该算法，原因正是其固有缺陷无法满足现代 JavaScript 运行需求。
循环引用导致内存泄漏
当两个或多个对象互相持有对方引用（如 objA.ref = objB 且 objB.ref = objA），即使它们已脱离作用域、外部再无任何变量指向，各自的引用计数仍大于 0。垃圾回收器只看数字，不分析结构关系，因此永远不会回收这些对象，造成持续内存占用。
- 早期 IE 6–8 的 DOM/BOM 实现曾用引用计数，正因该问题引发大量真实内存泄漏
- 现代 JS 场景中，事件监听器绑定、状态管理树、缓存 Map 结构等都容易无意构造此类闭环
频繁更新计数器带来性能开销
每次赋值、传参、入数组、设属性，都要原子性地增减引用计数；每次销毁引用（如变量重赋值、离开作用域）也需同步减一。这些操作分散在代码各处，高频发生时会显著拖慢执行速度。
- 尤其在大量对象创建/销毁的场景（如动画帧、实时数据流），计数器维护本身成为瓶颈
- 多线程或并发环境下还需加锁保障计数正确，进一步降低效率
无法与现代 GC 策略协同
V8 采用分代回收（新生代用 Scavenge 复制算法，老生代用 Mark-Sweep / Mark-Compact），依赖对象存活时间特征和内存布局优化。引用计数是“对象粒度即时响应”模型，与基于根可达性扫描、批量标记、整理内存块的设计逻辑根本冲突。
- 它无法支持增量标记（Incremental Marking）以减少主线程停顿
- 不能配合内存压缩（Compaction）解决碎片化问题
- 难以融入并行或并发 GC 阶段（如并行标记、辅助线程清理）
为什么资料里还提它？
不是因为它被 V8 使用，而是因为它揭示了内存管理的基本权衡：响应快但鲁棒性差。理解它，能帮你写出更安全的对象关系——比如主动断开监听器引用、用 WeakMap 存储元数据、避免在闭包中长期持有 DOM 节点等。这些实践，恰恰是为了绕过引用计数曾暴露过的那些陷阱。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
