Node.js中如何操作进程信号？

Node.js中常见进程信号包括SIGINT（用户中断，如Ctrl+C）、SIGTERM（请求终止，用于优雅停机）、SIGHUP（重新加载配置）、SIGUSR1/SIGUSR2（自定义用途）、SIGKILL（强制终止，不可捕获）和SIGSTOP（暂停进程，不可捕获）。其中，SIGINT和SIGTERM可用于实现优雅停机，通过监听这些信号，停止接收新请求、完成现有任务、清理资源后安全退出；而SIGHUP和SIGUSR1/2可扩展用于热重载或状态监控等场景。处理时需避免阻塞操作、慎用process.exit()、设置超时机制，并统一管理退出逻辑，确保应用在容器化环境中稳定运行。

Node.js中操作进程信号主要通过内置的

process

SIGINT

SIGTERM

在Node.js中，要处理进程信号，最直接的方式就是使用

process.on()

SIGINT

SIGTERM

kill

Node.js中常见的进程信号有哪些，它们各自的用途是什么？

在Node.js的世界里，我们与操作系统打交道，进程信号就是操作系统和我们应用之间的一种“悄悄话”。了解这些信号，对于构建健壮的Node.js应用来说，我觉得是基础中的基础。

• SIGINT

  登录后复制
  (Interrupt Signal)：这是我们最常遇到的信号之一，通常由用户在终端按下

  Ctrl+C

  登录后复制
  时发出。它的本意是请求程序中断当前操作。在Node.js应用中，监听

  SIGINT

  登录后复制
  是实现优雅退出的首要步骤。如果你不处理它，Node.js进程默认会直接退出。

• SIGTERM

  登录后复制
  (Termination Signal)：这个信号是操作系统或进程管理器（比如

  kill

  登录后复制
  命令，或者Docker、Kubernetes这类容器编排系统）请求进程终止的“标准”方式。它比

  SIGINT

  登录后复制
  更“正式”一些，意味着“请你自行清理后退出”。在生产环境中，

  SIGTERM

  登录后复制
  是实现优雅停机的核心。

• SIGHUP

  登录后复制
  (Hang Up Signal)：这个信号最初设计是在终端关闭时发送给进程的。但现在，它更多地被用于通知守护进程（daemon）重新加载配置文件。比如，你修改了某个配置，发送

  SIGHUP

  登录后复制
  ，应用就可以在不重启的情况下加载新配置。当然，这需要你在代码里明确实现这个逻辑。

• SIGUSR1

  登录后复制
  /

  SIGUSR2

  登录后复制
  (User-defined Signals)：这两个信号是留给开发者自定义用途的。它们没有预设的行为，你可以用它们来触发特定的应用逻辑，比如日志级别切换、内部状态报告等，非常灵活。

• SIGKILL

  登录后复制
  (Kill Signal)：这是一个“不讲道理”的信号。它会强制立即终止进程，不给进程任何清理的机会。你的Node.js应用无法捕获或忽略

  SIGKILL

  登录后复制
  。这意味着，如果你的应用收到

  SIGKILL

  登录后复制
  ，它会立刻死掉，没有任何商量的余地。这通常是作为最后的手段，当进程无响应时才使用。

• SIGSTOP

  登录后复制
  (Stop Signal)：这个信号会暂停进程的执行，但不会终止它。进程处于暂停状态，直到收到

  SIGCONT

  登录后复制
  信号才会恢复。同样，

  SIGSTOP

  登录后复制
  也无法被捕获或忽略。

我个人觉得，对

SIGINT

SIGTERM

SIGHUP

SIGUSR*

如何在Node.js应用中实现优雅停机（Graceful Shutdown）？

优雅停机，说白了就是让你的应用在被要求退出时，能把手头的工作做完，把该关的都关掉，再体面地离开。这听起来简单，但实际操作起来，尤其是在异步的世界里，还是有些门道的。

易森网络企业版

如果您是新用户，请直接将本程序的所有文件上传在任一文件夹下，Rewrite 目录下放置了伪静态规则和筛选器，可将规则添加进IIS，即可正常使用，不用进行任何设置；(可修改图片等)默认的管理员用户名、密码和验证码都是：yeesen系统默认关闭，请上传后登陆后台点击“核心管理”里操作如下:进入“配置管理”中的&ld

0

查看详情

一个典型的Node.js应用，在收到

SIGINT

SIGTERM

1. 停止接受新的请求：对于HTTP服务器来说，这意味着调用

   server.close()

   登录后复制
   。这样，新的连接就不会进来，但现有的连接会继续处理。
2. 完成现有请求/任务：等待所有正在处理的HTTP请求完成，或者等待正在进行的数据库操作、消息队列消费任务结束。
3. 清理资源：关闭数据库连接池、Redis客户端、文件句柄、WebSocket连接等所有外部资源。
4. 最终退出：在所有清理工作完成后，安全地退出进程。

这是一个简单的实现示例：

const http = require('http');

let connections = new Set(); // 用于追踪所有活跃的连接

const server = http.createServer((req, res) => {
    // 模拟一个需要一些时间处理的请求
    setTimeout(() => {
        res.writeHead(200, { 'Content-Type': 'text/plain' });
        res.end('Hello Node.js Graceful Shutdown!\n');
    }, 500); // 假设处理需要500ms
});

