242 lines
8.9 KiB
Markdown
242 lines
8.9 KiB
Markdown
|
---
|
|||
|
|
tags: [go/lang, gc, tri-color-marking, write-barrier, pacer]
|
|||
|
|
create time: 2026-08-08 19:00
|
|||
|
|
update time: 2026-08-08 19:00
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# 三色标记 GC 原理
|
|||
|
|
|
|||
|
|
## 概述
|
|||
|
|
|
|||
|
|
Go 的垃圾回收器（GC）是 Go 语言高性能的核心支柱之一。从 v1.5 引入的三色标记清除算法到 v1.9 完善的混合写屏障，每一次演进都在压缩 STW（Stop-The-World）时间、提升并发效率。理解 GC 的工作原理，不仅能在面试中从容应对底层细节问题，更能指导写出低 GC 压力的代码。
|
|||
|
|
|
|||
|
|
> [!NOTE] 为什么需要三色标记？
|
|||
|
|
> 传统标记阶段必须暂停所有 goroutine（STW），如果标记期间对象引用关系发生变化（如 A 指向 B，然后 A 不再指向 B 但其他白色对象还指向 B），可能导致被错误回收。三色标记用颜色抽象解决了这个问题。
|
|||
|
|
|
|||
|
|
## 核心原理
|
|||
|
|
|
|||
|
|
### 三种颜色的含义
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
graph LR
|
|||
|
|
W["白色 White<br/>未扫描"] -->|"被扫描后"| G["灰色 Gray<br/>已发现但未扫描子节点"]
|
|||
|
|
G -->|"扫描完所有子节点后"| B["黑色 Black<br/>完全扫描过"]
|
|||
|
|
|
|||
|
|
style W fill:#f5f5f5,stroke:#9e9e9e,color:#000
|
|||
|
|
style G fill:#bbdefb,stroke:#1565c0,color:#000
|
|||
|
|
style B fill:#a5d6a7,stroke:#2e7d32,color:#000
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
| 颜色 | 含义 | GC 行为 |
|
|||
|
|
|------|------|--------|
|
|||
|
|
| **白色** | 未被标记访问过的对象 | 可能被回收 |
|
|||
|
|
| **灰色** | 已被发现，但其引用的对象尚未扫描 | 加入扫描队列 |
|
|||
|
|
| **黑色** | 已完成扫描且其引用的对象也都是黑色或灰色 | 不可回收，不会再次出现白色引用 |
|
|||
|
|
|
|||
|
|
关键不变性：**黑色对象永远不会直接引用白色对象**。这保证了任何可达对象都被正确标记。
|
|||
|
|
|
|||
|
|
### 扫描流程
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
flowchart TD
|
|||
|
|
A["STW: 标记根集<br/>所有全局变量/栈上的指针"] --> B["根对象标为灰色<br/>放入扫描队列"]
|
|||
|
|
|
|||
|
|
B --> C{"扫描队列空?"}
|
|||
|
|
C -->|否| D["取出一个灰色对象<br/>扫描它的所有字段"]
|
|||
|
|
D --> E["发现的白色子节点<br/>→ 标为灰色并入队"]
|
|||
|
|
E --> F["当前对象标为黑色"]
|
|||
|
|
F --> C
|
|||
|
|
|
|||
|
|
C -->|是| G["触发下一轮 STW<br/>准备进入清除阶段"]
|
|||
|
|
|
|||
|
|
style A fill:#ffcdd2
|
|||
|
|
style D fill:#fff3e0
|
|||
|
|
style G fill:#e8f5e9
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
每个被取出的灰色对象会被完整扫描：遍历其内存中的所有指针字段，对每个指针对象执行：
|
|||
|
|
|
|||
|
|
```go
|
|||
|
|
if obj.isWhite() {
|
|||
|
|
obj.color = gray // 从未发现变为已发现
|
|||
|
|
addScanQueue(obj) // 加入待扫描队列
|
|||
|
|
} else if obj.isGray() {
|
|||
|
|
whiteObjectDelta++ // 记录灰色对象的数量变化
|
|||
|
|
}
|
|||
|
|
// 自身标记为 black
|
|||
|
|
obj.color = black
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
> [!TIP] 面试常考点
|
|||
|
|
> Go GC 的扫描不是传统的标记阶段。标记和清除是交错进行的——当用户代码运行的同时，后台也有 goroutine 在执行 GC 扫描工作。这被称为"并发标记"。
|
|||
|
|
|
|||
|
|
### 混合写屏障（Hybrid Write Barrier）
|
|||
|
|
|
|||
|
|
这是 Go GC 最核心的创新之一。写屏障确保在并发标记期间，即使对象的引用关系被修改，也不会导致可达对象被误回收。
|
|||
|
|
|
|||
|
|
Go 在 v1.8 引入白色前置写屏障，v1.9 完善为混合写屏障（白色后置 + 白色前置）：
|
|||
|
|
|
|||
|
|
```go
|
|||
|
|
// 混合写屏障伪代码
|
|||
|
|
func storePointer(p *unsafe.Pointer, val unsafe.Pointer) {
|
|||
|
|
old := *p
|
|||
|
|
new := val
|
|||
|
|
|
|||
|
|
// 白色前置屏障
|
|||
|
|
if isWhite(old) {
|
|||
|
|
markWhiteObject(old) // 将旧值重新标灰
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
// 真正的赋值
|
|||
|
|
*p = new
|
|||
|
|
|
|||
|
|
// 白色后置屏障
|
|||
|
|
if isWhite(new) && isGray(gcWorker) {
|
|||
|
|
markGrayObject(new) // 将新值标灰
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
两种屏障的组合确保了即使在并发修改的情况下：
|
|||
|
|
- **白色前置**：保证被取消引用的旧白色对象不会被漏扫
|
|||
|
|
- **白色后置**：保证新引用的白色对象会被纳入扫描
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
sequenceDiagram
|
|||
|
|
participant M as "用户代码 (Mutator)"
|
|||
|
|
participant WB as "写屏障"
|
|||
|
|
participant GC as "GC 扫描线程"
|
|||
|
|
|
|||
|
|
M->>WB: ptr = newObject(white)
|
|||
|
|
WB->>GC: 白色后置: new → gray
|
|||
|
|
GC->>GC: 从队列取出 new 扫描
|
|||
|
|
|
|||
|
|
M->>WB: ptr = anotherObject(white)
|
|||
|
|
Note over WB: 旧值被移除
|
|||
|
|
WB->>GC: 白色前置: old → gray
|
|||
|
|
GC->>GC: 从队列取出 old 扫描
|
|||
|
|
|
|||
|
|
GC->>GC: 继续扫描...
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
> [!WARNING] 为什么叫"混合"写屏障？
|
|||
|
|
> 纯前置屏障只需要在赋值前检查旧值，简单但无法处理新值的情况；纯后置屏障则相反。混合方案结合了两者的优点，同时保证不遗漏任何应该被扫描的对象。代价是每个指针存储操作多了两次颜色检查。
|
|||
|
|
|
|||
|
|
### STW 阶段
|
|||
|
|
|
|||
|
|
整个 GC 周期包含若干 STW 阶段，Go 的目标是让它们尽可能短：
|
|||
|
|
|
|||
|
|
| 阶段 | Go 版本 | 作用 | STW 时长目标 |
|
|||
|
|
|------|---------|------|-------------|
|
|||
|
|
| 初始 STW | v1.5+ | 标记根集为灰色，启动后台扫描器 | < 1ms |
|
|||
|
|
| 终止 STW (v1.8 之前) | v1.5-v1.8 | 配合单纯写屏障 | < 1ms |
|
|||
|
|
| 终止 STW (混合屏障后) | v1.9+ | 完成最后一批对象的标记 | ~微秒级 |
|
|||
|
|
| 清除 STW | v1.5+ | 重置 freed 对象的白色状态 | ~几毫秒 |
|
|||
|
|
|
|||
|
|
Go 1.8 之后，除了初始化时的根集扫描和结束时的少量清理外，大部分 GC 工作与用户代码并行运行。
|
|||
|
|
|
|||
|
|
### Pacer 算法与触发阈值
|
|||
|
|
|
|||
|
|
Go 使用一个称为 Pacer 的反馈控制系统来决定何时触发 GC：
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
Pacer(t) = GC_time / Wall_time - target_fraction
|
|||
|
|
|
|||
|
|
触发条件:
|
|||
|
|
heap_live >= last_heap_live * 1.44^(Pacer调整系数)
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
核心参数：
|
|||
|
|
- **GCCyCleTargetRatio**: 默认 0.1（即 10%）。控制每轮 GC 占 CPU 时间的比例上限
|
|||
|
|
- **HeapGoal**: `heap_live` 增长 44% 时触发一轮 GC（e^0.37 ≈ 1.44）
|
|||
|
|
|
|||
|
|
这意味着 GC 触发频率自适应：堆越大、分配越快，GC 越频繁。Go 通过指数增长的阈值来平滑 GC 触发的节奏。
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
flowchart LR
|
|||
|
|
A["堆内存增长"] -->|"达到 threshold × 1.44"| B["触发 GC"]
|
|||
|
|
B --> C["STW: 标记根集"]
|
|||
|
|
C --> D["并发标记: 后台 goroutine 扫描"]
|
|||
|
|
D --> E["并发清除: 释放白色对象"]
|
|||
|
|
E --> F["更新 heap_live"]
|
|||
|
|
F --> A
|
|||
|
|
|
|||
|
|
style B fill:#ffebee
|
|||
|
|
style D fill:#e8f5e9
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### Go GC 演进历史
|
|||
|
|
|
|||
|
|
| 版本 | 关键改进 | 突破点 |
|
|||
|
|
|------|---------|--------|
|
|||
|
|
| v1.5 | 引入三色标记 + 并发标记 | 首次实现用户代码与 GC 并行 |
|
|||
|
|
| v1.8 | 引入白色前置写屏障 | 支持更灵活的并发策略 |
|
|||
|
|
| v1.9 | 混合写屏障 + 改进 Pacer | STW 时间大幅缩减至可忽略级别 |
|
|||
|
|
|
|||
|
|
> [!TIP] 面试加分项
|
|||
|
|
> 提到 Go 采用增量式 GC（incremental GC）而非全量 STW 标记，并且通过写屏障处理了并发场景下的引用一致性问题是证明你对 GC 有深入理解的标志。
|
|||
|
|
|
|||
|
|
## 代码示例
|
|||
|
|
|
|||
|
|
### 减少 GC 压力的预分配技巧
|
|||
|
|
|
|||
|
|
```go
|
|||
|
|
// ❌ GC 压力大：每次循环都创建新的临时切片
|
|||
|
|
func processItems(items []Item) []Result {
|
|||
|
|
var results []Result
|
|||
|
|
for _, item := range items {
|
|||
|
|
results = append(results, transform(item)) // 多次扩容 + GC
|
|||
|
|
}
|
|||
|
|
return results
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
// ✅ GC 友好：一次性预分配
|
|||
|
|
func processItemsOptimized(items []Item) []Result {
|
|||
|
|
results := make([]Result, len(items)) // 零额外分配
|
|||
|
|
for i, item := range items {
|
|||
|
|
results[i] = transform(item)
|
|||
|
|
}
|
|||
|
|
return results
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
预分配切片的价值在于：不仅避免了多次扩容的拷贝开销，更重要的是减少了 GC 需要跟踪的中间对象数量。在高吞吐场景中，这点优化可能带来显著的性能差异。
|
|||
|
|
|
|||
|
|
### 主动触发 GC（通常不需要）
|
|||
|
|
|
|||
|
|
```go
|
|||
|
|
runtime.GC() // 立即触发一次完整的 GC
|
|||
|
|
stats := runtime.MemStats{}
|
|||
|
|
runtime.ReadMemStats(&stats)
|
|||
|
|
fmt.Printf("heap alloc: %d bytes\n", stats.HeapAlloc)
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
大多数应用不应该主动调用 `runtime.GC()`——Go 的 Pacer 已经做得足够好。手动触发只适合 benchmark 或调试场景。
|
|||
|
|
|
|||
|
|
## 实践场景
|
|||
|
|
|
|||
|
|
### 面试高频问题
|
|||
|
|
|
|||
|
|
**Q: 什么时候会触发 GC？**
|
|||
|
|
当 `heap_live` 相较于上一轮 GC 结束时增长了约 44% 时触发。这个比例由 Pacer 动态调整。
|
|||
|
|
|
|||
|
|
**Q: 如何降低 GC 压力？**
|
|||
|
|
- 预分配已知大小的容器（map/slice），避免扩容
|
|||
|
|
- 复用对象（sync.Pool）
|
|||
|
|
- 减少短生命周期对象的创建（逃逸到堆上会增加 GC 负担）
|
|||
|
|
- 使用指针数组而非接口类型（消除间接引用）
|
|||
|
|
|
|||
|
|
**Q: STW 和 CTW 的区别？**
|
|||
|
|
STW (Stop-The-World) 是暂停所有用户 goroutine。CTW (Concurrent The-World) 是 Go 的特色——大部分 GC 工作与用户代码并发运行。Go 1.8 之后几乎没有真正意义上的 CTW。
|
|||
|
|
|
|||
|
|
### 实战建议
|
|||
|
|
|
|||
|
|
- **关注 Pprof heap profile**：定期审查哪些对象占用了最多的堆空间并存活时间过长
|
|||
|
|
- **使用 `GOGC=100` 调低 GC 频率**：高延迟敏感场景下可以让堆增长更多再触发 GC
|
|||
|
|
- **使用 `GOGC=10` 提高 GC 频率**：内存受限环境下减少峰值占用
|
|||
|
|
|
|||
|
|
## 扩展阅读
|
|||
|
|
|
|||
|
|
- [[Pprof 性能分析指南]] — pprof 中的 heap profile 可直接观察 GC 产生的对象分布
|
|||
|
|
- [[Goroutine 调度模型]] — GC 扫描工作由独立的 GC worker goroutine 执行
|