网站首页 > 技术文章正文

优化 Node.js 性能:V8 内存管理和 GC 调优

ins518 2025-05-02 10:57:28 技术文章 12 ℃ 0 评论

大家好，很高兴又见面了，我是"高级前端进阶"，由我带着大家一起关注前端前沿、深入前端底层技术，大家一起进步，也欢迎大家关注、点赞、收藏、转发！

1. Node.js 应用较高的 RSS 并不意味着内存泄漏

Node.js 开发者经常会通过 RSS(Resident Set Size) 观察到内存占用持续增长，而这种不断增长的 RSS 经常会引发内存泄漏。因此，生产环境会配置监控和编排工具，例如：Kubernetes 或 Docker Swarm，以便在 RSS 超过分配内存限制的特定百分比时自动重启或终止 Node.js 进程。而前提是，高 RSS 等同于需要干预的严重内存问题。

Node.js 中的 RSS 是指进程内存中保存在 RAM 中的部分，其表示进程在给定时间内实际使用的内存。RSS 包括分配给堆、堆栈和其他内存区域的内存，以及共享库使用的内存，其是了解 Node.js 应用内存占用和性能的关键指标。

然而需要搞清楚的是，Node.js 应用中的高 RSS 值并不一定意味着传统意义上的内存泄漏。底层 JavaScript 引擎 V8 采用了专注于性能优化的复杂内存管理策略，例如：

V8 倾向于保留从 OS 获取的内存段，即使这些段中的 JavaScript 对象已成为垃圾。V8 会主动保留这些内存，预测未来的分配需求，从而最大限度地降低频繁向 OS 请求和释放内存的性能成本。而这些保留但未被主动使用的内存会影响整体 RSS。

于此对应，真正的内存泄漏是指垃圾收集器持续无法回收的 JavaScript 对象，从而导致应用程序堆的主动使用内存随时间推移而无限增长。

较高但稳定的 RSS 或在主要垃圾收集周期后增长但周期性下降的 RSS，表明 V8 正在针对给定的工作负载有效地管理其内存池。因此，仅仅依靠 RSS 作为进程终止的指标可能会产生误导，并导致健康的应用被终止。准确的诊断需要检查 V8 的内部堆统计信息，例如： heapUsed 与 heapTotal，以区分 V8 的内存管理和实际泄漏。

例如下面的示例：

const os = require('os');
function printMemoryUsage() {
  const memoryUsage = process.memoryUsage();
  const heapUsedMB = memoryUsage.heapUsed / (1024 * 1024);
  const heapTotalMB = memoryUsage.heapTotal / (1024 * 1024);
  const totalMemoryGB = os.totalmem() / (1024 ** 3);
  console.log(`Total System Memory: ${totalMemoryGB.toFixed(2)} GB`);
  console.log(`Heap Used: ${heapUsedMB.toFixed(2)} MB`);
  console.log(`Heap Total: ${heapTotalMB.toFixed(2)} MB`);
  console.log(`External: ${memoryUsage.external / (1024 * 1024).toFixed(2)} MB`);
}
function allocateMemory() {
  const arraySize = 10 * 1024 * 1024;
  // 10MB
  const array = new Array(arraySize).fill(0);
  return array;
}
printMemoryUsage();
const allocatedArray = allocateMemory();
printMemoryUsage();
setTimeout(() => {
  printMemoryUsage();
}, 2000);

2. 了解 V8 引擎的分代垃圾收集器

V8 引擎的垃圾收集器建立在分代假说 (generational hypothesis) 之上，其是垃圾收集理论中被广泛接受的原则。该假说认为，程序分配的大多数对象在创建后不久就会变成垃圾。相比之下，超过初始周期的对象往往会存活更长时间。V8 将其内存堆组织成不同的代，以利用这种行为，包括：新生代 (New Space) 和老生代 (Old Space)。

所有新的 JavaScript 对象最初都分配在新生代空间中，该区域相对较小，并使用名为 Scavenge 的算法进行优化，以达到频繁、高速的垃圾收集。Scavenge 将新生代空间划分为两个相等的 “半空间”，对象被分配到一个半空间中，直到该半空间填满。此时，Scavenge 循环开始：

V8 通过遍历可达的对象引用快速识别已填满的半空间中的存活对象，并将存活对象复制到当前为空的第二个半空间中
复制完成后，第一个半空间（仅包含垃圾）被完全清空，两个半空间的角色互换。这种快速的 “复制收集” 机制在大多数对象都是垃圾时非常高效，但需要新生代空间预留两倍于其活动分配区域的内存

