A common observation for Node.js developers is the seemingly continuous growth of their application's memory footprint, often measured by the Resident Set Size (RSS) reported by the operating system. This increasing RSS frequently leads to concerns about memory leaks. As a result, many production environments configure monitoring and orchestration tools, like Kubernetes or Docker Swarm, to automatically restart or terminate Node.js processes when their RSS surpasses a certain percentage of the allocated memory limit, often around 80%. This is done assuming high RSS equates to a critical memory problem requiring intervention.
Node.js 开发者常观察到的一个现象是应用程序内存占用的持续增长，通常以操作系统报告的驻留集大小（RSS）衡量。这种 RSS 的持续上升常引发对内存泄漏的担忧。因此，许多生产环境会配置监控和编排工具（如 Kubernete 或 Docker Swarm），在 Node.js 进程的 RSS 超过分配内存限制的某个百分比（通常约为 80%）时自动重启或终止该进程。这一做法基于高 RSS 等同于需要干预的严重内存问题的假设。
However, it's crucial to understand that high RSS in a Node.js application does not automatically signify a memory leak in the conventional sense. V8, the underlying JavaScript engine, employs sophisticated memory management strategies focused on performance optimization. One key aspect is its tendency to retain memory segments acquired from the operating system, even after the JavaScript objects within those segments have become garbage. V8 holds onto this memory proactively, anticipating future allocation needs, thereby minimizing the performance cost of frequent memory requests and releases to the OS. This reserved but not actively used memory contributes to the overall RSS.
然而，关键要理解的是，Node.js 应用中的高 RSS 并不自动意味着传统意义上的内存泄漏。V8 作为底层 JavaScript 引擎，采用了专注于性能优化的复杂内存管理策略。其核心特点之一是倾向于保留从操作系统获取的内存段，即使这些内存段中的 JavaScript 对象已成为垃圾。V8 会主动持有这些内存，以预判未来的分配需求，从而减少频繁向操作系统申请和释放内存的性能开销。这部分被保留但未实际使用的内存会计入整体 RSS。
A real memory leak involves unreachable JavaScript objects that the garbage collector consistently fails to reclaim, leading to an unbounded increase in the memory actively used by the application's heap over time. A high but stable RSS, or an RSS that grows but periodically decreases after the major garbage collection cycle, indicates that V8 is managing its memory pool effectively for the given workload. Relying solely on RSS as an indicator for process termination can be misleading and may result in killing healthy applications. Accurate diagnosis requires inspecting V8's internal heap statistics (like heapUsed vs. heapTotal) to differentiate between V8's memory management and actual leaks where active heap usage grows indefinitely.
真正的内存泄漏涉及垃圾回收器持续未能回收的不可达 JavaScript 对象，导致应用程序堆中活跃使用的内存随时间无限增长。高但稳定的 RSS（常驻集大小），或 RSS 在主要垃圾回收周期后虽增长但周期性下降，表明 V8 针对给定工作负载有效管理其内存池。仅依赖 RSS 作为进程终止指标可能产生误导，并导致误杀健康应用。准确诊断需检查 V8 内部堆统计（如 heapUsed 与 heapTotal），以区分 V8 的内存管理与实际泄漏（即活跃堆使用量无限增长的情况）。
理解 V8 的分代垃圾回收器
The V8 engine's garbage collector is built upon the "generational hypothesis," a widely accepted principle in garbage collection theory. This hypothesis posits that most objects a program allocates become garbage shortly after creation ("die young"). In contrast, objects that persist beyond an initial period tend to remain alive for much longer. V8 organizes its memory heap into distinct generations to capitalize on this behavior, primarily the New Space (Young Generation) and the Old Space.
V8 引擎的垃圾回收器基于垃圾回收理论中广泛认可的"分代假说"构建。该假说认为，程序分配的大多数对象在创建后不久就会变成垃圾（"早逝"）。相反，那些在初始阶段后仍存活的对象往往具有更长的生命周期。为了利用这一行为特点，V8 将其内存堆划分为不同的代，主要是新生代（New Space）和老生代（Old Space）。
All new JavaScript objects are initially allocated within the New Space. This area is kept relatively small and is optimized for frequent, high-speed garbage collection using an algorithm called "Scavenge." Scavenge divides the New Space into two equal "semi-spaces." Objects are allocated into one semi-space until it fills. At that point, a Scavenge cycle begins: V8 rapidly identifies live objects in the filled semi-space by traversing reachable object references and copies these live objects into the second, currently empty, semi-space. After the copy, the first semi-space (containing only garbage) is completely cleared, and the roles of the semi-spaces are swapped. This fast "copying collection" mechanism is highly efficient when most objects are garbage, but necessitates that the New Space reserves twice the memory of its active allocation area.
所有新的 JavaScript 对象最初都被分配在新生代空间（New Space）中。该区域保持相对较小，并通过一种称为“Scavenge”的算法优化频繁且高速的垃圾回收。Scavenge 将新生代空间划分为两个相等的“半空间”。对象被分配到一个半空间直至其填满。此时，Scavenge 周期启动：V8 通过遍历可达对象引用快速识别已填满半空间中的存活对象，并将这些存活对象复制到当前为空的第二个半空间。复制完成后，第一个半空间（仅含垃圾）被完全清空，随后两个半空间的角色互换。当大多数对象为垃圾时，这种快速的“复制收集”机制效率极高，但要求新生代空间预留其活动分配区域两倍的内存。
Objects that endure through a couple of these rapid Scavenge cycles (typically two) are deemed likely to be long-lived. These surviving objects are then "promoted" – moved from the New Space into the significantly larger Old Space. The Old Space is intended for objects with longer lifecycles. Garbage collection in the Old Space is performed less frequently because it is more time-consuming. It primarily uses a "Mark & Sweep" algorithm: V8 traverses the entire object graph to mark all objects still reachable from the application's roots. Then, during the sweep phase, memory occupied by unmarked (garbage) objects is reclaimed. Optionally, V8 may perform a "Compaction" phase, rearranging the remaining live objects to reduce memory fragmentation. While compaction can lead to memory being returned to the operating system, V8 often retains this compacted space to optimize future Old Space allocations.
在经历几次快速的 Scavenge 周期（通常是两次）后仍然存活的对象被认为可能具有较长的生命周期。这些幸存下来的对象随后会被“晋升”——从新生代空间转移到容量大得多的老生代空间。老生代空间专为生命周期较长的对象设计。由于耗时较长，老生代空间的垃圾回收执行频率较低，主要采用“标记-清除”算法：V8 会遍历整个对象图，标记所有仍能从应用根节点访问到的对象。接着在清除阶段，回收未被标记（即垃圾对象）占用的内存。V8 可选择性地执行“压缩”阶段，重新排列剩余的存活对象以减少内存碎片。虽然压缩可能导致内存被返还给操作系统，但 V8 通常会保留这些压缩后的空间以优化未来的老生代空间分配。
性能陷阱：过早晋升
Despite its efficiency, the generational garbage collection strategy can sometimes lead to performance degradation, particularly under specific application workloads. Applications that exhibit very high rates of temporary object allocation, such as those heavily involved in complex data transformations, string manipulations, or especially server-side rendering (SSR) using frameworks like React or Next.js, are susceptible. During SSR, for instance, rendering a single complex page might create and quickly discard millions of short-lived objects.
尽管分代垃圾回收策略效率很高，但在特定应用负载下仍可能导致性能下降。那些临时对象分配率极高的应用尤其容易受到影响，例如涉及复杂数据转换、字符串操作或使用 React、Next.js 等框架进行服务器端渲染（SSR）的场景。以 SSR 为例，渲染单个复杂页面可能创建并迅速丢弃数百万个短生命周期对象。
The performance issue arises when the New Space, designed to be small for fast collection, fills up more rapidly than the Scavenge collector can process it. If allocations outpace collections significantly, objects that logically become garbage almost instantly might still be present during one or two Scavenge cycles simply because the collector didn't run frequently enough or quickly enough relative to the allocation rate. Though intended for a brief existence, these objects survive the initial GC cycles.