Linux 环境中 Node.js 如何优化内存使用

在 Linux 环境中运行 Node.js 应用，内存优化一直是个绕不开的话题。搞不好，服务撑不过几天就 OOM 了，或者干脆响应慢得像蜗牛。其实核心思路并不复杂，往下看。

先聊聊 V8 引擎的内存管理策略。Node.js 背后是 V8，它自带自动垃圾回收机制，但默认配置不一定适合所有人的场景。一个很实用的做法是通过 --max-old-space-size 参数来控制老生代空间的大小——比如你的应用是大量短生命周期的对象，那老生代空间可以设小一些；如果是长时间运行的内存缓存型服务，适当调大反而能减少 GC 频率。关键是，这个参数得根据实际负载反复调优，没有万能数字。

全局变量是个隐形杀手。只要声明在全局作用域中，对象就会一直活着，直到进程退出。这会造成内存只增不减。建议尽量把变量限制在函数或模块作用域内，用完后显式赋值为 null，给垃圾回收器一个明确的信号。别嫌麻烦，这个小习惯能省下不少内存。

缓存如果在项目中用得恰当，可以把重复计算和数据库查询的开销压到最低。但缓存如果不加限制，本身就是个内存黑洞。推荐采用 LRU（最近最少使用）策略，只保留最近被访问过的数据，旧的自动淘汰。像 lru-cache 这个库就很成熟，设置好最大条目数和存活时间，效果立竿见影。

数据结构的选型也值得多花一点心思。如果处理的是大量数值数据（比如数组、矩阵），普通 Ja vaScript 数组性能差且内存开销大。换成 Typed Arrays（比如 Float32Array、Uint8Array）能让内存使用直接砍半，而且运算速度更快。可惜很多人习惯了一刀切地用普通数组，这个点容易被忽略。

内存泄漏是最让人头疼的问题，但也不是没法治。常见的泄漏场景包括：忘了关闭文件描述符、数据库连接池用完不归还、事件监听器绑了不解除。写代码时多留个心眼，用完的资源及时释放。如果项目里已经出现了泄漏，可以借助 weak 或 finalization-registry 这类库来辅助回收。不过，最根本的办法还是养成良好的编码规范。

处理大文件时，千万别用 fs.readFileSync 一口气吞下整个文件。改用流（stream），逐块读取、处理、丢弃。比如用 fs.createReadStream 配合 pipeline，内存占用基本能压到几 MB 级别。同样的逻辑也适用于大 JSON 数据的解析——用流式解析器代替 JSON.parse。

大型任务分割成小块执行，这个原则在 Promise 和事件循环里特别实用。把一个大循环拆成多个小批次，每次处理完主动让出主线程，或者用 setImmediate 将剩余任务插回事件队列。这样既能避免单次分配过多内存导致堆溢出，又能保持应用响应性。

最后，别忘了把内存分析工具纳入日常。用 heapdump 抓堆快照，用 node-memwatch 检测内存泄漏趋势。跑压力测试时，配合 loadtest 或 artillery 模拟高并发，同时盯着内存曲线。一旦发现内存只升不降，马上 dump 下来分析——哪个对象占了多少、谁引用着它，一目了然。

说到底，内存优化不是一次性的活，而是持续监控、持续调整的过程。把上面几个点挨个落实，Linux 上的 Node.js 应用基本就能跑得稳、跑得省了。