server.on('connection', connection => {
    connections.add(connection);
    connection.on('close', () => connections.delete(connection));
});

server.listen(3000, () => {
    console.log('Server running at http://localhost:3000/');
});

// 优雅停机逻辑
const gracefulShutdown = () => {
    console.log('Received kill signal, shutting down gracefully...');

    // 1. 停止接受新的请求
    server.close(() => {
        console.log('Closed out remaining connections.');
        // 2. 所有连接都已关闭，可以安全退出
        process.exit(0);
    });

    // 如果有活跃连接，给它们一些时间完成
    // 否则，server.close()会立即回调
    if (connections.size > 0) {
        console.log(`Waiting for ${connections.size} connections to close...`);
        // 设置一个超时，防止某些连接永远不关闭
        setTimeout(() => {
            console.warn('Forcefully shutting down due to timeout. Not all connections closed.');
            connections.forEach(conn => conn.destroy()); // 强制关闭剩余连接
            process.exit(1); // 退出码非0表示非正常退出
        }, 10000); // 10秒超时
    } else {
        // 如果没有活跃连接，直接退出
        process.exit(0);
    }
};

// 监听终止信号
process.on('SIGTERM', gracefulShutdown);
process.on('SIGINT', gracefulShutdown);

// 监听未捕获的异常，这也很重要，避免应用在意外情况下崩溃
process.on('uncaughtException', (err) => {
    console.error('Uncaught Exception:', err);
    // 在生产环境中，这里通常会记录错误并尝试优雅退出
    // 但为了避免进程卡死，有时会选择立即退出或在短暂清理后退出
    gracefulShutdown();
});

process.on('unhandledRejection', (reason, promise) => {
    console.error('Unhandled Rejection at:', promise, 'reason:', reason);
    // 同样，这里也应该进行错误记录和优雅退出
    gracefulShutdown();
});

这里我用了一个

Set

server.close()

处理进程信号时，Node.js有哪些需要注意的陷阱或最佳实践？

处理进程信号这事儿，看似简单，但实际操作中还是有些坑需要避开，也有一些实践能让你的应用更稳健。

• 不要在信号处理器中执行阻塞操作：这是个大忌。信号处理器应该尽可能轻量和快速。如果你在里面做了同步的、耗时的操作（比如同步读写大文件，或者复杂的CPU密集型计算），那你的应用就可能卡死，无法响应其他信号，甚至无法正常退出。所有清理工作都应该是异步的。

• process.exit()

  登录后复制
  的慎用：

  process.exit()

  登录后复制
  会立即终止Node.js进程，跳过事件循环中所有未完成的异步操作。这意味着，如果你在调用

  process.exit()

  登录后复制
  之前还有数据库写入、文件保存等异步任务，它们可能就不会执行了。通常，我们应该让Node.js的事件循环自然地清空，或者至少确保所有关键的异步清理任务完成后再退出。只有在确定所有清理工作都已完成，或者在非常紧急的情况下（例如，超时强制退出），才应该调用

  process.exit()

  登录后复制
  。
• 统一的停机逻辑：我建议你把所有的清理和退出逻辑封装到一个函数里（就像上面示例中的

  gracefulShutdown

  登录后复制
  ），然后在所有需要的地方调用它。这样可以避免逻辑分散，减少重复代码，也更容易维护。
• 设置合理的超时：优雅停机不是无限等待。如果你的应用在收到信号后，清理工作迟迟不能完成，那就需要一个超时机制来强制退出。这可以防止应用在某些极端情况下（比如外部服务无响应）无限期地挂起，影响整个系统的稳定性。
• 区分退出码：

  process.exit(0)

  登录后复制
  表示正常退出，而

  process.exit(1)

  登录后复制
  或其它非零值则表示异常退出。在脚本或容器环境中，这个退出码非常重要，它可以告诉父进程或编排系统你的应用是否成功完成任务。
• 考虑

  uncaughtException

  登录后复制
  和

  unhandledRejection

  登录后复制
  ：虽然它们不是进程信号，但在应用健壮性方面，它们和信号处理一样重要。一个未捕获的异常可能导致你的应用在没有任何警告的情况下崩溃。妥善处理这些情况，比如记录日志并尝试优雅退出，能大大提高应用的稳定性。
• 在容器化环境中的考量：在Docker或Kubernetes这样的容器环境中，

  SIGTERM

  登录后复制
  是容器编排系统停止容器的标准信号。确保你的Node.js应用能正确响应

  SIGTERM

  登录后复制
  ，并执行优雅停机，这对于容器的平稳升级和部署至关重要。如果你的应用不处理

  SIGTERM

  登录后复制
  ，容器可能在超时后直接发送

  SIGKILL

  登录后复制
  ，导致数据丢失或状态不一致。
• 避免重复的信号处理：如果你多次调用

  process.on('SIGTERM', handler)

  登录后复制
  ，那么每次收到

  SIGTERM

  登录后复制
  时，所有的处理器都会被执行。这通常不是你想要的。如果你需要替换处理器，应该先用

  process.removeListener()

  登录后复制
  移除旧的。但在大多数优雅停机场景中，一个统一的处理器就足够了。

以上就是Node.js中如何操作进程信号？的详细内容，更多请关注php中文网其它相关文章！