V8垃圾回收调优原理

V8 GC 采用分代回收策略，理解 GC 原理有助于编写内存高效代码并进行参数调优。

V8 分代回收架构

内存分代

+------------------------+------------------------+
|       New Space        |       Old Space        |
|  (Semispace 1-8MB)     |    (数十MB到GB)        |
+------------------------+------------------------+
|   Scavenge GC          |   Mark-Sweep-Compact   |
|   快速、频繁           |   慢速、全面           |
+------------------------+------------------------+

对象晋升规则

新对象 → New Space 分配
    ↓
存活 1-2 次 Scavenge → 晋升 Old Space
    ↓
Old Space 满 → Mark-Sweep GC

新生代 GC：Scavenge

Cheney 算法原理

New Space 分两半：
+----------+----------+
|  From    |   To     |
| (活跃)   | (空闲)   |
+----------+----------+

GC 流程：
1. From 空间扫描存活对象
2. 复制存活对象到 To 穆间
3. 交换 From/To 角色
4. 存活多次对象晋升 Old Space

Scavenge 特点

优点：
- 时间短（只扫描半空间）
- 无碎片（复制时自动整理）
- 分配快（指针碰撞分配）

缺点：
- 空间利用率低（50%）
- 复制开销（存活对象多时慢）

触发条件

// New Space 空间耗尽时触发
// 默认 New Space 大小：1-8MB（根据系统调整）

// 查看当前大小
const v8 = require('v8');
const stats = v8.getHeapStatistics();
console.log('New Space:', stats.new_space_size / 1024 / 1024, 'MB');

老生代 GC：Mark-Sweep-Compact

三阶段流程

1. Mark（标记）
   ├─ 从 GC Roots 开始
   ├─ 标记所有可达对象
   └─ 白→灰→黑 三色标记

2. Sweep（清除）
   ├─ 扫描堆空间
   └─ 清除未标记对象

3. Compact（整理）
   ├─ 移动存活对象
   ├─ 消除内存碎片
   └─ 更新引用地址

三色标记算法

白色：未访问，GC 后回收
灰色：已访问但引用未扫描
黑色：已访问且引用已扫描

初始：全部白色
GC Root → 灰色
扫描灰色引用 → 子对象变灰，自己变黑
最终：黑色存活，白色回收

增量标记（Incremental Marking）

传统标记：一次性完成，长停顿

增量标记：
  JS执行 ── GC标记 ── JS执行 ── GC标记 ── ...
  将标记拆成多步，减少单次停顿

┌──────────────────────────────────────────────┐
│ JS │GC│ JS │GC│ JS │GC│ JS │GC│ JS │Sweep │
└──────────────────────────────────────────────┘

并行/并发 GC（Parallel/Concurrent）

并行 GC：
- 主线程 + 辅助线程同时 GC
- 利用多核 CPU

并发 GC：
- GC 在后台线程运行
- 主线程几乎无停顿
- 需要 Write Barrier 同步

V8 6.0+ 默认：
- 新生代：并行 Scavenge
- 老生代：并发标记 + 并行整理

GC 触发条件与调优

触发条件

1. New Space 空间耗尽 → Scavenge
2. Old Space 达到阈值 → Mark-Sweep
3. 内存分配失败 → Full GC
4. 手动触发（不推荐）

堆内存参数

# 设置堆内存上限
node --max-old-space-size=4096 app.js  # 4GB

# 设置新生代大小
node --max-semi-space-size=8 app.js    # 8MB

# 完整参数
node \
  --max-old-space-size=4096 \
  --max-semi-space-size=4 \
  --max-heap-size=4096 \
  app.js

参数调优策略

查看默认限制

const v8 = require('v8');

console.log('Heap Limit:', v8.getHeapStatistics().heap_size_limit / 1024 / 1024, 'MB');
// 64位系统默认约 1.4GB
// 32位系统默认约 700MB

GC 性能监控

监控 GC 统计

const v8 = require('v8');

setInterval(() => {
  const stats = v8.getHeapStatistics();
  console.log({
    used: (stats.used_heap_size / 1024 / 1024).toFixed(2) + ' MB',
    total: (stats.total_heap_size / 1024 / 1024).toFixed(2) + ' MB',
    external: (stats.external_memory / 1024 / 1024).toFixed(2) + ' MB'
  });
}, 5000);

GC 日志追踪

# 打印 GC 日志
node --trace-gc app.js

# 详细 GC 日志
node --trace-gc --trace-gc-verbose app.js

