Node js - 完整解决方案与实战教程

在构建高并发的 Node.js 后端服务时，很多开发者会遇到一个看似简单却极其棘手的问题：服务运行一段时间后，内存持续上涨，最终触发 OOM（Out of Memory）崩溃，或者响应时间从几十毫秒飙升到几秒，但 CPU 和内存监控却看不出明显异常。尤其是在使用 Express/Koa 配合大量中间件、数据库连接池、定时任务以及 WebSocket 长连接的场景下，这种“温水煮青蛙”式的性能衰退尤为常见。本文将从真实业务场景出发，带你一步步排查并解决 Node.js 中因事件循环阻塞、闭包引用泄漏和连接池配置不当导致的性能顽疾。

问题现象

假设你负责一个基于 Node.js 的订单查询服务，部署在 4 核 8G 的容器中。上线初期 QPS 稳定在 800 左右，平均响应时间 30ms。但运行 6 小时后，出现以下典型症状：

P99 响应时间从 50ms 逐渐攀升至 2s 以上，且伴随大量 504 超时。
通过 process.memoryUsage() 观察，heapUsed 持续增长，手动触发 GC 后仅能释放少量内存。
日志中出现 MaxListenersExceededWarning 警告，但未引起重视。
重启服务后一切恢复正常，但几小时后问题复现。

这类问题往往不是单一原因造成的，而是多个小问题在长时间运行后叠加爆发。

原因分析

经过对线上堆快照（heap snapshot）和事件循环延迟（event loop lag）的采集分析，我们定位到三个核心原因：

未清理的定时器与事件监听器：每个请求都会创建一个 setInterval 用于轮询订单状态，但请求结束后没有 clearInterval，导致定时器不断累积，闭包引用的请求上下文无法被 GC 回收。
同步阻塞操作混入主线程：在订单导出功能中，使用了 JSON.parse 解析一个 50MB 的大 JSON 文件，且未使用 Worker Threads，直接阻塞事件循环超过 1.5 秒，导致所有并发请求排队。
数据库连接池配置不当：MySQL 连接池的 connectionLimit 设置为 100，但未设置 acquireTimeout 和 idleTimeout。高并发下连接被占满，后续请求无限等待，最终拖垮整个服务。

解决方案（附完整代码）

下面给出针对上述三个问题的完整修复代码，涵盖定时器管理、Worker Threads 卸载 CPU 密集任务以及连接池优化。

1. 使用 WeakMap 管理定时器与监听器，避免闭包泄漏

// timer-manager.js
const timers = new WeakMap(); // 使用 WeakMap，键为请求对象，值为定时器ID

function startPolling(req, res) {
  // 模拟轮询逻辑
  const intervalId = setInterval(() => {
    // 假设这里执行一些异步查询
    console.log(`Polling for request ${req.id}`);
  }, 1000);

  // 将定时器与请求对象关联，WeakMap 不会阻止 GC 回收 req
  timers.set(req, intervalId);

  // 请求结束时清理定时器
  req.on('close', () => {
    const id = timers.get(req);
    if (id) {
      clearInterval(id);
      timers.delete(req);
      console.log(`Timer cleared for request ${req.id}`);
    }
  });
}

module.exports = { startPolling };

关键点：使用 WeakMap 而不是普通对象或 Map，因为 WeakMap 的键是弱引用，当请求对象被回收时，对应的定时器引用也会自动消失，避免内存泄漏。

2. 使用 Worker Threads 处理 CPU 密集型任务

// worker-json-parser.js
const { Worker, isMainThread, parentPort, workerData } = require('worker_threads');

if (isMainThread) {
  // 主线程：导出解析函数
  module.exports = function parseLargeJSON(jsonString) {
    return new Promise((resolve, reject) => {
      const worker = new Worker(__filename, {
        workerData: jsonString // 将大 JSON 字符串传递给 worker
      });
      worker.on('message', resolve);
      worker.on('error', reject);
      worker.on('exit', (code) => {
        if (code !== 0) reject(new Error(`Worker stopped with exit code ${code}`));
      });
    });
  };
} else {
  // Worker 线程：执行解析
  const { workerData } = require('worker_threads');
  try {
    const result = JSON.parse(workerData);
    parentPort.postMessage(result);
  } catch (err) {
    parentPort.postMessage({ error: err.message });
  }
}

在 Express 路由中这样使用：

// routes/export.js
const express = require('express');
const parseLargeJSON = require('../worker-json-parser');
const router = express.Router();

router.post('/export', async (req, res) => {
  const largeJsonString = req.body.data; // 假设是 50MB 的字符串
  try {
    // 将解析任务交给 Worker，不阻塞事件循环
    const parsed = await parseLargeJSON(largeJsonString);
    res.json({ success: true, data: parsed });
  } catch (err) {
    res.status(500).json({ error: err.message });
  }
});

module.exports = router;

3. 优化 MySQL 连接池配置

// db.js
const mysql = require('mysql2');

const pool = mysql.createPool({
  host: 'localhost',
  user: 'root',
  password: 'password',
  database: 'orders',
  waitForConnections: true,
  connectionLimit: 20,        // 根据 CPU 核数和数据库负载调整，通常 10-20 足够
  queueLimit: 0,              // 不限制排队请求数，但需配合 acquireTimeout
  acquireTimeout: 10000,      // 获取连接的超时时间，避免无限等待
  timeout: 60000,             // 查询超时
  idleTimeout: 30000,         // 空闲连接 30 秒后释放
  enableKeepAlive: true,
  keepAliveInitialDelay: 10000
});

// 使用 promise 版本
const promisePool = pool.promise();

module.exports = promisePool;

同时，在业务代码中务必使用 try/finally 确保连接释放：

async function getOrder(orderId) {
  const conn = await promisePool.getConnection();
  try {
    const [rows] = await conn.query('SELECT * FROM orders WHERE id = ?', [orderId]);
    return rows[0];
  } finally {
    conn.release(); // 必须释放，否则连接池很快耗尽
  }
}

排查与验证步骤

修复后，建议按以下步骤验证效果：

使用 clinic 或 0x 生成火焰图，确认事件循环延迟低于 10ms。
通过 process.memoryUsage() 每 10 秒打印一次堆内存，观察 1 小时内是否稳定。
使用 autocannon 或 k6 进行 30 分钟压力测试，QPS 维持在 1000 以上且 P99 低于 100ms。
检查日志中是否还有 MaxListenersExceededWarning，若有则通过 emitter.setMaxListeners() 调整或修复监听器泄漏。

Node.js 的性能问题往往隐蔽且具有累积性，养成定期做堆快照和事件循环监控的习惯，才能防患于未然。