排查 worker 和 indexeddb 的内存泄漏，核心在于确认后台线程是否被正确终止以及数据库连接是否在任务结束后关闭。具体做法是：在 service worker 或 dedicated worker 中，确保所有 idbdatabase 实例在事务完成或脚本结束时调用 close()；同时通过 chrome devtools 的 memory 面板录制 heap snapshot，对比 worker 启动前与长时间运行后的快照，重点检查 idbdatabase、idbtransaction 以及关联的 arraybuffer 是否残留。若发现这些对象未被垃圾回收，通常是因为存在未关闭的连接引用或未处理的异步回调。
Worker 生命周期管理不当导致的泄漏
Worker 泄漏常发生在主线程未正确终止 Worker 或 Worker 内部发生未捕获异常导致自我挂起时。开发者应确保在主线程不再需要 Worker 时调用 terminate()，并在 Worker 内部监听 onerror 以防止静默失败。此外，若 Worker 持有对大型数据的引用且未释放，即使 Worker 停止，数据仍可能因闭包而驻留内存。
const worker = new Worker('worker.js');
// 模拟长时间运行的任务
worker.postMessage({ action: 'start', data: new ArrayBuffer(1024 * 1024) });
// 错误示范：未处理错误可能导致 Worker 挂起
worker.onmessage = (e) => {
console.log('Result:', e.data);
};
// 正确做法：在不需要时显式终止
function cleanup() {
worker.terminate();
}
IndexedDB 连接未关闭引发的资源堆积
IndexedDB 泄漏的主要原因是打开数据库后忘记关闭连接，或者在事务未完成时提前关闭。每个 IDBDatabase 连接都会占用系统资源，若长期不关闭，会导致内存持续增长。开发者应在所有操作完成后立即调用 db.close()，并避免在多个地方重复打开同一数据库而不关闭。
const request = indexedDB.open('MyDatabase', 1);
request.onupgradeneeded = (event) => {
const db = event.target.result;
if (!db.objectStoreNames.contains('items')) {
db.createObjectStore('items', { keyPath: 'id' });
}
};
request.onsuccess = (event) => {
const db = event.target.result;
// 执行操作
const transaction = db.transaction(['items'], 'readwrite');
const store = transaction.objectStore('items');
store.put({ id: 1, value: 'test' });
transaction.oncomplete = () => {
// 关键：事务完成后关闭连接
db.close();
};
transaction.onerror = () => {
db.close();
};
};
request.onerror = (event) => {
console.error('Database error:', event.target.error);
};
如何验证特定输入下的内存释放情况
为了验证上述代码是否真正释放了内存，可以使用 Chrome DevTools 的 Memory 面板进行 Heap Snapshot 对比。首先记录初始状态，然后触发一次完整的 IndexedDB 写入和 Worker 通信，最后再次记录快照。通过比较两次快照中 IDBDatabase 和 Worker 对象的数量变化，可以判断是否存在泄漏。如果对象数量没有减少，说明仍有引用未被清除。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
