PM2内存上限自动重启

PM2进程因内存占用超过上限自动重启，根因通常是Node.js应用存在内存泄漏或单次处理数据量过大，触发了PM2的"max_memory_restart"保护机制。这个机制本身是救命稻草，防止服务器直接卡死，但频繁重启意味着业务逻辑必须立刻修正。直接查看PM2日志，如果看到"exited with code 0"或"restarting due to exceeding memory limit"，基本可以断定是内存阈值被触发。解决思路分两条线：紧急处理和根本治理。紧急处理是调高内存上限或临时增加实例，根本治理是定位内存泄漏点并优化代码。

PM2的"max_memory_restart"参数允许设置进程内存上限，单位可以是K、M、G。当进程内存占用超过这个值，PM2会强行杀掉进程并重启。这个参数在"ecosystem.config.js"里配置，或者通过命令行"pm2 start app.js --max-memory-restart 500M"指定。如果没有显式设置，PM2默认不会因内存自动重启，所以如果你遇到了自动重启，要么是你或团队成员设置过这个值，要么是系统OOM Killer在起作用。区分两者的方法是查看系统日志："dmesg | grep -i "out of memory""，如果有记录，说明是操作系统层面的OOM干预；如果没有，再看PM2日志，"pm2 logs --err"会明确打印内存超限信息。

如果业务正在遭受频繁重启，第一步不是改代码，而是止血。修改"ecosystem.config.js"中的"max_memory_restart"，将其调高到一个相对安全的数值，比如从500M调整到1G。同时考虑启用集群模式，"instances: 'max'"或指定具体数量，让多个进程分摊内存压力。但注意，集群模式下每个子进程独立计算内存上限，如果内存泄漏存在，只是延缓了单个进程的重启时间，并没有根治。另一个紧急手段是设置"max_old_space_size"，在启动命令里加上"node --max-old-space-size=4096 app.js"，限制V8堆内存大小，防止Node无限制地吞噬内存。这个值一般设置为服务器物理内存的70%左右，留出余量给系统和其他进程。

根本治理必须找到内存泄漏点。Node.js内存泄漏常见于闭包未释放、全局变量持续增长、事件监听器未移除、定时器未清理、缓存无限膨胀等场景。推荐使用Chrome DevTools连接Node进程做堆快照对比。启动应用时加上"--inspect"参数，然后在Chrome浏览器访问"chrome://inspect"，连接到目标进程。在业务操作前拍一张堆快照，模拟用户操作一段时间后再拍一张，对比两张快照的Delta值，重点看Constructor列中Array、Object、String、Closure的数量增长。如果某个自定义类的实例数异常增加，那就是泄漏源。另一种更轻量的方式是使用"process.memoryUsage()"在代码中打点，记录"heapUsed"和"external"的变化趋势，配合"v8.getHeapStatistics()"获取更详细的堆信息。把这些数据写入日志或输出到监控系统，观察内存增长曲线是否呈锯齿状或持续上升。

闭包引用未释放是最隐蔽的泄漏。比如在Express中间件里对每个请求创建一个大的闭包对象，且该对象被某个长生命周期的变量引用。解决方式是确保请求处理结束后，相关引用置为null。事件监听器泄漏常见于EventEmitter，每次请求都"on"一个事件但没有对应的"removeListener"，导致监听器数组不断增长。改用"once"或者在请求结束时主动移除。缓存无限膨胀是另一个重灾区，使用"node-cache"或"lru-cache"等库时，必须设置TTL和最大条目数，不能放任一个普通Object或Map无限制增长。定时器"setInterval"如果在模块退出时不清理，回调函数持有的闭包会阻止垃圾回收。务必在进程退出信号或模块销毁逻辑中调用"clearInterval"。