能够经历两次以上的快速清除周期的对象被认为很可能是长寿的，对象随后会从新空间移至更大的老空间，而后者用于存放生命周期更长的对象。由于老空间的垃圾收集更耗时，因此执行频率较低，主要基于 “标记与清除” 算法：

V8 遍历整个对象图，标记所有从应用程序 root 可达的对象
在清除阶段，回收未被标记的对象占用的内存
V8 选择执行 “压缩” 阶段，重新排列剩余的存活对象以减少内存碎片

虽然压缩可以将内存返还给 OS，但 V8 通常会保留这些压缩后的空间以优化未来的老空间分配。

3. 性能陷阱：过早提升

尽管分代垃圾收集策略效率非常高，但有时还是会导致性能下降，尤其是在特定的应用程序工作负载下。那些临时对象分配率极高的应用程序，例如：涉及大量复杂数据转换、字符串操作，或者使用 React 或 Next.js 等框架进行服务器端渲染 (SSR) 的应用程序，很容易受到影响。例如，在 SSR 期间，渲染一个复杂页面可能会创建并快速丢弃数百万个短期对象。

function renderPage(data) {
    // 模拟生成复杂页面内容
    return `
        <html>
            <body>
                <h1>Complex Page</h1>
                ${data.map(item => `
                    <section>
                        <h2>${item.title}</h2>
                        <p>${item.text.slice(0, 50)}</p>
                        <ul>${item.list.map(listItem => `<li>${listItem}</li>`).join('')}</ul>
                    </section>
                `).join('')}
            </body>
        </html>
    `;
}
// 模拟复杂数据
const complexData = Array.from({length: 100}, (_, i) => ({
    title: `Section ${i}`,
    text: "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.",
    list: ["Item A", "Item B", "Item C", "Item D"],
}));
// 模拟多次渲染复杂页面
function simulateSSR() {
    console.log("Starting SSR simulation...");
    for (let i = 0; i < 1000; i++) {
        const renderedPage = renderPage(complexData);
        if (i % 100 === 0) console.log(`Rendered page ${i + 1}`);
    }
    console.log("SSR simulation completed.");
}
// 每次渲染都会创建大量的临时对象，包括：字符串、数组等
// 一个复杂的 React 站点可能分配大约 3000 个对象来在服务器上渲染页面
simulateSSR();

当新生代空间的填充速度超过 Scavenge 收集器时就会出现性能问题。如果分配速度明显超过收集速度，那么逻辑上几乎立即变成垃圾的对象可能仍会在一两个 Scavenge 循环中存活，而这仅仅是因为收集器的运行频率不够高或速度不够快。虽然此类对象寿命很短，但最终却在 GC 中存活了下来。

此类本质上是临时的对象，在经历了多次 Scavenge 后，会被错误地归类为潜在的长寿命对象，并被提升到老生代。这种 “过早提升” 会导致老生代空间中堆满可能在到达后不久就变成垃圾的对象。

而由于老生代空间被短寿命垃圾不成比例地填满，V8 引擎被迫更频繁地启动其速度较慢、资源更密集的标记清除垃圾收集器，从而增加请求延迟，并降低应用处理并发请求的能力，最终对性能产生负面影响。

4.V8 调优：配置

为了解决过早提升带来的性能挑战，Node.js 开发者可以通过调整新生代空间的大小来直接影响 V8 的垃圾收集器行为，例如： --max-semi-space-size。

// 模拟高内存分配率的场景
function allocateObjects() {
    const objects = [];
    for (let i = 0; i < 1e6; i++) {
        objects.push({id: i, data: "some temporary data"});
    }
    return objects;
}
function runTest() {
    console.log("Starting memory allocation test...");
    let totalRuns = 0;
    // 持续运行，直到手动停止
    const intervalId = setInterval(() => {
        allocateObjects(); // 分配大量临时对象
        totalRuns++;
        if (totalRuns % 10 === 0) {
            console.log(`Completed ${totalRuns} runs`);
        }
    }, 100);
    // 运行 10 秒后停止
    setTimeout(() => {
        clearInterval(intervalId);
        console.log("Memory allocation test completed.");
    }, 10000);
}
runTest();
// 通过下面的命令执行
// node --trace-gc --max-semi-space-size=32 your-script.js

该参数允许开发者指定新空间中两个半空间的最大值，例如：node --max-semi-space-size=64 index.js 表示 V8 允许每个半空间最大内存增长到 64 MB。

由于一次只有一个半空间处于活动分配状态，而另一个半空间则保留用于下一次 Scavenge 复制，因此年轻代可能占用最多 128 MB 的保留堆空间，但在触发 Scavenge 之前，其活动分配限制为 64 MB。该值很大程度上取决于应用特定的内存分配特性和系统总可用内存，通常每个半空间的范围在 16MB 到 256MB 之间。

