1.1「cycle」的四个阶段#

Go runtime 定义的 GC cycle 包含：

1. sweep termination（STW）
2. mark（并发）
3. mark termination（STW）
4. sweep（通常并发）

源码证据：runtime.GC() 的注释对 cycle 定义得非常明确，它通过 work.cycles 等待「第 N 次 mark 完成」：mgc.go。

1.2 流程图：从触发到结束（建议收藏）#

对应源码主入口：

• 触发判断：gcTrigger.test：mgc.go
• 分配触发：mallocgc 末尾 heap trigger：malloc.go
• 启动与相位推进：gcStart：mgc.go
• 完成点与 ragged barrier：gcMarkDone：mgc.go
• mark termination 与 sweep：gcMarkTermination：mgc.go

1.3 两个“计数”别混：work.cycles vs memstats.numgc#

• work.cycles：cycle 计数（sweep term + mark + mark term + sweep）
• memstats.numgc：统计口径，在 mark termination 时递增（不是 cycle 末尾）

源码：work.cycles 注释强调它不同于 memstats.numgc：mgc.go，memstats.numgc++ 在 mark termination 后半段执行：mgc.go。

2.1 入口（Entrypoints）#

2.2 触发条件（gcTrigger.test）：为什么“该触发”但可能“没开始”#

触发逻辑统一由 gcTrigger.test() 判断，它有三层关卡：

1. 总闸门控：必须启用 GC、不能在 panic 过程中、且相位必须为 _GCoff if !memstats.enablegc || panicking!=0 || gcphase != _GCoff { return false } mgc.go

2. 触发种类：

• heap：heapLive >= trigger（trigger 来自 pacer） mgc.go

• time：now-last_gc_nanotime > forcegcperiod mgc.go

• cycle：目标 n 尚未开始（相对于 work.cycles） mgc.go

  3)「真正启动」还需通过 gcStart 的上下文安全检查：g0、持锁过多、preemptoff 等情况会直接 return，避免在脆弱上下文中启动 STW：mgc.go。

4.1 gcStart：从 _GCoff 进入 _GCmark#

触发后进入 gcStart(trigger)：

1. 安全检查（g0/锁/不可抢占则退出）
2. 先并发补扫 sweepone()（避免残留 unswept span）
3. 抢占相位推进权 work.startSema，再复核 trigger
4. 获取 gcsema/worldsema，STW 进入 sweep termination
5. finishsweep_m() + clearpools()
6. work.cycles.Add(1)，初始化 pacer：gcController.startCycle(...)
7. setGCPhase(_GCmark) 开写屏障
8. gcPrepareMarkRoots() 切 root jobs；gcMarkTinyAllocs()；gcBlackenEnabled=1
9. startTheWorldWithSema：并发 mark 开始

源码主干：mgc.go。

4.2 并发 mark 怎么推进？三条“发动机”#

并发 mark 的“推进”来自三条通道：

1. root jobs：在 STW 时把根扫描拆成 job，后续由 worker/assist 在 drain 循环中领取执行（不是独立阶段）

   • gcPrepareMarkRoots：mgcmark.go
   • markroot：mgcmark.go

2. 后台 mark workers：每个 P 有一个 worker G，平时 park 在 pool，调度器按需唤醒执行 drain

   • gcBgMarkStartWorkers：mgc.go
   • gcBgMarkWorker：mgc.go

3. mutator assists：分配太快时，分配 goroutine 会“欠债”，必须先帮着做标记工作才能继续分配

   • 扣债：deductAssistCredit：malloc.go
   • assist：gcAssistAlloc/gcAssistAlloc1：mgcmark.go

4.3 gcDrainN：并发标记的“消费灰对象”核心循环#

gcDrainN(gcw, scanWork) 是消费灰对象的核心循环（worker/assist 最终都会走到 drain）：

• 按优先级从 P 本地 workbuf、全局 workbuf、写屏障 buffer、root jobs 等获取工作
• 拿到对象就 scanobject，发现新指针就入队为灰对象

源码：mgcmark.go。

其中“取 work 的优先级”非常关键（理解 root jobs 为什么不是独立阶段）：
mgcmark.go

4.4 什么时候算“标记完成”？gcMarkDone + ragged barrier#

并发 mark 何时结束不是靠“全局轮询”，而是当 worker/assist 观察到： incnwait == work.nproc && !gcMarkWorkAvailable(nil) 时触发 gcMarkDone()
mgc.go

gcMarkWorkAvailable 会检查：

• 全局 workbuf/spanq 是否为空
• root jobs 是否还有
  mgc.go

gcMarkDone() 里最重要的工程细节是 ragged barrier：

• forEachP 刷写屏障缓冲 wbBufFlush1(pp)，并把每个 P 本地 pp.gcw.dispose() 刷到全局
• 如果 barrier 期间发现有新 work（gcMarkDoneFlushed != 0），就回到 top 重新判定

这是为了避免“本地缓存里还有灰对象”导致误判完成。
源码主干：mgc.go。

4.5 mark termination：gcMarkTermination → setGCPhase(_GCoff) → sweep#

gcMarkTermination(stw) 做最终 STW 收尾：

• setGCPhase(_GCmarktermination)（写屏障仍开）
• systemstack(gcMark(startTime)) 最终标记与一致性处理
• 标记完成后 setGCPhase(_GCoff) 关闭写屏障
• gcSweep(work.mode) 开始 sweep
• 更新 memstats 并唤醒 waiters

源码：mgc.go。

5.1 为什么需要写屏障？#

并发三色标记中，mutator 在 GC 标记期间仍然会修改对象图。如果不做约束，会破坏三色不变式，导致：

• 把一个“白对象”从灰集合里“漏掉”，最终被错误回收（悬垂引用）

写屏障的本质是：在 mutator 写指针时，额外做一点工作（记录 old/new 或者直接标记某个对象），保证并发标记的正确性。

在 Go runtime 里，写屏障开关由 setGCPhase 控制：
writeBarrier.enabled = (gcphase == _GCmark || gcphase == _GCmarktermination)
mgc.go

5.2 插入写屏障（Insertion barrier）是什么？Go 怎么实现？#

定义（Dijkstra insertion barrier 直觉版）：

• 当执行 *slot = ptr 时，对新写入的指针 ptr 做 shade/mark（或记录），保证新接入的可达对象不会漏标。

Go 的混合写屏障里确实包含 insertion barrier 的成分，但它是有条件的：只有当“当前 goroutine 栈还可能是灰色”时才对 ptr 做 shade（见 5.4）。

在实现层面：

• 编译器会在需要写指针的位置插入分支：if writeBarrier.enabled { ... } else { normal store }
  • writeBarrier 变量的布局刻意让编译器用 32-bit load 读 enabled：mgc.go
  • SSA 插桩逻辑在 cmd/compile/internal/ssa/writebarrier.go，它会加载 &runtime.writeBarrier 并判断非零走写屏障分支：writebarrier.go
• 写屏障分支会通过 OpWB（后端 lowering）调用 runtime.gcWriteBarrier{1..8} 申请一段 buffer，并把 old/new 指针写进去，后续由 runtime 批量处理。

5.3 删除写屏障（Deletion barrier）是什么？Go 怎么实现？#

定义（Yuasa deletion barrier 直觉版）：

• 当执行 *slot = ptr 时，对写入前旧值 *slot 做 shade/mark（或记录），避免旧的可达路径被 mutator 切断导致漏标。

在 Go 的混合写屏障伪代码里，“shade(*slot)”就是 deletion barrier 的部分（见 5.4）。

实现落点：

• 对于批量内存写（memmove/memclr 等），Go 在真正写入前走 bulkBarrierPreWrite，它会把目标区域里所有“即将被覆盖”的指针槽位的 old（以及需要时的 new）记录到 wbBuf：
  • bulkBarrierPreWrite：mbitmap.go
  • if !writeBarrier.enabled { return }：mbitmap.go

5.4 混合写屏障（Hybrid barrier）是什么？Go 具体用的就是它#

Go 在 runtime 源码里直接写出了混合写屏障的伪代码与说明，这是最硬的证据：

• 混合屏障说明：mbarrier.go

其伪代码核心是：

• shade(*slot)（deletion barrier：旧值）
• 如果当前 goroutine 的栈“仍可能灰”（尚未被扫黑），则 shade(ptr)（insertion barrier：新值）

这套组合解决了并发标记下常见的“黑->白”漏标风险，同时避免了某些纯 insertion 方案对 STW 栈处理的要求。

5.5 “Go 的写屏障”在工程实现上到底怎么落地？#

