小对象分配总从 mcache 开始，因其是每个 p 私有缓存，无锁快速分配；size ≤ 32kb 时优先查 mcache（含 67 种 size class 各 1–2 个 span）；class 不匹配仍可复用同 span；mcentral 按 class 独立加锁；≥32kb 对象直走 mheap；span 级碎片导致 rss 居高不下。
小对象分配为什么总从 mcache 开始
因为它是每个 P（goroutine 调度器）私有的缓存，拿内存不用加锁、不争抢，最快。只要你要的 size ≤ 32KB，运行时就先查你本地的 mcache——它按 67 种大小规格（spanClass）各存了一小批空闲块。
常见错误现象：pprof 显示大量 runtime.mallocgc 调用集中在某几个 goroutine 上，但 CPU 却不高 → 很可能是某个 P 的 mcache 频繁耗尽，被迫频繁向 mcentral 申请新 span，触发锁竞争。
- 实操建议：用
go tool trace查看 “Goroutine Analysis” 页，观察是否有 P 长时间卡在runtime.(*mcache).refill - size class 不匹配会绕过
mcache：比如你 new 一个 17B 的 struct，实际落入 24B class；但如果后续又 new 一个 19B 的，它还是进 24B class —— 只要 size class 一致，就能复用同一批 span - 别指望
mcache永远够用：它只缓存少量 span（通常每 class 1–2 个），一旦并发分配激增，立刻穿透到mcentral
mcentral 的锁到底锁什么
它不锁整个中心缓存，只锁“同一 size class”的 span 链表。也就是说，67 种 size class 各自有一把互斥锁，彼此完全独立。这是 Go 减少锁竞争的关键设计。
使用场景：高频创建固定大小对象（如 HTTP 请求中的 []byte{1024}、统一结构体池）时，所有 goroutine 都会集中请求同一个 class 的 span，这时该 class 的 mcentral 锁就成了瓶颈。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 参数差异：
mcentral分为small和large两类，但 large class 实际只用于 ≥ 32KB 对象，日常几乎不走这里 - 性能影响：当某 class 的
mcentral锁等待时间明显上升（可通过runtime.ReadMemStats中PauseTotalNs结合 pprof 火焰图交叉验证），说明该 size 的分配太热 - 容易踩的坑：以为加了
sync.Pool就万事大吉——但如果 Pool 里对象大小不统一（比如混了 32B 和 48B 的 struct），Get/put 还是会触发不同 class 的mcentral锁
为什么 ≥32KB 的对象直接跳过 mcache 和 mcentral
因为大对象分配频次低、单次成本高，再套两层缓存收益小，反而增加路径复杂度和管理开销。Go 直接让 mheap 从操作系统申请整数页（8KB/page），按需拼成所需大小。
常见错误现象：runtime.MemStats.HeapAlloc 增长不快，但 HeapSys 持续飙升 → 很可能有大量生命周期长的大对象（如大 buffer、大 map）长期占着 page，而这些 page 无法被拆散复用给小对象。
- 实操建议：用
go tool pprof -http=:6060 <binary><heap-profile></heap-profile></binary>，执行top -cum，重点看调用栈中是否出现runtime.largeAlloc或make([]byte, N)（N ≥ 32768） - 兼容性注意：大对象分配失败时不会 panic，而是返回 nil（如
make([]byte, 1 在 64 位系统上可能静默失败） - 别误判“大”：32KB 是硬分界，不是约数——32767B 走小对象路径，32768B 就走大对象路径
内存碎片卡住 RSS 的真实原因
不是因为你 malloc 太多，而是因为 span 无法整体归还：一个 span 里哪怕只剩 1 个活跃对象，整个 span（可能是 1~128 个连续 page）就一直被钉在 mheap 里，既不能拆开给小对象用，也不能还给操作系统。
使用场景：微服务中高频创建短生命周期小结构体（如日志字段、RPC 元信息），且 size 分布分散（16B/24B/40B/48B 各占一摊）→ 各自占满一批 span，但回收时间错开，导致大量 span 半空不空。
- 判断依据：检查
runtime.MemStats中HeapSys - HeapIdle - HeapReleased差值，持续 > 100MB 就大概率是 span 级碎片 - 实操手段：统一 struct 字段对齐（如补
_ [x]byte），把原本落在 4B/8B/16B/24B 的对象尽量收拢到 8B 或 16B class；避免用make([]byte, n)动态长度，改用预定义常量池 - 最容易被忽略的一点：
sync.PoolPut 进去的对象，如果被其他 goroutine 持有引用（哪怕只是临时传参没逃逸），它就不再属于 Pool 管理范围，照样触发新分配 → Pool 不是银弹，得盯住逃逸分析输出
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
