Go高并发内存碎片是runtime分配器对≤32KB小对象按固定size class划分span且不合并重排的必然结果；频繁分配不同大小小对象会导致span卡住、HeapSys上涨而HeapReleased≈0。
Go 高并发下内存碎片不是“写法错”，而是 runtime 分配器对小对象（≤32KB）按固定 size class 划分 span、不合并也不重排的必然结果。只要频繁分配不同大小的小对象（比如 []byte{17}、struct{a int; b string}），就大概率卡住 span，导致 runtime.MemStats.Sys 持续上涨但 HeapReleased 几乎为 0。
怎么看是不是内存碎片在作怪
别靠猜，直接看运行时指标和 pprof 数据：
-
GODEBUG=gctrace=1启动程序，观察 GC 日志里是否有大量scvg: inuse: X -> Y, released: 0—— 这说明 mheap 无法把空闲 span 归还 OS -
go tool pprof http://localhost:6060/debug/pprof/heap，输入top -cum，重点看runtime.mallocgc下游是否密集调用make、new或 struct 字面量，且参数尺寸分散（如 16B、23B、41B） - 检查
runtime.ReadMemStats：若HeapSys - HeapIdle - HeapReleased > 100MB并持续不降，基本可断定是 span 级碎片卡住了内存页
sync.Pool 复用对象时最常踩的三个坑
sync.Pool 是缓解碎片最直接的手段，但用错反而加重问题：
- Get 后没调
Reset()或清零字段 → 下次拿到的是脏数据，业务逻辑出错，还可能因引用残留导致对象逃逸失效 - Put 的对象被其他 goroutine 持有（比如塞进 channel、存进 map、或作为返回值传出）→ Pool 放弃管理，照样触发新分配
- New 函数返回的是指针但没做初始化（如
return &MyStruct{}而非return new(MyStruct)）→ Pool 可能复用未清零的内存，引发隐性 bug
统一 size class 是降低碎片的关键操作
Go 小对象分配器将内存按固定尺寸切分成多个 size class（如 8B、16B、32B…），不同 size 的对象落在不同 span 中。只要生命周期不一致，整个 span 就无法释放。
例如这个结构体：struct{a uint8; b uint16} 占 3B，会被分到 4B class；但加一个填充字段：struct{a uint8; b uint16; _ [5]byte} 就稳定落在 8B class —— 这样所有同类对象都走同一 span，释放时更容易整块归还。
类似地，避免动态长度的 []byte：预分配固定容量（如 make([]byte, 0, 1024)），或用 bytes.Buffer + Grow() 控制底层数组复用，比反复 make([]byte, N) 安全得多。
快照/批量恢复场景下的碎片陷阱
像时序数据库这类系统，从磁盘加载快照时若 chunk 内存分配顺序混乱（比如按时间戳乱序读取），会导致小对象跨 span 散布。即使逻辑上这批 chunk 生命周期一致，也会因分配位置分散而无法整体释放。
解决方式不是排序写入（会严重拖慢写性能），而是改用预分配大块内存 + 偏移寻址：一次性 make([]byte, totalSize)，再把每个 chunk 按需切片（buf[off:off+chunkLen]）。这样所有 chunk 共享同一底层数组，GC 时只要最后一个 chunk 释放，整块内存就能回收。
注意：这种做法要求 chunk 生命周期严格对齐，且不能让任意一个切片逃逸到全局作用域。