通过增加 --max-semi-space-size，开发者可以为新分配的对象提供更大的缓冲区。此扩展为快速 Scavenge 收集器提供了更多时间和机会，使其能够在分配空间满之前识别和回收短期垃圾。

经过精心调优的更大新生代空间可显著降低过早提升至老生代的概率，此时缓慢且具有破坏性的老生代 GC 周期的频率会大幅降低，从而最大限度地减少应用程序暂停，并提高延迟和吞吐量。

5. 战略权衡：内存换计算性能

修改 --max-semi-space-size 代表了一种有意识且通常有益的性能调优决策，即以内存资源换取计算效率。增加年轻代半空间的大小，即明确允许 Node.js 进程预留并使用更大的物理内存，而增加的内存占用就是调优的成本。

注意：鉴于垃圾收集器也会消耗 CPU 时间，而后果是依赖项的延迟增加会导致 Node.js 应用程序中 CPU 使用率的增加。

内存使用量增加带来的好处是减少了垃圾收集所消耗的 CPU 时间和应用程序暂停时间。通过在更大的新空间中启用速度更快的 Scavenge 收集器来处理更大比例的短期垃圾对象，可以降低在老空间中调用速度更慢、更具破坏性的标记清除与压缩循环的频率，从而减少延迟和提升吞吐量。

在生产环境，尤其是在云基础架构或容器化部署中，与 CPU 周期或性能不佳的应用对业务的影响相比，RAM 通常被认为是一种更丰富、更便宜的资源。

6.Node v22+ 默认值和低内存注意事项

在 Node.js v22 中，V8 内存管理出现了一个重要的细微差别，即如何确定新空间半空间的默认大小。与一些早期版本使用更多静态默认值不同，较新的 V8 版本采用了启发式算法，尝试动态设置此默认大小，通常基于 Node.js 进程启动时可用的内存总量。其目的是在不同的硬件配置下提供合理的默认值，而无需手动调整。

虽然该动态方法在具有大量 RAM 的系统上表现良好，但在 Node.js 进程严格受内存限制的环境中可能导致性能不佳。这对于部署在容器，例如： Kubernetes 上的 Docker 或无服务器平台，例如： AWS Lambda 或 Google Cloud Functions 中的应用程序至关重要，因为这些平台的内存限制通常设置得相对较低。在这种情况下，V8 的动态计算可能会导致默认值 --max-semi-space-size 异常小，低至 <1 MB 或 8 MB。

for MiB in 16 32 64 128; do
    node --max-semi-space-size=$MiB index.js
done

严重不足的年轻代会大幅增加对象过早提升的可能性，从而频繁触发老生代 GC，最终导致性能下降。因此，对于在内存受限的环境中运行 Node.js v22 或更高版本的应用，通常不建议仅依赖 V8 的默认半空间大小设置。开发者应该认真考虑分析应用，并明确将 --max-semi-space-size 标志设置为在给定内存限制内适合其分配模式的值，从而确保年轻代具有足够的大小以实现高效的垃圾收集。

参考资料

https://v8.dev/blog/free-garbage-collection

https://blog.platformatic.dev/optimizing-nodejs-performance-v8-memory-management-and-gc-tuning

上一篇：都说Vue3跟Vue2比，性能优化很厉害!
下一篇：前端技术-Symbol在现实场景中的应用

网站首页 > 技术文章正文

优化 Node.js 性能:V8 内存管理和 GC 调优

1. Node.js 应用较高的 RSS 并不意味着内存泄漏

2. 了解 V8 引擎的分代垃圾收集器

3. 性能陷阱：过早提升

4.V8 调优：配置

5. 战略权衡：内存换计算性能

6.Node v22+ 默认值和低内存注意事项

参考资料

猜你喜欢

本文暂时没有评论，来添加一个吧(●'◡'●)

取消回复欢迎你发表评论:

网站首页 > 技术文章 正文

优化 Node.js 性能:V8 内存管理和 GC 调优

1. Node.js 应用较高的 RSS 并不意味着内存泄漏

2. 了解 V8 引擎的分代垃圾收集器

3. 性能陷阱：过早提升

4.V8 调优：配置

5. 战略权衡：内存换计算性能

6.Node v22+ 默认值和低内存注意事项

参考资料

猜你喜欢

本文暂时没有评论，来添加一个吧(●'◡'●)

取消回复欢迎 你 发表评论:

网站首页 > 技术文章正文

取消回复欢迎你发表评论: