V8 中外部内存由 C++ 分配但被 JS 对象引用，计入内存统计却不由 GC 自动释放，导致误触发频繁 GC 与主线程停顿；需通过显式释放、transfer()、正确析构及监控来缓解。
V8 中的外部内存（External Memory）指由 C++ 层分配、但由 JavaScript 对象持有引用的堆外内存，比如 ArrayBuffer 的底层 BackingStore、TypedArray 视图、原生模块中通过 node::Buffer 或 v8::ArrayBuffer::Allocator 分配的内存。这类内存不归 V8 堆管理器直接分配，但 V8 会跟踪其大小，并将其计入内存限制与垃圾回收决策中——这正是它干扰回收周期的核心原因。
外部内存被纳入 V8 内存统计，但不触发自动回收
V8 通过 SetResourceConstraints 设置内存上限（如 Node.js 默认 1.4GB），该上限包含堆内内存 + 外部内存总和。当外部内存持续增长，即使堆内对象很少、GC 很少触发，总内存也可能逼近阈值，迫使 V8 提前启动老生代 GC（即主垃圾回收器）。但关键在于：外部内存本身不会被 GC 自动释放——V8 只能回收 JS 对象（如 ArrayBuffer 实例），而其背后的 BackingStore 是否释放，取决于该对象是否被标记为不可达，且对应的 C++ 分配器是否实现了正确的析构逻辑。
常见干扰表现：
- 一个长期存活的
ArrayBuffer持有 100MB 外部内存，JS 层已设为null，但因闭包或全局变量意外保留引用，导致该 ArrayBuffer 无法被标记为垃圾 → 外部内存长期驻留； - 频繁创建又丢弃
Uint8Array视图，但底层BackingStore被复用或缓存（如某些 Node.js Buffer 实现），V8 统计到外部内存持续高位，误判为内存压力大，从而更频繁地执行耗时的 Mark-Compact； - 自定义
v8::ArrayBuffer::Allocator未正确实现Allocate/Free配对，或Free被延迟调用，造成 V8 认为内存仍被占用，实际却已泄漏。
外部内存影响 GC 触发时机与暂停时间
V8 的 GC 触发不是只看堆使用率，而是综合「堆已用 + 外部内存已用」与「软限制（soft limit）」比较。一旦总和超过软限制（通常为硬限制的 95%），V8 就可能提前触发增量标记（Incremental Marking）甚至完整 GC，即使堆内活跃对象极少。这种“被带节奏”的回收，不仅无效（清不掉外部内存），还会带来额外的主线程停顿（Stop-The-World），影响应用响应性。
尤其在 Node.js 服务端场景下，这种干扰更明显：
- HTTP 请求中解析大文件生成
Buffer，请求结束但Buffer未被及时释放，外部内存堆积； - 流式处理中反复
slice()或subarray()，产生多个视图共享同一BackingStore，只要任一视图存活，整块外部内存就无法释放； - 使用
process.memoryUsage().external可观察该值持续上涨，是外部内存未被及时回收的明确信号。
如何缓解外部内存对回收周期的干扰
根本思路是：让外部内存的生命周期与 JS 对象严格对齐，并主动参与 V8 的资源管理协议。
-
显式释放视图引用：避免长期持有
TypedArray或DataView；不用时设为null，必要时调用arrayBuffer.transfer()明确放弃所有权； -
使用
ArrayBuffer.transfer()或ArrayBuffer.detached状态检测：转移控制权后，原 ArrayBuffer 进入 detached 状态，V8 可立即回收其关联的外部内存； -
在 C++ 扩展中正确绑定生命周期：若自行分配
BackingStore，必须通过v8::ArrayBuffer::Allocator::Allocate并确保Free在 JS 对象被 GC 后准确调用（常借助v8::Persistent+WeakCallback）； -
监控并告警：定期采样
process.memoryUsage().external，设置突增阈值告警，结合堆快照（heapdump或 Chrome DevTools）定位持有外部内存的大对象。
外部内存本身不是垃圾回收的直接目标，却是 V8 判断“要不要收”和“什么时候收”的关键权重。理解它如何被统计、何时被释放、以及为何容易滞留，才能避免写出看似无害却悄悄拖垮 GC 效率的代码。