你可以把它分成三层：

案例 1：JSON 解码/编码导致的“小对象风暴”（典型 Web API）#

代码：case1-json-churn/main.go

你会在很多“网关/REST/GraphQL”链路里看到类似形态：

• 收到 JSON（[]byte）
• encoding/json.Unmarshal 到 map[string]any / []any
• 业务处理后 encoding/json.Marshal 回写

allocs 结果（节选，alloc_space）：

1
Showing nodes accounting for 442.84MB, 98.28% of 450.59MB total
2
      flat  flat%   sum%        cum   cum%
3
  152.68MB 33.88% 33.88%   236.11MB 52.40%  encoding/json.(*decodeState).objectInterface
4
   74.16MB 16.46% 50.34%   179.38MB 39.81%  encoding/json.Marshal
5
   65.36MB 14.51% 64.85%    65.36MB 14.51%  encoding/json.unquote (inline)
6
   58.70MB 13.03% 77.88%   104.75MB 23.25%  encoding/json.mapEncoder.encode
7
   24.54MB  5.45% 93.08%   260.65MB 57.85%  encoding/json.(*decodeState).arrayInterface
8
    1.64MB  0.36% 98.18%   267.47MB 59.36%  encoding/json.Unmarshal

文件来源：allocs_top.txt

读者视角的“干货结论”：

• map[string]any/[]any 是小对象放大器：每个元素/键值的解析都会引入大量短命对象与反射路径。
• 这类服务的 GC 压力通常先从“分配速率”爆发（alloc_space 非常高），再通过 pacer/assist 传导到“尾延迟”。

案例 2：无界缓存导致的“可达但无用”（典型内存泄漏形态）#

代码：case2-leaky-cache/main.go

这是最常见的“为什么有 GC 还会泄漏”的真实形态：对象一直可达（被 map/全局结构持有），因此 GC 永远不会回收。

heap 结果（节选，inuse_space）：

1
Type: inuse_space
2
Showing nodes accounting for 63.88MB, 99.88% of 63.96MB total
3
      flat  flat%   sum%        cum   cum%
4
   48.83MB 76.35% 76.35%    63.89MB 99.90%  runtime.main
5
   12.96MB 20.27% 96.62%    15.06MB 23.55%  main.main

文件来源：heap_top.txt

读者视角的“干货结论”：

• 只要引用链不断（比如全局 map / 长生命周期缓存 / goroutine 泄漏持有），GC 就不会回收；这就是“GC 语义上的泄漏”。
• 这类问题优先看 heap inuse（活对象占用），而不是 allocs（分配速率）。

案例 3：高并发 fan-out 管道：sync.Pool 让 allocs 断崖式下降#

代码：case3-fanout-pipeline/main.go

对比两次运行（同样 jobs/size，不同 -pool）：

1
Type: alloc_space
2
Showing nodes accounting for 53MB, 99.85% of 53.08MB total
3
      flat  flat%   sum%        cum   cum%
4
   50.75MB 95.61% 95.61%       53MB 99.85%  main.main

1
Type: alloc_space
2
Showing nodes accounting for 2792.18kB, 99.43% of 2808.19kB total
3
      flat  flat%   sum%        cum   cum%
4
 2305.13kB 82.09% 82.09%  2305.13kB 82.09%  runtime/trace.(*traceMultiplexer).startLocked
5
    5.53kB   0.2% 99.43%  2427.94kB 86.46%  main.main

7.1 先定目标：你要省内存，还是要省 CPU，还是要省暂停？#

Go 的调优通常是“三者取舍”：

• 更低的内存：更频繁 GC、更多写屏障与扫描 CPU
• 更低的 GC CPU：更高的内存峰值（更大的堆 goal）
• 更低的暂停：通常要减少 root 集合与写屏障 flush 压力，以及减少“大对象/大栈/大量 goroutine”

7.2 Scavenger（内存回收器）：如何把空闲内存归还给 OS？#

GC 的 sweep 阶段只是把对象标记为”空闲”，但对应的物理内存页并未归还给操作系统——进程的 RSS（Resident Set Size）可能远高于实际需要的堆大小。Scavenger 就是负责把空闲页的物理内存归还给 OS 的机制。

7.3 GOMEMLIMIT 与 GOGC 的交互：软内存上限如何影响 GC？#

