如何调试在setImmediate调用中挂起的Node.js进程？

我有个用setImmediate拆分耗时同步操作的应用，偶尔会在setImmediate调用处挂起，导致控制台日志"await is over"无法输出。简化代码如下：

async function computeHeavyOp() {
     const largeVal = 10000;
     for (let i = 0; i < largeVal; i++) { 
        if ( i % 50 === 0) {
           await new Promise((resolve) => setImmediate(resolve));
           console.log(" await is over");
        }
     }
}

实际应用中注册了大量事件回调，但无法复现最小挂起用例。想知道如何调试挂起的JS进程？用lldb附加到进程PID后，看到线程停在事件循环处，推测是微任务队列里有未处理回调，阻塞了宏任务setImmediate的执行。有没有办法定位问题所在的JS调用栈？有没有技术能打印待处理的微任务队列，以及识别来自应用的JS回调？

lldb调试栈信息如下：

* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007ff8162b934e libsystem_kernel.dylib`kevent + 10
    frame #1: 0x00000001036e8361 libuv.1.dylib`uv__io_poll + 871
    frame #2: 0x00000001036d8dca libuv.1.dylib`uv_run + 359
    frame #3: 0x0000000101268ef0 node`node::SpinEventLoop(node::Environment*) + 301
    frame #4: 0x0000000101379f87 node`node::NodeMainInstance::Run(int*, node::Environment*) + 97
    frame #5: 0x0000000101379bb2 node`node::NodeMainInstance::Run(node::EnvSerializeInfo const*) + 130

调用setImmediate前用wtfnode打印的打开句柄如下：

- File descriptors: (note: stdio always exists)
  - fd 2 (tty) (stdio)
  - fd 1 (tty) (stdio)
  - fd 0 (tty)
- Sockets:
  - 127.0.0.1:51544 -> 127.0.0.1:2452

调试方案 #

1. 定位JS调用栈 #

• 用lldb附加进程后，加载Node.js源码自带的调试脚本：command script import /path/to/node/src/debugger/lldb_commands.py（路径对应本地Node.js源码位置），执行node js_backtrace命令，可打印当前JS调用栈及事件循环中待处理的回调上下文。
• 也可以用node --inspect-brk your-app.js启动进程，挂起时通过Chrome DevTools的「Pause」按钮查看调用栈，同时在「Performance」面板中检查宏任务/微任务队列的状态。

2. 打印待处理微任务队列 #

• 启动进程时添加--trace-event-categories v8,node.async_hooks参数，会输出微任务的创建、执行日志，筛选PromiseResolve、MicroTask相关事件，定位未执行微任务的来源。
• 借助async_hooks模块手动追踪，在应用中注入代码记录微任务的创建栈和生命周期：

  const async_hooks = require('async_hooks');
  const fs = require('fs');
  const logPath = './microtasks.log';
  
  const hook = async_hooks.createHook({
    init(id, type, triggerId) {
      if (type === 'PROMISE') {
        const stack = new Error().stack;
        fs.writeFileSync(logPath, `Promise ${id} created by:\n${stack}\n`, { flag: 'a' });
      }
    },
    destroy(id) {
      fs.writeFileSync(logPath, `Promise ${id} destroyed\n`, { flag: 'a' });
    }
  });
  hook.enable();
  

  挂起时查看日志，对比已创建和已销毁的Promise，找出未清理的任务。

3. 识别应用中的JS回调 #

• 用wtfnode --full your-app.js启动，会详细列出所有活跃句柄、定时器、回调及其关联调用栈，区分应用代码和第三方库回调。
• 在代码中调用process._getActiveHandles()和process._getActiveRequests()，打印所有活跃句柄和请求，筛选带有应用代码标识的回调。
• 添加--trace-sync-io参数，追踪同步IO操作是否阻塞事件循环，导致微任务无法及时执行。

4. 验证微任务阻塞假设 #

• 挂起时向进程发送自定义信号，在信号处理函数中触发一个微任务：

  process.on('SIGUSR1', () => {
    Promise.resolve().then(() => console.log('Microtask executed'));
  });
  

  如果日志能输出，说明事件循环未完全挂死，只是存在未处理的微任务。
• 检查是否存在无限递归的微任务：比如某个Promise的then回调中持续创建新Promise，导致微任务队列永远无法清空，阻塞后续宏任务执行。

内容的提问来源于stack exchange，提问作者Pavan Kumar