slice / map 在 Go GC 与内存碎片上的真实成本

在 Go 服务的性能问题中，GC 压力与内存碎片 往往比 CPU 更早成为瓶颈。而在绝大多数业务系统里，真正制造这些问题的，并不是"复杂对象"，而是被大量、无意识使用的 slice 与 map。

它们语义简单，却是 内存行为最复杂的两类内建集合。

本文从 runtime 实现、GC 扫描路径、碎片来源与工程对策 四个层面，拆解它们的真实成本。

一、先给结论（工程级结论）

slice 的成本主要在"生命周期与扩容"
map 的成本主要在"桶结构与指针密度"

换句话说：

slice 容易制造 短命对象 + 大对象
map 容易制造 长寿命对象 + 高扫描成本

二、Go GC 关心的到底是什么？

Go 的 GC 是 非分代、三色标记-清扫（目前仍是非分代，尽管内部有逃逸/栈分配优化）。

GC 关心的核心只有三点：

对象数量
对象大小
对象中是否包含指针

slice / map 三点全中。

三、slice 的真实成本

1. slice 本身很小，但它"拖着一块内存"

复制代码

type slice struct {
    ptr *T   // 指针
    len int
    cap int
}

slice header 只有 24 字节（64 位）
真正昂贵的是它指向的 底层数组

2. 扩容 = 新分配 + 拷贝 + 老对象等待 GC

复制代码

s := []int{}
for i := 0; i < 1_000_000; i++ {
    s = append(s, i)
}

发生了什么？

多次底层数组重新分配
每次扩容都产生：
- 一个 新数组
- 一个 即将变成垃圾的旧数组
旧数组等待 GC 扫描与回收

扩容不是"覆盖"，而是"制造垃圾"。

3. cap 泄漏：最隐蔽的内存杀手

复制代码

buf := make([]byte, 0, 1<<20) // 1MB
small := buf[:10]
return small

问题：

small 只用 10 字节
但 1MB 的底层数组被整个保活

GC 视角：

这是一个 存活的大对象
会进入老生代（逻辑意义上）
每次 GC 都要扫描

👉 这是生产事故级问题。

4. slice + 指针元素 = GC 扫描放大

[]*Object

GC 需要扫描 slice 中 每一个元素
指针越多，标记成本越高
比 []struct{} 成本高一个量级

5. slice 的碎片来源

不同大小的底层数组频繁分配
大 slice 生命周期不一致
导致 heap span 难以复用

四、map 的真实成本（更重）

1. map 不是一个对象，而是一组结构

一个 map 至少包含：

map header
多个 bucket
overflow bucket
key/value 存储区

map 是"对象簇"，不是对象。

2. bucket 结构导致的指针密度

每个 bucket 有：
- key
- value
- 指向 overflow bucket 的指针

即使你只存 1 个元素，也可能存在多个 bucket。

GC 成本来自：

大量小对象
大量指针
不可预测的内存布局

3. map 扩容 = 渐进式搬迁（但 GC 不会放过）

扩容时：
- 老 bucket + 新 bucket 同时存在
- GC 需要扫描 两套结构
map 越大，扩容窗口越长

4. map 的"长寿命 + 持续增长"问题

典型场景：

复制代码

var cache = map[string]*Object{}

服务启动后不断写入
几乎不 delete
map 被提升为 高存活对象
每次 GC 都完整扫描

这是很多 Go 服务 RSS 越跑越高 的根因之一。

5. delete ≠ 释放内存

复制代码

delete(m, k)

只清空逻辑槽位
bucket 仍然存在
内存不会立刻归还

想释放：

复制代码

m = make(map[K]V)

五、slice vs map：GC 成本对比

维度	slice	map
扩容成本	高	很高
指针密度	可控	天生高
碎片风险	中	高
delete 效果	可回收	基本不可
GC 扫描	连续	离散

六、工程级对策（重点）

1. 所有 slice 必须"容量有意识"

make([]T, 0, n)

这是 性能设计的一部分，不是优化细节。

2. 严禁 cap 泄漏

返回前 copy
缩容：

s = append([]T(nil), s...)

3. map 用完即丢，不要长期复用

请求级 map：用完置 nil
缓存型 map：有上限、有淘汰

4. 少用 map[string]interface{}

这是 GC 噩梦组合。

5. 优先用 slice + 排序 + 二分（在小规模下）

少指针
连续内存
GC 友好

6. 高并发缓存：sync.Map 不是银弹

减少锁
不会减少 GC 扫描
依然是大量指针

七、你在监控中会看到的信号

GC 时间占比升高
HeapAlloc 波动剧烈
RSS 不随流量下降
GC 周期缩短但回收效果变差

这些，几乎都和 slice / map 的使用模式有关。

八、一句话总结

slice 是"制造垃圾的高手"，
map 是"保活垃圾的高手"。

理解它们的 GC 成本，本质上是在理解：

对象生命周期
内存布局
指针密度

而这三点，正是 Go 高性能系统的分水岭。