深入理解 Go GC：为什么 100 万个小对象比 1 个大对象更令编译器头疼？

原创

go
go

Go语言教程

2026年6月14日 13:01
陕西

在小说阅读器读本章

去阅读

Go GC 最烦的不是大，是碎

线上看 gctrace，最别扭的不是 heap 一下涨到几百 MB。

真正让我警觉的是这种日志味道：

GODEBUG=gctrace=1 ./price-job

然后你发现堆不算特别大，GC 却来得很勤，CPU 也被偷了一截。业务代码看着还挺朴素：查一批价格，组一批对象，算完扔掉。

这种场景我第一眼一般不怀疑算法，先看对象数量。

Go 里面，100 万个小对象，很多时候比 1 个大对象更麻烦。

注意，这里“麻烦”的主要不是编译器，而是运行时 GC。编译器确实会做逃逸分析，判断变量能不能放栈上；但对象一旦逃到堆上，后面真正擦屁股的是 GC。

看一段很常见的写法：

package main

import (
 \"fmt\"
 \"runtime\"
)

type PriceNode struct {
 SKU   string
 Cents int64
 Next  *PriceNode
}

var hold any

func buildSmallObjects(n int) {
 head := &PriceNode{SKU: \"sku-root\", Cents: 1}

 for i := 0; i < n; i++ {
  node := &PriceNode{
   SKU:   fmt.Sprintf(\"sku-%06d\", i),
   Cents: int64(i % 997),
   Next:  head,
  }
  head = node
 }

 hold = head
}

func main() {
 buildSmallObjects(1_000_000)
 runtime.GC()
 runtime.KeepAlive(hold)
}

这代码有什么问题？

不是 for，不是 fmt.Sprintf，这些当然也能优化，但先别急着修边角料。

真正扎眼的是：这里制造了 100 万个 PriceNode，每个节点还有指针字段 Next，SKU 里面也带指针。GC 扫描的时候，不是看你“总共用了多少 MB”这么粗暴，它还得沿着对象图去标记。

一个对象，要有分配记录，要落在 span 里，要维护标记位。带指针的对象，还要被扫描。100 万个对象，就是 100 万个小现场。

GC 不怕搬砖，怕你把砖打成粉末。

再看另一种写法：

type PriceRow struct {
 SKUId uint32
 Cents int64
}

var rows []PriceRow

func buildOneBigChunk(n int) {
 buf := make([]PriceRow, 0, n)

 for i := 0; i < n; i++ {
  buf = append(buf, PriceRow{
   SKUId: uint32(i),
   Cents: int64(i % 997),
  })
 }

 rows = buf
}

这段就舒服很多。

它不是没有内存。100 万条数据也要占空间。但它是一个连续的大数组，里面没有指针字段。对 GC 来说，这种对象很像一块“别扫我”的内存。

Go 的 GC 扫描最关心指针。[]PriceRow 这个切片头有指针，但底层数组里的 PriceRow 不含指针，运行时知道这块内存是 noscan 的，标记阶段不用一个字段一个字段进去翻。

这就是差别。

一个大对象，如果里面全是数字、定长字段、枚举值，GC 压力未必大。

100 万个小对象，只要它们在堆上，尤其还互相挂指针，那就麻烦了。GC 要处理的不是“一份数据”，而是一张对象网。

逃逸这里也得看一眼。

有些人写 Go，喜欢所有东西都 new 一下，觉得清楚：

func makeBillLine(sku string, cents int64) *PriceNode {
 return &PriceNode{
  SKU:   sku,
  Cents: cents,
 }
}

这个函数返回指针，基本就别指望它老老实实待在栈上了。调用层再把这些指针塞进 slice：

func collectLines(items []string) []*PriceNode {
 out := make([]*PriceNode, 0, len(items))

 for i, sku := range items {
  out = append(out, makeBillLine(sku, int64(i*3)))
 }

 return out
}

这类代码一多，GC 压力不是慢慢上来的，是业务量一放大就冒头。

我一般会先跑这个命令：

go build -gcflags='-m=2' ./cmd/price-job

看到类似这种输出，就要停一下：

./price.go:18:9: &PriceNode{...} escapes to heap
./price.go:27:19: make([]*PriceNode, 0, len(items)) escapes to heap

不是说逃逸一定错。返回结果、跨 goroutine、放全局缓存，本来就可能逃逸。

但你要知道代价。

如果这批数据只是中间计算，用完就扔，那用指针切片就不太值。很多时候可以改成值切片：

type BillLine struct {
 SKUId  uint32
 Count  int32
 Cents  int64
 Status uint8
}

func collectBillLines(ids []uint32) []BillLine {
 lines := make([]BillLine, 0, len(ids))

 for i, id := range ids {
  lines = append(lines, BillLine{
   SKUId:  id,
   Count: 1,
   Cents: int64((i + 17) % 1000),
   Status: 1,
  })
 }

 return lines
}

这段代码少了很多堆对象。

[]BillLine 自己是一个对象，底层数组也是一块连续内存。里面都是普通值，不带指针。GC 看它一眼，大概就过去了。

这里还有个坑：不是所有“大对象”都省 GC。

比如你搞一个大数组，里面全是指针：

type UserRef struct {
 ID   int64
 Name *string
}

var userRefs []UserRef

这个就不能当成普通大块内存看。因为里面有指针，GC 还是要扫描。只是对象数量少了一点，但扫描字段的活还在。

所以优化时别只盯着对象大小，要看两个东西：

对象数量。

指针密度。

指针密度这个词有点硬，换成现场话就是：这块内存里，到处是不是都埋着地址。

缓存场景最容易踩这个坑。

我见过有人为了省查询，把几十万用户状态塞进 map：

var userState = map[int64]*State{}

然后 State 里面又有几个 slice、几个 string、几个 map。看起来只是一个缓存，实际上给 GC 造了一个菜市场。每次标记都要进去逛一圈。

如果状态比较固定，完全可以压平一点：

type StateLite struct {
 Level  uint16
 Score  int32
 Flags  uint32
 Expire int64
}

var stateTable map[int64]StateLite

这不是为了写得“低级”，是为了让 GC 少看。

Go 的 GC 已经很努力了，并发标记、写屏障、辅助标记，该做的都做了。但 GC 再聪明，也架不住你每个请求都撒一地小对象。

排查这类问题，我通常按这个顺序来：

先开 gctrace 看 GC 频率和暂停。

再用 pprof 看 alloc_objects，不要只看 alloc_space。

然后用 go build -gcflags='-m=2' 抓逃逸。

最后才改代码结构。

命令大概这样：

go test -run=NONE -bench=. -benchmem ./internal/price

go tool pprof -http=:8080 ./price-job heap.out

alloc_space 大，说明你分配了很多字节。

alloc_objects 大，说明你造了很多对象。

后者经常更脏。

1 个 100MB 的 []byte，只要不带指针，GC 多半懒得仔细看它。

100 万个 100 字节的小对象，加起来也就 100MB，但每个对象都要登记、标记、扫描、回收。中间再夹几个指针，GC 就没法闭眼跳过。

所以 Go 里写高吞吐代码，不是见到 new 就怕，也不是见到大 slice 就怕。

真正要防的是这种写法：一层业务对象套一层 DTO，一层 DTO 再套指针字段，最后请求一多，堆上全是零碎对象。代码看着挺面向对象，GC 看着想骂人。

能用值就别随手上指针。

能用连续数组就别散成链表。

能把字符串、map、slice 从热路径挪出去，就别让它们跟着每个小对象一起逃逸。

Go GC 不怕你用内存，它怕你把内存切得太碎，还到处插指针。