有些重启并非内存泄漏，而是瞬时内存峰值超过了上限。比如一次性从数据库读取几十万条记录到内存中处理，或者上传大文件时全量读入Buffer。这类问题需要改用流式处理。数据库查询使用游标或分页，每次只取一批数据，处理完再取下一批。Node.js的"stream"模块是处理大数据的利器，"fs.createReadStream"配合"Transform"流可以边读边处理，内存占用恒定。对于JSON解析大文件，不要用"JSON.parse"一次性解析整个文件，使用"JSONStream"或"stream-json"这类流式解析库。如果业务必须进行大规模数组计算，考虑将计算任务转移到Worker Threads中，计算完成后传输结果，避免主线程堆内存膨胀。

PM2本身提供了一些辅助手段。"pm2 monit"可以实时查看进程CPU和内存占用，适合临时观察。更持久化的方案是配合"pm2-logrotate"做日志切割，避免日志文件撑爆磁盘。还可以编写自定义的PM2模块或利用"pm2 start"的"--cron-restart"参数在业务低峰期主动重启进程，作为一种兜底策略。但这只是治标不治本。真正推荐的做法是将内存指标接入外部监控系统，比如Prometheus + Grafana。在应用中引入"prom-client"库，暴露"process_heap_bytes"和"process_external_memory_bytes"等指标，设置Grafana告警规则，当堆内存使用率超过80%持续5分钟时发送通知，而不是等到PM2自动重启才被动响应。这样可以在问题恶化前介入，通过手动重启或触发降级开关来保护服务。

如果应用运行在Docker容器中，情况会更复杂。容器本身有内存限制，"docker run --memory=512m"。当容器内所有进程的内存总和超过这个限制，宿主机OOM Killer会杀死容器内进程，PM2的"max_memory_restart"此时可能来不及反应。建议将容器的内存限制设置为PM2内存上限的1.2倍左右，给PM2留出检测和重启的缓冲空间。同时容器内只运行一个Node进程，避免PM2的集群模式在容器内多实例叠加内存占用，导致OOM。Kubernetes环境下，"resources.limits.memory"和"resources.requests.memory"要合理设置，配合"livenessProbe"和"readinessProbe"做健康检查。如果进程频繁OOM重启，K8s会进入CrashLoopBackOff状态，此时需要结合"kubectl describe pod"和节点日志综合排查。

下面是一个在应用内集成内存监控和自动降级的示例代码，可以在内存逼近上限时主动释放非关键缓存或拒绝新请求，避免被PM2或系统强制杀死。

const v8 = require('v8');
const heapLimit = 400 * 1024 * 1024; // 400MB阈值

setInterval(() => {
  const stats = v8.getHeapStatistics();
  const usedHeap = stats.used_heap_size;
  if (usedHeap > heapLimit) {
    console.warn('堆内存接近上限，执行降级策略');
    // 清除非关键缓存
    if (global.cache) {
      global.cache.clear();
    }
    // 通知负载均衡摘除本节点
    process.send && process.send('memory_pressure');
  }
}, 10000);

这段代码每10秒检查一次堆内存使用量，超过400MB时主动清理缓存，并通过进程间通信通知父进程或管理端。如果使用PM2集群模式，可以在主进程收到"memory_pressure"消息后，暂时减少该工作进程的请求分发权重。这种主动防御比被动等待PM2重启要平滑得多，用户几乎无感知。

解决了当前问题后，要防止未来再次引入内存泄漏。在CI/CD流水线中加入内存性能测试，使用"autocannon"或"wrk"进行压力测试，同时用"clinic doctor"或"0x"生成火焰图和内存分析报告。设定内存基线，比如处理10000个请求后堆内存应稳定在200MB左右，如果代码变更导致内存增长超过20%，则阻断合入。这种工程化手段能从根本上减少生产环境的内存问题。同时定期审查依赖库的版本，有些内存泄漏可能来自第三方包，升级版本或更换库是必要的。保持Node.js版本更新也能获得V8引擎在垃圾回收方面的改进。

处理PM2内存上限自动重启，关键在于区分是配置不当、瞬时峰值还是代码泄漏，然后分别采取调整参数、流式处理、修复泄漏、建立监控的分层策略。单一手段无法彻底解决，必须组合使用才能让Node.js应用长期稳定运行。