排查 Node.js Worker Threads 卡死问题时，我先确认的是外部现象：主线程的 Promise 是否长时间 pending，worker 所在进程的 CPU 占用有没有变化，日志里有没有报错。通常这能帮助区分是死锁、资源竞争，还是纯粹的任务量太大。

如果是共享内存场景，第一优先是看 SharedArrayBuffer 的写入路径。不要急着加日志，先检查代码里有没有直接对共享内存赋值，以及锁获取的顺序。

先确认现象：超时和锁的判断

当多个Worker通过SharedArrayBuffer相互等待对方写入数据，且各自在Atomics.wait上阻塞时，就形成了死锁。判断时可以在每个worker的入口处加入一个超时计数器，如果超过预期时间还没有收到应答，就主动抛出错误并终止所有相关线程。一个典型的信号是，主线程的Promise长时间处于pending状态，而worker的进程仍然在运行。

这一步的核心是先把“挂起”变成一个可观测的事件。超时计数器不是要立即终止，而是要记录是谁先超时、哪个锁没有释放。

容易误判：赋值写共享内存和内存重排

避免资源竞争的核心是让每个worker只操作自己独立的内存区域。如果确实需要共享数据，应该使用Atomics.load和Atomics.store来读写，并且配合Atomics.wait和Atomics.notify进行同步。不要直接用普通的赋值操作对SharedArrayBuffer写入，因为JavaScript引擎可能会对内存访问进行重排，导致数据不一致。

这里容易误判的地方是，单线程下运行正常的代码，一旦放进多个 worker 且共享同一块缓冲区，就可能出现随机性的数据错乱。排查时可以在关键写入点加上 Atomics.store，并在读取端使用 Atomics.load。只有这两个操作落在相同的索引上，再配合 wait 和 notify，才算有同步保证。

建议的处理顺序：线程池边界和锁策略

配置线程池时，Worker的数量不宜超过物理核心数。一个常见做法是使用os.cpus().length获取核心数，再根据任务性质留出一定余量。如果任务包含大量I/O操作，可以适当增加一些线程，但只要涉及共享数据，就应减少并发量。建议在代码中显式设置最大线程数，并加上监控日志，方便排查问题。

在处理顺序上，我会先缩小并发范围，再调整锁的顺序。具体做法是：先让每个 worker 只处理固定槽位的数据；如果必须申请多个资源锁，就按照同一个全局顺序来申请。然后观察还剩下哪些 worker 会超时。那些仍然超时的，通常是锁粒度太大，或者某个 worker 提前退出但没有释放锁。

配置和检查：超时计数器与 worker 生命周期

下面是一个最小化的超时计数器模板，用于在主线程捕捉 worker 无响应的情况。它没有处理具体业务，只演示“超时-终止-清理”的顺序。

const { Worker } = require('worker_threads');

function createTrackedWorker(file, timeout = 5000) {
  const worker = new Worker(file);
  let settled = false;

  const timer = setTimeout(() => {
    if (!settled) {
      console.error('worker timed out, terminating');
      worker.terminate();
    }
  }, timeout);

  worker.on('message', () => {
    settled = true;
    clearTimeout(timer);
  });

  worker.on('error', (err) => {
    settled = true;
    clearTimeout(timer);
    worker.terminate();
  });

  worker.on('exit', (code) => {
    clearTimeout(timer);
    // 在 exit 回调里清理共享内存槽位
  });

  return worker;
}

这里的 timer 会主动终止不响应的 worker。terminate 会触发 exit 事件，所以 exit 回调里适合清理 SharedArrayBuffer 上的状态，比如重置代表“忙碌”的槽位。但注意，terminate 是强制的，真正优雅的退出是在 worker 内部处理完消息后自己退出。

验证方法：靠事件日志而不是靠肉眼

验证是否已经解决死锁，不能只看任务能不能跑完，还要看退出路径是否干净。我通常会在 worker 的 exit 事件里输出退出码和消耗时间，在 Atomics.notify 调用前后各输出一条调试日志，并在主线程里记录每个 worker 的最后活跃时间。

一个常见的坑是忘记调用 worker.terminate()，导致 worker 一直占用资源。尤其是在 worker 内部发生异常时，如果不监听 error 事件，主线程可能不知道错误已经发生。所以在创建 worker 后，要立即绑定 error、exit 和 message 事件；exit 事件的回调里可以清理共享内存上的状态。这样退出路径干净，后续排查时日志才可靠。

如果多次验证都稳定通过，最后再检查一遍是否还有未释放的锁。我的做法是在验证环境里临时打开 Node.js 的诊断报告，观察 worker 线程状态。但这不是必须的，关键还是日志要能对得上事件顺序。

回滚和风险

这一类问题最容易在回滚时反复。如果新代码是增加了共享内存和锁，我会把旧版本作为一键回滚项，同时保留超时计数器。因为死锁一旦出现，很可能不是必现，而是要等队列积压到一定程度才触发。回滚后也要观察一个完整的任务周期，确认 worker 的退出数量和控制台错误都归零。

还有一个风险边界：共享内存的槽位大小要固定。如果业务需求要求传递大小不固定的字符串，建议先序列化到 ArrayBuffer，再通过 postMessage 发送，而不是把对象直接写进共享内存。postMessage 会做结构化克隆，虽然多一次拷贝，但能省掉手工同步的很多边界问题。

所以我的处理顺序是：先加超时计数器，确认死锁现象；再把共享内存读写全部改成 Atomics 操作；最后限制线程池并绑定 worker 事件。每一步都要有日志或计数器证明前后差异，而不是凭感觉调整。