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
func setGCPhase(x uint32) {
2
    atomic.Store(&gcphase, x)
3
    writeBarrier.enabled = x != _GCoff
4
}

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。

3.1 goal 的计算：GOGC 如何决定堆目标#

heap goal 的核心公式（简化版）：

1
goal = heapLive + (heapLive + stacks + globals) * GOGC / 100

其中：

• heapLive：上一轮 GC 结束时的存活堆大小
• stacks：所有 goroutine 栈占用的字节数
• globals：全局变量占用的字节数
• GOGC：默认 100，即允许堆增长 100%

直觉理解：如果上一轮 GC 结束时存活 100MB，GOGC=100，那么 goal = 100 + (100+stacks+globals)*1 = 200MB+（加上栈和全局变量的额外开销）。GC 的目标是”在堆增长到 goal 之前完成标记”。

当 GOGC=off（设为 -1）时，goal 被设为最大值，GC 不再基于堆大小触发（但 time trigger 和 GOMEMLIMIT 仍然有效）。

源码：gcControllerState.heapGoal 计算：mgcpacer.go。

3.2 trigger 的计算：runway 与上下界约束#

trigger 的计算比 goal 更复杂，因为它需要考虑”并发标记期间堆还会继续增长”这个事实。核心逻辑：

1
trigger = goal - runway

然后被 clamp 到 [minTrigger, maxTrigger] 范围内：

• minTrigger：不能低于上一轮 GC 结束时的 live 大小（否则 GC 会连续触发）
• maxTrigger：不能超过 goal（否则 GC 永远无法在 goal 前完成）

runway 的计算基于反馈控制：

1. 估计本轮需要扫描的总字节数（heap + stacks + globals）
2. 根据历史扫描速度（scanWork）和分配速度，估算标记需要多长时间
3. 在标记期间，mutator 还会继续分配，这些分配量就是 runway
4. runway = 扫描总字节数 / 扫描速度 * 分配速度

如果上一轮 GC 的扫描速度估计偏慢（实际更快），pacer 会在 endCycle 中修正，让下一轮的 runway 更小（触发更晚），减少不必要的 GC 频率。反之亦然。

源码：gcControllerState.trigger()：mgcpacer.go。

3.3 startCycle 与 endCycle：每个 GC cycle 的 pacer 闭环#

gcController.startCycle() 在 gcStart 中被调用，初始化本轮的扫描预算和 assist 比率：

• assistWorkPerByte：mutator 每分配 1 字节需要做多少扫描工作
• assistBytesPerWork：反过来，每做 1 单位扫描工作可以分配多少字节
• dedicatedMarkWorkersNeeded：需要多少个 dedicated worker
• fractionalUtilizationGoal：fractional worker 的 CPU 占用目标

gcController.endCycle() 在 gcMarkDone 中被调用，根据本轮实际扫描量和堆增长情况，计算下一个 cycle 的 trigger ratio，形成闭环反馈：

1
func (c *gcControllerState) endCycle() float64 {
2
    // 计算实际扫描量与预期扫描量的比率
3
    // 据此调整下一轮的 trigger ratio
4
    // 如果本轮扫描比预期快，下一轮可以触发更晚
5
    // 如果本轮扫描比预期慢，下一轮需要触发更早
6
}

源码：mgcpacer.go。

4.1 gcStart：从 _GCoff 进入 _GCmark#

触发后进入 gcStart(trigger)：

源码主干：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