# 输出示例
[12345:0x123] Scavenge 1.2 (3.4) -> 0.8 (4.0) MB, 2.5 ms
[12345:0x123] Mark-sweep 100.2 (150.0) -> 80.5 (150.0) MB, 50.3 ms

GC 时间统计

const { performance, PerformanceObserver } = require('perf_hooks');

const obs = new PerformanceObserver((list) => {
  const entries = list.getEntries();
  entries.forEach(entry => {
    console.log(`GC: ${entry.kind}, Duration: ${entry.duration.toFixed(2)}ms`);
  });
});
obs.observe({ entryTypes: ['gc'] });

// GC 类型
// - minor: 新生代 GC (Scavenge)
// - major: 老生代 GC (Mark-Sweep)
// - incremental: 增量标记

GC 频率分析

let gcCount = { minor: 0, major: 0 };

const obs = new PerformanceObserver((list) => {
  list.getEntries().forEach(entry => {
    gcCount[entry.kind]++;
  });
});
obs.observe({ entryTypes: ['gc'] });

setInterval(() => {
  console.log('GC counts:', gcCount);
}, 60000);

// 健康指标
// - minor GC: 几十次/分钟（正常）
// - major GC: 几次/分钟（需关注）
// - major GC > 10次/分钟: 可能内存问题

GC 调优实践

场景1：内存敏感应用

# 增大堆内存，减少 GC 频率
node --max-old-space-size=2048 app.js

# 增大新生代，减少晋升
node --max-semi-space-size=16 app.js

场景2：低延迟应用

// 代码层面减少 GC 压力
// 1. 预分配对象池
const objectPool = [];
for (let i = 0; i < 1000; i++) {
  objectPool.push({ data: null, reset() { this.data = null; } });
}

// 2. 减少临时对象
function process(buffer) {
  // 复用 buffer 而非新建
  buffer.fill(0);
}

// 3. 避免大对象频繁分配
const reusableBuffer = Buffer.alloc(1024 * 1024);

场景3：高吞吐应用

# 平衡内存和吞吐
# 堆太大：GC 时间长
# 堆太小：GC 频率高

# 找最佳值：从默认开始测试
node app.js                     # 默认 1.4GB
node --max-old-space-size=512 app.js  # 测试不同大小
node --max-old-space-size=2048 app.js

# 监控 GC 时间占比
# 目标：GC 时间 < 5% 总执行时间

GC 与代码优化

减少对象分配

// 热点：循环内创建对象
for (let i = 0; i < 10000; i++) {
  const obj = { id: i, value: 0 };  // 每次新建
  process(obj);
}

// 优化：复用对象
const obj = { id: 0, value: 0 };
for (let i = 0; i < 10000; i++) {
  obj.id = i;
  obj.value = 0;
  process(obj);
}

减少晋升压力

// 问题：短生命周期对象过多
function handler() {
  const temp = { data: largeData };  // 可能晋升
  return temp.data.value;
}

// 优化：避免创建中间对象
function handler() {
  return largeData.value;  // 直接访问
}

及时释放引用

// 问题：引用未释放
let cache = loadData();
// 使用后不清理
processSomethingElse();  // cache 仍在引用

// 优化：主动释放
let cache = loadData();
process(cache);
cache = null;  // 允许 GC 回收

避免内存碎片

// 问题：频繁创建不同大小对象
for (let i = 0; i < 1000; i++) {
  const buf = Buffer.alloc(Math.random() * 10000);
}

// 优化：固定大小对象池
const pool = [];
const CHUNK_SIZE = 4096;
for (let i = 0; i < 1000; i++) {
  pool.push(Buffer.alloc(CHUNK_SIZE));
}

GC 参数决策流程

1. 监控 GC 频率和时间
   ↓ major GC 频率过高
2. 分析内存使用情况
   ↓ 内存接近上限
3. 调整堆大小
   ↓ --max-old-space-size
4. 观察效果
   ↓ GC 频率下降？
5. 微调参数
   ↓ 找最优配置

注意：手动调用 global.gc() 在生产环境不推荐，可能导致不可预测的停顿。

要点总结

• 新生代使用 Scavenge 复制算法，快速但空间利用率低
• 老生代使用 Mark-Sweep-Compact，增量/并发减少停顿
• 增大堆内存减少 GC 频率，但增加单次 GC 时间
• 代码层面减少临时对象分配，复用对象池
• 监控 GC 时间占比，目标 < 5% 总执行时间