每个Worker拥有独立Isolate，含专属堆内存和GC，互不共享；SharedArrayBuffer内存位于原生堆，不受任何Worker的GC管理。
JavaScript 的垃圾回收（GC）在 Worker 多线程环境中，不是“共享一套 GC”，而是每个 Worker 拥有完全独立的内存边界和回收逻辑。这种隔离不是靠开发者手动控制，而是由 V8 引擎底层的 Isolate 机制强制保障的。
每个 Worker 对应一个独立 Isolate
V8 中的 Isolate 是最高粒度的执行与内存隔离单元。每个 Web Worker 或 Node.js Worker Thread 启动时，都会创建专属的 Isolate 实例，它包含：
- 独占的堆内存（Heap），所有 JS 对象都分配在此，互不交叉
- 独立的垃圾回收器（GC），只扫描、标记、清理自己堆内的对象
- 无共享的执行栈与上下文，无法直接访问其他 Worker 的变量或闭包
这意味着：A Worker 中创建的数组、闭包、DOM 引用（若在支持环境）等，B Worker 的 GC 根本“看不见”，也绝不会尝试去标记或回收——这不是策略选择，而是内存地址空间天然隔离的结果。
共享数据必须绕过 V8 堆
Worker 之间要通信或共享数据，不能靠传递 JS 对象引用（因为它们在不同堆中地址无效），只能通过：
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
结构化克隆（structured clone）：如
postMessage()传递可序列化的值，本质是深拷贝到对方 Isolate 的堆中 - ArrayBuffer + SharedArrayBuffer（配合 Atomics）：在原生内存（C++ malloc/mmap 分配）中开辟共享区域，所有 Worker 通过指针访问同一块物理内存，V8 堆 GC 完全不管理这部分
关键点：SharedArrayBuffer 的内存不在任何 V8 堆内，因此不受任一 Worker 的 GC 影响——它由开发者显式分配和释放（如调用 .close()），GC 不会介入，也不会误回收。
如何监控各自内存使用边界
监控必须在每个 Worker 内部进行，无法跨 Isolate 获取对方堆快照。常用方式有：
-
performance.memory（仅部分浏览器支持）：返回当前 Isolate 的堆使用量、限制与总量，例如performance.memory.usedJSHeapSize -
chrome://tracing或 Chrome DevTools 的 Memory 面板：可分别录制各 Worker 的堆快照（Heap Snapshot）和分配时间线（Allocation Timeline） - Node.js 中使用
worker.getHeapStatistics()（需启用--expose-gc）获取当前 Worker 的堆统计信息
注意：这些 API 返回的数值全部属于“本 Isolate”，不存在“总 Worker 内存”聚合接口——这正是隔离设计的体现：监控粒度与执行边界严格对齐。
为什么不能让 GC 跨 Worker 协同工作
技术上不可行，原因很根本：
- V8 堆对象地址在 GC Compact 阶段会移动，而跨线程同步移动后的地址成本极高，且破坏内存安全性
- 并发 GC 需要精细的读写屏障和暂停协调，一旦引入跨 Isolate 引用，就等于打破隔离契约，带来严重安全隐患和性能退化
- Web 标准明确要求 Worker 间通信必须显式、可控，禁止隐式内存共享，这是沙箱模型的基石
所以，所谓“监控多线程下的 GC”，本质就是分别监控多个独立 GC 实例的行为，而不是在一个统一视图里调度它们。
