检测 javascript 内存中的 port 泄漏，核心方法是利用 chrome devtools 的 memory 面板进行 heap snapshot 对比分析。具体做法是：在触发疑似泄漏的代码逻辑前和逻辑执行后，分别截取两次堆快照，然后使用 comparison 视图筛选出由 "jsworker"、"messageport" 或 "jscloseevent" 等类型构成的对象，并检查它们的 retainers（保留路径）是否指向了不应存在的闭包或全局变量。通过追踪这些对象的引用链，可以定位到未正确关闭的端口或未解除的事件监听器。
如何从 Heap Snapshot 中识别 Port 对象
在 Chrome DevTools 的 Memory 面板中，选择 "Take Heap Snapshot" 获取当前堆状态。为了准确识别 Port 泄漏，需要在搜索框中输入特定的构造函数名称或类名。常见的 Port 相关对象包括 MessagePort（用于 Worker 间通信）、WebSocket（底层可能涉及端口管理）以及 Service Worker 相关的 Client 或 MessageChannel 实例。在快照视图中，切换到 "Summary" 模式并按类型排序，或者使用 "Search" 功能输入 MessagePort，即可列出所有存活的对象实例。如果数量随页面刷新或操作重复而线性增长，则存在泄漏风险。
const channel = new MessageChannel();
const port1 = channel.port1;
const port2 = channel.port2;
// 模拟泄漏：将 port1 挂载到全局对象，导致其无法被垃圾回收
globalThis.leakedPort = port1;
// port2 传递给 Worker 或其他上下文
port2.postMessage('test');
// 此时若不再需要 port1，应调用 port1.close();
// 但在全局引用存在的情况下，即使调用 close()，只要引用未断开，GC 仍可能无法回收部分结构
上述代码创建了一个 MessageChannel，并将其中一个端口 port1 赋值给全局变量 globalThis.leakedPort。在正常的单页应用生命周期中，局部变量应在函数执行结束后被销毁。但由于 port1 被全局引用，Garbage Collector (GC) 认为它仍然活跃。当我们在 DevTools 中查看 Heap Snapshot 时，这个 MessagePort 对象会一直存在于内存中。通过观察其 Retainers，可以看到一条从 globalThis 到 leakedPort 再到 port1 的路径，这直接证明了泄漏源。
如何通过 Retainers 追踪泄漏源头
找到泄漏的 Port 对象后，下一步是确定是谁持有对它的引用。在 Chrome DevTools 的 Heap Snapshot 中，选中某个 MessagePort 对象，点击下方的 "Show Retainers" 标签页。Retainers 面板会以树状结构展示所有指向该对象的对象链。开发者需要重点关注那些非预期的父级节点，例如意外挂载的全局对象、长期存活的 DOM 元素上的数据属性、或者未清理的 Event Listener 回调函数。如果 Retainer 路径显示一个普通的 Object 或 Function 持有了 Port，那么检查该对象的定义位置，通常能找到忘记置为 null 或忘记移除监听器的代码行。
// 假设有一个长期运行的定时器或事件监听器
setInterval(() => {
const channel = new MessageChannel();
// 错误示范：每次循环都创建新通道，但未关闭旧通道的端口
// 且没有将端口传递给任何实际消费者，导致孤立对象积累
channel.port1.onmessage = (e) => console.log(e.data);
// port1 和 port2 都没有被 close()，也没有被外部引用清除
// 它们仅被局部变量引用，但在某些复杂闭包场景下可能被意外捕获
}, 1000);
这段代码演示了一种隐蔽的泄漏方式：setInterval 每秒创建一个 MessageChannel。虽然 channel 是局部变量，但其内部的 port1 和 port2 如果没有被正确关闭或传递，就会堆积在内存中。特别是在 onmessage 回调中，如果形成了对包含 Port 的闭包引用，且该回调未被移除，Port 对象及其关联的上下文将被永久保留。在 Retainers 视图中，你可能会看到这些 Port 对象被匿名函数或定时器上下文所引用。解决此问题的关键在于确保在不需要通信时，显式调用 port.close()，并移除相关的事件监听器，从而切断 Retainer 路径，允许 GC 回收内存。
基于程序中特定输入条件验证 Port 关闭行为
为了验证 Port 是否正确关闭，可以构造一个特定的测试用例，模拟用户交互或异步操作完成后的清理流程。例如，在一个 WebSocket 连接或 Worker 通信场景中，当收到特定的终止信号（如 'CLOSE' 消息）时，程序应当立即关闭所有相关的 Port 并解除引用。通过在 DevTools 的 Console 中手动触发这一信号，并随后执行多次 GC（在 Memory 面板点击垃圾桶图标），观察 Heap Snapshot 中 MessagePort 的数量是否下降。如果数量不降反升，说明清理逻辑存在缺陷，可能是某个分支路径遗漏了 close() 调用，或者是事件监听器依然保持了对 Port 的强引用。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