Go 1.19 引入了 GOMEMLIMIT / debug.SetMemoryLimit，它是一个软内存上限（soft memory limit），与 GOGC 协同工作，让容器化场景下的内存控制更可预测。

1
MemStats.Sys - MemStats.HeapReleased

1
/memory/classes/total:bytes - /memory/classes/heap/released:bytes

7.4 你能直接调的旋钮#

1. GOGC / debug.SetGCPercent：调“目标堆增长比例”，从而影响 goal/trigger。
   SetGCPercent 的文档说明就在：runtime/debug/garbage.go

2. GOMEMLIMIT / debug.SetMemoryLimit：调“软内存上限”，runtime 会在内存压力下调高 GC 频率并更积极归还内存。
   见：runtime/debug/garbage.go

3. 减少堆分配（最有效）：

   • 减少小对象逃逸（逃逸分析、返回值、interface/closure 捕获等）
   • 尽量复用对象（sync.Pool 等）——注意这会改变内存曲线与 GC 行为，需配合 profile 验证

4. 减少指针密度/扫描成本：

   • 用切片/数组装“非指针元素”比链表/树更利于 GC（指针少、局部性好）
   • 大量 map[string]*T、[]*T 会显著增加扫描工作量

7.5 当分配速度 > 标记清除速度，会发生什么？#

答案是：Go 会通过 mutator assist 把压力转移到分配方，让分配 goroutine 自己做一部分标记工作，从而“强行把分配速率压下来”，防止堆失控增长。

源码链路：

• deductAssistCredit 扣减 g.gcAssistBytes，欠债则 gcAssistAlloc：malloc.go
• gcAssistAlloc 计算需要做多少 scanWork，并通过 gcDrainN 实际执行标记：mgcmark.go

工程直觉：

当 GC 跟不上时，runtime 不是“随它爆内存”，而是把你的分配路径变慢，让你用 CPU 换内存上限与正确性。

12.1 Go 语言历史版本在 GC 方面有哪些改进？#

• 核心里程碑：并发 tracing mark-sweep、混合写屏障、pacer 演进、内存限制（GOMEMLIMIT/SetMemoryLimit）。
  细节见本文第 8 节；源码侧可直接对照：
  • 并发相位骨架：_GCmark/_GCmarktermination：mgc.go
  • 混合写屏障伪代码注释：mbarrier.go
  • 软内存上限 API 语义：runtime/debug/garbage.go

12.2 Go GC 演化过程中有哪些设计没有被采用？为什么？#

• 分代、移动/压缩、引用计数、彻底无 STW 等，原因主要是：实现复杂度、与 unsafe/cgo 的兼容性、指针更新成本、以及 Go 对稳定低停顿的工程目标。
  详见本文第 9 节。

12.3 目前 Go 语言的 GC 还存在哪些问题？#

• 碎片/RSS、指针密集扫描成本、root 集合过大、内存限制下可能近乎连续 GC。
  详见本文第 10 节。

12.4 哪些编程语言提供 GC，哪些不提供？GC 和 No GC 各自的优缺点是什么？#

12.5 Go 语言的 GC 性能相比 Java 和 JS V8 引擎中的 GC 怎么样？#

这题没有统一答案，取决于你的“性能指标”（吞吐/暂停/内存）。建议按第 11 节的框架理解：Go 擅长低停顿、Java 擅长多策略覆盖（含压缩/分代）、V8 对 JS 分代/增量优化更深。

12.6 Go 语言中，为什么小对象多了会造成 GC 压力？#

因为追踪 GC 的成本与“对象数/指针数”强相关：

• 小对象越多 → 堆上对象数量越多 → 标记时要扫描/访问的对象元数据与指针槽位更多 → GC CPU 与 cache miss 增加
• 同时分配越频繁 → pacer 更容易触发 GC；若仍跟不上 → assist 让分配路径变慢

源码链路：

• 分配触发 GC：mallocgc 末尾触发检查：malloc.go
• 分配过快触发 assist：deductAssistCredit → gcAssistAlloc：malloc.go

12.7 Go 语言中两次 GC 周期重叠会引发什么问题，GC 触发机制是什么样的？#

先说结论：

• mark 相位不会重叠：因为 gcTrigger.test() 明确要求 gcphase == _GCoff，只要在 _GCmark/_GCmarktermination，新的触发 test 就会失败：mgc.go。
• 但 sweep 可以与下一轮 mark 并行：这正是并发 sweep 的设计（cycle 被分解了）。

