20. 目前 Go 语言的 GC 还存在哪些问题？

尽管 Go 团队宣称 STW 停顿时间得以优化到 100 微秒级别，但这本质上是一种取舍。原本的 STW 某种意义上来说其实转移到了可能导致用户代码停顿的几个位置；除此之外，由于运行时调度器的实现方式，同样对 GC 存在一定程度的影响。

目前 Go 中的 GC 仍然存在以下问题：

1. Mark Assist 停顿时间过长

  1. package main
  3. import (
  4.     "fmt"
  5.     "os"
  6.     "runtime"
  7.     "runtime/trace"
  8.     "time"
  9. )
  11. const (
  12.     windowSize = 200000
  13.     msgCount   = 1000000
  14. )
  16. var (
  17.     best    time.Duration = time.Second
  18.     bestAt  time.Time
  19.     worst   time.Duration
  20.     worstAt time.Time
  22.     start = time.Now()
  23. )
  25. func main() {
  26.     f, _ := os.Create("trace.out")
  27.     defer f.Close()
  28.     trace.Start(f)
  29.     defer trace.Stop()
  31.     for i := 0; i < 5; i++ {
  32.         measure()
  33.         worst = 0
  34.         best = time.Second
  35.         runtime.GC()
  36.     }
  37. }
  39. func measure() {
  40.     var c channel
  41.     for i := 0; i < msgCount; i++ {
  42.         c.sendMsg(i)
  43.     }
  44.     fmt.Printf("Best send delay %v at %v, worst send delay: %v at %v. Wall clock: %v \n", best, bestAt.Sub(start), worst, worstAt.Sub(start), time.Since(start))
  45. }
  47. type channel [windowSize][]byte
  49. func (c *channel) sendMsg(id int) {
  50.     start := time.Now()
  52.     // 模拟发送
  53.     (*c)[id%windowSize] = newMsg(id)
  55.     end := time.Now()
  56.     elapsed := end.Sub(start)
  57.     if elapsed > worst {
  58.         worst = elapsed
  59.         worstAt = end
  60.     }
  61.     if elapsed < best {
  62.         best = elapsed
  63.         bestAt = end
  64.     }
  65. }
  67. func newMsg(n int) []byte {
  68.     m := make([]byte, 1024)
  69.     for i := range m {
  70.         m[i] = byte(n)
  71.     }
  72.     return m
  73. }

运行此程序我们可以得到类似下面的结果：

  1. $ go run main.go
  3. Best send delay 330ns at 773.037956ms, worst send delay: 7.127915ms at 579.835487ms. Wall clock: 831.066632ms 
  4. Best send delay 331ns at 873.672966ms, worst send delay: 6.731947ms at 1.023969626s. Wall clock: 1.515295559s 
  5. Best send delay 330ns at 1.812141567s, worst send delay: 5.34028ms at 2.193858359s. Wall clock: 2.199921749s 
  6. Best send delay 338ns at 2.722161771s, worst send delay: 7.479482ms at 2.665355216s. Wall clock: 2.920174197s 
  7. Best send delay 337ns at 3.173649445s, worst send delay: 6.989577ms at 3.361716121s. Wall clock: 3.615079348s

总结 - 图1

在这个结果中，第一次的最坏延迟时间高达 7.12 毫秒，发生在程序运行 578 毫秒左右。通过 go tool trace 可以发现，这个时间段中，Mark Assist 执行了 7112312ns，约为 7.127915ms；可见，此时最坏情况下，标记辅助拖慢了用户代码的执行，是造成 7 毫秒延迟的原因。

2. Sweep 停顿时间过长

同样还是刚才的例子，如果我们仔细观察 Mark Assist 后发生的 Sweep 阶段，竟然对用户代码的影响长达约 30ms，根据调用栈信息可以看到，该 Sweep 过程发生在内存分配阶段：

总结 - 图2

3. 由于 GC 算法的不正确性导致 GC 周期被迫重新执行

此问题很难复现，但是一个已知的问题，根据 Go 团队的描述，能够在 1334 次构建中发生一次 [15]，我们可以计算出其触发概率约为 0.0007496251874。虽然发生概率很低，但一旦发生，GC 需要被重新执行，非常不幸。

4. 创建大量 Goroutine 后导致 GC 消耗更多的 CPU

这个问题可以通过以下程序进行验证：

  1. func BenchmarkGCLargeGs(b *testing.B) {
  2.     wg := sync.WaitGroup{}
  4.     for ng := 100; ng <= 1000000; ng *= 10 {
  5.         b.Run(fmt.Sprintf("#g-%d", ng), func(b *testing.B) {
  6.             // 创建大量 goroutine，由于每次创建的 goroutine 会休眠
  7.             // 从而运行时不会复用正在休眠的 goroutine，进而不断创建新的 g
  8.             wg.Add(ng)
  9.             for i := 0; i < ng; i++ {
  10.                 go func() {
  11.                     time.Sleep(100 * time.Millisecond)
  12.                     wg.Done()
  13.                 }()
  14.             }
  15.             wg.Wait()
  17.             // 现运行一次 GC 来提供一致的内存环境
  18.             runtime.GC()
  20.             // 记录运行 b.N 次 GC 需要的时间
  21.             b.ResetTimer()
  22.             for i := 0; i < b.N; i++ {
  23.                 runtime.GC()
  24.             }
  25.         })
  27.     }
  28. }

其结果可以通过如下指令来获得：

  1. $ go test -bench=BenchmarkGCLargeGs -run=^$ -count=5 -v . | tee 4.txt
  2. $ benchstat 4.txt
  3. name                     time/op
  4. GCLargeGs/#g-100-12       192µs ± 5%
  5. GCLargeGs/#g-1000-12      331µs ± 1%
  6. GCLargeGs/#g-10000-12    1.22ms ± 1%
  7. GCLargeGs/#g-100000-12   10.9ms ± 3%
  8. GCLargeGs/#g-1000000-12  32.5ms ± 4%

这种情况通常发生于峰值流量后，大量 goroutine 由于任务等待被休眠，从而运行时不断创建新的 goroutine，旧的 goroutine 由于休眠未被销毁且得不到复用，导致 GC 需要扫描的执行栈越来越多，进而完成 GC 所需的时间越来越长。一个解决办法是使用 goroutine 池来限制创建的 goroutine 数量。

总结

GC 是一个复杂的系统工程，本文讨论的二十个问题尽管已经展现了一个相对全面的 Go GC。但它们仍然只是 GC 这一宏观问题的一小部分较为重要的内容，还有非常多的细枝末节、研究进展无法在有限的篇幅内完整讨论。

从 Go 诞生之初，Go 团队就一直在对 GC 的表现进行实验与优化，但仍然有诸多未解决的公开问题，我们不妨对 GC 未来的改进拭目以待。

进一步阅读的主要参考文献

其他参考文献