1
func gcBgMarkWorker() {
2
    gp := getg()
3
    node := new(gcBgMarkWorkerNode)
4
    node.gp.set(gp)
5
    node.m.set(acquirem())
6
    notewakeup(&work.bgMarkReady)
7

8
    for {
9
        // park 到 pool，等待调度器或 GC 控制器唤醒
10
        gopark(func(g *g, nodep unsafe.Pointer) bool {
11
            node := (*gcBgMarkWorkerNode)(nodep)
12
            if mp := node.m.ptr(); mp != nil {
13
                releasem(mp)
14
            }
15
            gcBgMarkWorkerPool.push(&node.node)
16
            return true
17
        }, unsafe.Pointer(node), waitReasonGCWorkerIdle, traceEvGoBlock, 0)

1
case gcMarkWorkerDedicatedMode:
2
    gcDrain(&_p_.gcw, gcDrainUntilPreempt|gcDrainFlushBgCredit)
3
    if gp.preempt {
4
        lock(&sched.lock)
5
        for {
6
            gp, _ := runqget(_p_)
7
            if gp == nil {
8
                break
9
            }
10
            globrunqput(gp)
11
        }
12
        unlock(&sched.lock)
13
    }
14
    gcDrain(&_p_.gcw, gcDrainFlushBgCredit)

1
delta := nanotime() - gcController.markStartTime
2
if delta > 0 && float64(_p_.gcFractionalMarkTime)/float64(delta) > c.fractionalUtilizationGoal {
3
    return nil // 已达目标，不启动
4
}
5
_p_.gcMarkWorkerMode = gcMarkWorkerFractionalMode

1
if gcBlackenEnabled != 0 && _p_.gcBgMarkWorker != 0 && gcMarkWorkAvailable(_p_) {
2
    _p_.gcMarkWorkerMode = gcMarkWorkerIdleMode
3
    gp := _p_.gcBgMarkWorker.ptr()
4
    casgstatus(gp, _Gwaiting, _Grunnable)
5
    return gp, false
6
}

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

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

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

源码：mgcmark.go。

其中”取 work 的优先级”很重要（理解 root jobs 为什么不是独立阶段）： mgcmark.go

1
type gcWork struct {
2
    wbuf1, wbuf2 *workbuf  // 主/备缓冲区
3
    bytesMarked uint64     // 标记字节累计
4
    scanWork    int64      // 扫描工作量累计
5
    flushedWork bool       // 本次 dispose 是否往全局推送了 work
6
}

1
func (w *gcWork) balance() {
2
    if w.wbuf1 == nil {
3
        return
4
    }
5
    if w.wbuf2 == nil {
6
        w.wbuf2 = trygetfull()
7
    } else if w.wbuf1.nobj > 4 {
8
        w.wbuf2 = trygetfull()
9
        if w.wbuf2 != nil {
10
            putfull(w.wbuf1)  // 把较满的 wbuf1 放到全局
11
            w.wbuf1 = w.wbuf2
12
            w.wbuf2 = nil
13
        }
14
    }
15
}

1
// gcDrainN 的核心循环（简化）
2
for work != 0 {
3
    if work.full == 0 {
4
        gcw.balance()
5
    }
6
    b := gcw.tryGetFast()
7
    if b == 0 {
8
        b = gcw.tryGet()
9
        if b == 0 {
10
            wbBufFlush(nil, 0)
11
            b = gcw.tryGet()
12
        }
13
    }
14
    if b == 0 {
15
        break  // 确实没有 work 了
16
    }
17
    scanobject(b, gcw)  // 扫描对象，发现的指针通过 greyobject 入队
18
    // ... 累计 scanWork，检查是否该让出
19
}

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。

1
top:
2
    if !(gcphase == _GCmark && work.nwait == work.nproc && !gcMarkWorkAvailable(nil)) {
3
        return
4
    }
5
    gcMarkDoneFlushed = 0
6
    systemstack(func() {
7
        forEachP(func(_p_ *p) {
8
            wbBufFlush1(_p_)       // 刷写屏障缓冲
9
            _p_.gcw.dispose()      // 把本地 workbuf 推到全局
10
            if _p_.gcw.flushedWork {
11
                atomic.Xadd(&gcMarkDoneFlushed, 1)
12
                _p_.gcw.flushedWork = false
13
            }
14
        })
15
    })
16
    if gcMarkDoneFlushed != 0 {
17
        goto top  // 有新 work，重新判定
18
    }

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。

1
func gcMarkTermination(nextTriggerRatio float64) {
2
    atomic.Store(&gcBlackenEnabled, 0)
3
    setGCPhase(_GCmarktermination)
4

5
    systemstack(func() {
6
        gcMark(startTime)  // 最终标记：确保所有对象都已处理
7
    })
8

9
    // 标记完成，切换到 _GCoff
10
    systemstack(func() {
11
        setGCPhase(_GCoff)  // 关闭写屏障
12
        gcSweep(work.mode)  // 初始化 sweep 状态
13
    })
14

15
    // 更新触发比率与统计
16
    gcSetTriggerRatio(nextTriggerRatio)
17
    wakeScavenger()
18

19
    // 更新 memstats
20
    systemstack(func() {
21
        forEachP(func(_p_ *p) {
22
            _p_.mcache.prepareForSweep()
23
        })
24
    })
25

26
    // 恢复世界
27
    startTheWorldWithSema(true)
28
}

1
func sweepone() uintptr {
2
    _g_ := getg()
3
    _g_.m.locks++
4
    sg := mheap_.sweepgen
5
    for {
6
        s = mheap_.nextSpanForSweep()
7
        if s == nil { break }
8
        if s.sweepgen == sg-2 && atomic.Cas(&s.sweepgen, sg-2, sg-1) {
9
            break  // 找到待清扫 span，CAS 抢占
10
        }
11
    }
12
    if s != nil {
13
        if s.sweep(false) {
14
            atomic.Xadduintptr(&mheap_.reclaimCredit, npages)
15
        }
16
    }
17
    _g_.m.locks--
18
    return npages
19
}

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 栈处理的要求。

1
func mallocgc(size uintptr, typ *_type, needzero bool) unsafe.Pointer {
2
    ...
3
    if gcphase != _GCoff {
4
        gcmarknewobject(span, uintptr(x), size, scanSize)
5
    }
6
    ...
7
}
8

9
func gcmarknewobject(span *mspan, obj, size, scanSize uintptr) {
10
    objIndex := span.objIndex(obj)
11
    span.markBitsForIndex(objIndex).setMarked()  // 直接标黑
12
    arena, pageIdx, pageMask := pageIndexOf(span.base())
13
    if arena.pageMarks[pageIdx]&pageMask == 0 {
14
        atomic.Or8(&arena.pageMarks[pageIdx], pageMask)
15
    }
16
    gcw := &getg().m.p.ptr().gcw
17
    gcw.bytesMarked += uint64(size)
18
    gcw.scanWork += int64(scanSize)
19
}

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

你可以把它分成三层：

1
// DI = slot (写入目标地址)
2
// AX = ptr  (要写入的新值)
3
get_tls(BX)
4
MOVQ   g(BX), BX
5
MOVQ   g_m(BX), BX
6
MOVQ   m_p(BX), BX
7
MOVQ   (p_wbBuf+wbBuf_next)(BX), CX   // 当前 P 的 wbBuf 写指针
8
LEAQ   8(CX), CX                        // 推进 8 字节（一个指针）
9
MOVQ   CX, (p_wbBuf+wbBuf_next)(BX)    // 更新写指针
10
CMPL   CX, (p_wbBuf+wbBuf_end)(BX)     // 是否超出 buffer 末尾？
11
MOVQ   AX, -8(CX)                       // 记录新值 ptr
12
MOVQ   (DI), BX                         // 读取旧值 *slot
13
MOVQ   BX, -8+8(CX)                     // 记录旧值 *slot
14
JEQ    flush                             // buffer 满了，走慢路径
15
ret:
16
    MOVQ   AX, (DI)                     // 执行实际写操作 *slot = ptr
17
    RET
18
flush:
19
    CALL   runtime·wbBufFlush(SB)       // 刷 buffer
20
    JMP    ret

1
func wbBufFlush1(_p_ *p) {
2
    start := uintptr(_p_.wbBuf.start)
3
    end := uintptr(_p_.wbBuf.next)
4
    n := (end - start) / unsafe.Sizeof(uintptr(0)) / 2  // 指针对数量
5

6
    buf := (*[1 << 30]uintptr)(unsafe.Pointer(start))[:2*n]
7
    // 每一对 (old, new) 都需要检查
8
    var pos int
9
    for i := 0; i < 2*n; i += 2 {
10
        old := buf[i]
11
        new := buf[i+1]
12
        // 混合写屏障语义：shade(old) 始终执行
13
        // shade(new) 在当前栈未扫描时执行
14
        if old != 0 && isShaded(old) == false {
15
            shade(old)
16
            buf[pos] = old
17
            pos++
18
        }
19
        if stackScan && new != 0 && isShaded(new) == false {
20
            shade(new)
21
            buf[pos] = new
22
            pos++
23
        }
24
    }
25
    // 批量入队到 gcWork
26
    if pos > 0 {
27
        putObjBatch(&buf[0], pos)
28
    }
29
    _p_.wbBuf.next = _p_.wbBuf.start  // 重置 buffer
30
}

案例 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）：

Showing nodes accounting for 442.84MB, 98.28% of 450.59MB total

文件来源：allocs_top.txt（case1）

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

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

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

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

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

heap 结果（节选，inuse_space）：

Type: inuse_space

Showing nodes accounting for 63.88MB, 99.88% of 63.96MB total

文件来源：heap_top.txt（case2）

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

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

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

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

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

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

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

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

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

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

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

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

8.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 会显著增加扫描工作量

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

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

源码链路：

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

工程直觉：

当 GC 跟不上时，runtime 会把你的分配路径变慢，让你用 CPU 换内存上限与正确性。

1
assistG.gcAssistBytes -= int64(size)
2
if assistG.gcAssistBytes < 0 {
3
    gcAssistAlloc(assistG)  // 欠债了，必须做标记来还
4
}

1
func gcAssistAlloc(gp *g) {
2
retry:
3
    debtBytes := -gp.gcAssistBytes
4
    scanWork := int64(gcController.assistWorkPerByte * float64(debtBytes))
5

6
    // 第一步：尝试从全局信用池 bgScanCredit 借
7
    bgScanCredit := atomic.Loadint64(&gcController.bgScanCredit)
8
    stolen := int64(0)
9
    if bgScanCredit > 0 {
10
        if bgScanCredit < scanWork {
11
            stolen = bgScanCredit
12
            gp.gcAssistBytes += 1 + int64(gcController.assistBytesPerWork*float64(stolen))
13
        } else {
14
            stolen = scanWork
15
            gp.gcAssistBytes += debtBytes
16
        }
17
        atomic.Xaddint64(&gcController.bgScanCredit, -stolen)
18
        scanWork -= stolen
19
        if scanWork == 0 {
20
            return  // 借够了，不用自己做
21
        }
22
    }
23

24
    // 第二步：借不够，自己动手做标记
25
    systemstack(func() {
26
        gcAssistAlloc1(gp, scanWork)  // 内部调用 gcDrainN
27
    })
28

29
    // 第三步：做完还是欠债，park 到 assistQueue 等唤醒
30
    if gp.gcAssistBytes < 0 {
31
        if gp.preempt {
32
            Gosched()
33
            goto retry
34
        }
35
        if !gcParkAssist() {
36
            goto retry
37
        }
38
    }
39
}

1
func gcFlushBgCredit(scanWork int64) {
2
    if work.assistQueue.q.empty() {
3
        // 没人等，直接存入全局信用池
4
        atomic.Xaddint64(&gcController.bgScanCredit, scanWork)
5
        return
6
    }
7
    // 有人等，按债务大小依次唤醒
8
    scanBytes := int64(float64(scanWork) * gcController.assistBytesPerWork)
9
    for !work.assistQueue.q.empty() && scanBytes > 0 {
10
        gp := work.assistQueue.q.pop()
11
        if scanBytes+gp.gcAssistBytes >= 0 {
12
            scanBytes += gp.gcAssistBytes
13
            gp.gcAssistBytes = 0
14
            ready(gp, 0, false)  // 唤醒
15
        } else {
16
            gp.gcAssistBytes += scanBytes
17
            scanBytes = 0
18
            work.assistQueue.q.pushBack(gp)
19
            break
20
        }
21
    }
22
    // 剩余存入全局信用池
23
    if scanBytes > 0 {
24
        scanWork = int64(float64(scanBytes) * gcController.assistWorkPerByte)
25
        atomic.Xaddint64(&gcController.bgScanCredit, scanWork)
26
    }
27
}

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

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

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

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

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

• 碎片/RSS、指针密集扫描成本、root 集合过大、内存限制下可能近乎连续 GC。
  详见前面现存问题一节。

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

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

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

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

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

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

源码链路：

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

13.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

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

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

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

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

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

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

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

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

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

见前面 cycle 骨架一节与从 gcStart 到 gcMarkTermination 的源码级流程。函数入口：

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

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

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

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

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

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

常见方式：

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

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

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

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

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

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

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

见前面观察 GC 一节。最直接的是：

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

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

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

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

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

难点主要是：

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

源码落点：

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

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

见前面从 gcStart 到 gcMarkTermination 的源码级流程。如果你要一份「按函数链路走读」，也可以对照 runtime-gc-flow.md。

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

三类触发器：

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

统一判断入口 gcTrigger.test()：mgc.go。
入口来源见前面触发入口一节。

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

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

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

工程上通常盯三类：

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

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

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

见前面调优一节。最通用且最有效的路径是：

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

13.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（可进一步深挖）