为什么 mark 重叠会出大问题？

• 两轮 mark 会同时依赖写屏障语义与 mark bits/队列一致性；相位切换与终止条件会相互干扰，破坏正确性与统计口径。

在实现上，Go 用多把“推进锁”保证相位推进的唯一性：

• work.startSema 保护 _GCoff → _GCmark 的推进：mgc.go
• work.markDoneSema 保护 _GCmark → _GCmarktermination 的推进：mgc.go

12.8 什么是 Go 语言的插入写屏障？它又是如何实现的？#

• 定义见第 5.2 节（对新值 shade）。
• Go 的实现体现在“混合写屏障”的 insertion 部分，算法说明见：mbarrier.go。
• 工程实现链路：编译器插桩（SSA writebarrier.go）→ 调用 runtime.gcWriteBarrier*（汇编）→ 写入 wbBuf → wbBufFlush1 批处理入队。

12.9 什么是 Go 语言的删除写屏障？它又是如何实现的？#

• 定义见第 5.3 节（对旧值 shade）。
• Go 混合写屏障包含 deletion barrier，算法说明同样在：mbarrier.go。
• 批量写入场景的关键实现是 bulkBarrierPreWrite，它会在写入前把 old/new 指针记录到 buffer：mbitmap.go。

12.10 什么是 Go 语言的写屏障？它又是如何实现的？#

• 写屏障是并发标记的正确性装置：mutator 写指针时记录必要信息，保证不会漏标。
• Go 的 write barrier 开关由 setGCPhase 控制：mgc.go。
• 实现链路详见第 5.5 节（编译器插桩 + gcWriteBarrier 汇编 + wbBufFlush）。

12.11 什么是 Go 语言的混合写屏障？它又是如何实现的？#

• 定义与伪代码在 runtime 源码注释里写得非常清楚（Yuasa deletion + Dijkstra insertion）：mbarrier.go。
• 实现：插桩写指针写入、以及 bulkBarrierPreWrite 覆盖 memmove/memclr 等批量写路径（第 5 节）。

12.12 Go 语言中 GC 垃圾回收的过程是怎么样的？请介绍工作原理#

见本文第 1 节（cycle 骨架）与第 4 节（从 gcStart 到 gcMarkTermination 的源码级流程）。核心函数入口：

• gcStart：mgc.go
• gcMarkDone：mgc.go
• gcMarkTermination：mgc.go

12.13 什么是 Go 语言中的根对象？#

根对象（roots）是 GC 标记遍历的起点集合，典型包括：

• goroutine 栈上的指针
• 全局变量区（data/bss）中的指针
• runtime 自己维护的一些固定根（finalizer、cleanup 队列等）

源码里，gcPrepareMarkRoots() 在 STW 下把 roots 拆成 job，并把要扫描的 goroutine 快照到 work.stackRoots：mgcmark.go。

12.14 常见的 GC 实现方式有哪些？Go 语言使用的是什么 GC 实现？#

常见方式：

• 引用计数（RC）
• 追踪式：标记-清扫、标记-整理（压缩）、复制（copying）
• 分代 GC（通常结合复制/整理）

Go runtime 的主实现是：并发追踪式标记-清扫（concurrent mark-sweep），配合写屏障与 pacer、并发 sweep、mutator assist。

12.15 Go 语言中的三色标记法是什么？#

三色标记是追踪式标记的一个并发正确性框架：

• 白：未发现（可能垃圾）
• 灰：已发现但未扫描其指针
• 黑：已扫描完成

并发下关键是不允许“黑对象指向白对象”而白对象又不被灰化（否则漏标）。写屏障就是为此服务。

12.16 如何观察 Go 语言的 GC 运行情况？#

见第 6 节。最直接的是：

• GODEBUG=gctrace=1（runtime 打印位置：mgc.go）
• runtime/metrics、pprof、trace

12.17 在有 GC 的情况下，为什么 Go 语言中仍会发生内存泄漏？#

因为 GC 只回收“不可达”的对象。只要对象仍可达，它就不会被回收；工程上常见的“可达但无用”包括：

