Go内存分配器以TCMalloc分级缓存+无锁分配为骨架，分微/小/大对象三级分配，通过mcache→mcentral→mheap自上而下申请、反向归还，并由tiny分配器优化超小对象。
TCMalloc 思想是 Go 内存分配器的底层骨架
Go 并没有直接照搬 tcmalloc 的全部代码，但 runtime 中的内存管理模型高度借鉴了它的核心设计。关键在于“分级缓存 + 无锁分配”：把内存按大小分类、按线程隔离、按层级流转。这种结构大幅降低锁竞争，也减少系统调用频次。
Go 把对象按大小划分为三类：微对象（字节且无指针）走 tiny 分配器；小对象（16–32KB）从 mcache 的 mspan 中分配；大对象（>32KB）则直连 mheap，由页级管理器统一分配。这种划分不是凭空设定，而是为了平衡碎片率与分配速度。
mcache、mcentral、mheap 三级结构怎么协作
这是面试必问的链条，本质是一个“自上而下申请、自下而上归还”的缓存体系：
- mcache：每个 P（逻辑处理器）独享，无锁。它缓存了一批已划分好 slot 的 mspan（比如 8 字节、16 字节等规格），分配时直接取，O(1) 完成
- mcentral：所有 P 共享的中心池，按 span 类别组织（如“8 字节 slot 的 span 链表”）。当 mcache 某类 span 耗尽，就向 mcentral 申请新 span
- mheap：全局堆，管理操作系统页（page，8KB）。当 mcentral 缺 span，就向 mheap 申请新 page，并切分成对应 size 的 span
回收路径相反：对象被 GC 回收后，其所在 span 若全空，会逐级归还——先回 mcache，再归 mcentral，最后若整页都空，才交还给 mheap，甚至可能归还 OS（需满足内存闲置阈值）。
立即学习“go语言免费学习笔记（深入）”；
为什么 tiny 分配器不参与常规回收
tiny 分配器专用于
所以 tiny 块只在所属 goroutine 栈完全销毁且无逃逸引用时才整体回收。它换来了极低的分配开销和零碎片，代价是延迟回收、无法精确释放单个 tiny 对象。
面试常追问的几个点
考官常顺着原理往下挖细节，以下问题高频出现：
- “mcache 为什么能无锁？” → 因为绑定到唯一 P，无并发写入；跨 P 分配不走它，走 mcentral
- “span 是什么？最小多大？” → span 是 mheap 切分出的内存单元，至少 1 个 page（8KB），内部划分为固定大小 slot
- “对象何时分配到栈？何时到堆？” → 编译期逃逸分析决定。局部变量若被返回、取地址、闭包捕获、或大小动态未知，就会逃逸到堆
- “GC 如何配合内存分配？” → GC 使用三色标记 + 混合写屏障，确保分配器在并发分配时不漏标；回收后的 span 不立即清零，而是放入 free list 复用
- “如何检测内存泄漏？” → pprof heap profile 是首选：
go tool pprof http://localhost:6060/debug/pprof/heap，重点关注 inuse_objects 和 inuse_space 随时间增长趋势