• 全局 map 缓存无限增长
• goroutine 泄漏（持有引用链）
• channel/队列里残留引用
• sync.Pool/内部缓存导致的高水位（不是泄漏但表现类似）
• finalizer/cleanup 或外部资源引用链不释放
• C 侧分配内存（cgo）不在 Go GC 管理范围

12.18 Go 语言中并发标记清除法的难点是什么？#

难点主要是：

• 并发修改对象图导致的正确性（需要写屏障、终止条件验证、ragged barrier）
• 低争用的工作队列设计（P 本地 + 全局 workbuf）
• 触发时机（pacer）与极端情况（分配突刺、root 暴涨）

源码落点：

• gcMarkDone 的 ragged barrier：mgc.go
• gcDrainN 的 work 获取优先级与 root job 领取：mgcmark.go

12.19 Go 语言中 GC 的具体流程是什么？#

见第 4 节（从 gcStart 到 gcMarkTermination）。如果你要一份“按函数链路走读”，也可以看：runtime-gc-flow.md。

12.20 Go 语言中触发 GC 的时机是什么？#

三类触发器：

• heap：heapLive >= trigger
• time：超过 forcegcperiod
• cycle：runtime.GC() 强制开启下一轮

统一判断入口 gcTrigger.test()：mgc.go。
入口来源见第 2.1 节。

12.21 如果内存分配速度超过了标记清除的速度，Go 语言会如何处理？#

通过 mutator assist 把分配方变慢，并强制其执行标记工作（第 7.5 节）。
源码链路见：malloc.go 与 mgcmark.go。

12.22 Go 语言的 GC 关注的主要指标有哪些？#

工程上通常盯三类：

• 暂停：STW pause（p50/p99/最大）
• CPU：GC CPU fraction、assist/dedicated/idle 时间组成
• 内存：heap live、heap goal、RSS/碎片、scavenger 归还效果

源码里 gctrace 打印的字段非常贴近这三类指标：mgc.go。

12.23 如何对 Go 语言的 GC 进行调优？#

见第 7 节。最通用且最有效的路径是：

• 先用 allocs/heap profile 找分配热点与逃逸
• 通过减少堆分配、降低指针密度、复用对象，把“根因”压下去
• 再用 GOGC/GOMEMLIMIT 做资源取舍调参，并用指标验证

12.24 Go 语言垃圾回收器的相关 API 有哪些？它们的作用分别是什么？#

常用 API（按“你真会用到”的频率排序）：

• runtime.GC()：强制触发并等待一轮完整 cycle（见第 2.1C）
  mgc.go
• runtime.ReadMemStats：读取 MemStats（用于观测）
  对应结构体更新点在 mark termination：mgc.go
• runtime/debug.SetGCPercent：设置 GOGC（调频）
  runtime/debug/garbage.go
• runtime/debug.SetMemoryLimit / GOMEMLIMIT：设置软内存上限（容器化场景很重要）
  runtime/debug/garbage.go
• runtime/debug.FreeOSMemory()：GC() + 更积极归还内存给 OS
  runtime/debug/garbage.go
• runtime.SetFinalizer：终结器（谨慎使用，会影响对象可回收时机与 GC 行为）
  终结器处理在 mfinal.go（可进一步深挖）

Q1：GOGC 和 GOMEMLIMIT 应该设置哪个？#

Go 1.19+ 推荐使用 GOMEMLIMIT 设置内存上限，GOGC 作为辅助。GOMEMLIMIT=off 可禁用内存限制仅用 GOGC。两者可同时设置，GOMEMLIMIT 优先。

Q2：GC 触发频率可以手动控制吗？#

可以通过 debug.SetGCPercent() 调整 GOGC 值。GOGC=100 表示堆增长 100% 时触发；GOGC=off 关闭 GC（危险！）；GOGC=0 表示每次分配都触发 GC。

Q3：为什么 Go 选择并发标记-清除而非分代 GC？#

Go 的设计哲学是简洁和低延迟。分代 GC 需要写屏障区分老年代和新年代引用，增加运行时复杂度。Go 的并发标记-清除通过 GC Assist 机制控制延迟，更符合 Go 的设计理念。

Q4：如何判断 GC 是否成为性能瓶颈？#

使用 runtime.ReadMemStats 观察 GCCPUFraction（GC 占用 CPU 比例），超过 10% 说明 GC 压力大。也可用 go tool trace 查看 GC 事件的频率和持续时间。