runtime.mallocgc 对32kb对象仍走小对象路径，因size &^ (pagesize-1) == 0仅影响大对象对齐；真正大对象（>32kb）直调mheap.alloc，不参与size class管理、gc扫描更重、释放延迟更高。
runtime.mallocgc 为什么对
Go 的 runtime.mallocgc 不会为每个 byte 或 struct{a int8} 单独分配一个 object。微小对象（Tiny 对象，即大小在 1–16 字节、且不含指针）会被**批量打包进同一个 16 字节 object 中**，复用剩余空间。
这是为了对抗内存碎片和分配开销——如果每个 1 字节对象都走完整分配路径，mcache → mcentral → mheap，光是维护 100 万个 tiny object 的 allocBits 和 span 状态就足以拖慢分配器。
常见错误现象：
- 你定义了
type Flag struct{ v bool }，期望它只占 1 字节，但实际被塞进 16 字节块里，且无法被 GC 单独回收 - 用
unsafe.Sizeof(Flag{})看到是 1，但runtime.ReadMemStats显示堆增长远超预期——因为 tiny 分配不按对象计数，而按 object 块计费
关键判断点：
- 必须同时满足：大小 ≤16 字节 且 不含任何指针字段（包括 interface、slice、map、func、chan、*T）
- 一旦结构体加了一个
*int字段，哪怕总大小还是 16 字节，tiny 分配立即失效，退化为常规小对象分配 - tiny 分配只发生在堆上；栈上逃逸分析仍起作用，但 tiny 打包逻辑仅由
mallocgc在堆分配时触发
32KB 是大对象的硬分界线，但不是唯一标准
runtime.mallocgc 判断大对象的首要条件确实是 size > 32KB（即 32768 字节），但真正决定是否走大对象路径的，是 size &^ (pageSize - 1) == 0 后的对齐行为与后续处理逻辑。
大对象不经过 mcache 或 mcentral，而是直接调用 mheap.alloc 向操作系统申请整页（8KB）对齐的内存，并标记为 spanClass = 0（表示“未分类大块”）。这意味着：
- 不会被切分成 object，不参与 size class 桶管理
- GC 标记阶段跳过扫描其内部（除非它含指针，此时需额外构造 pointer bitmap）
- 释放时不归还给 mcache/mcentral，而是直接
unmap内存页，延迟更高（受 OS page reclaim 影响）
容易踩的坑：
- 误以为
make([]byte, 32769)就一定比make([]byte, 32768)更“重”——其实前者多出 1 字节，导致跨越 page 边界，触发额外的 mmap 调用，反而更慢 - 用
unsafe.Slice手动拼接多个小 slice 成一个大 buffer，结果意外凑够 32KB+，触发大对象路径，破坏局部性
小对象（8B–32KB）的 size class 查表逻辑实际很“粗糙”
runtime.mallocgc 对小对象不做精确匹配，而是查一张 67 行的静态表（sizeclasses.go），把请求 size 映射到最近的、更大的固定档位。比如：
- 请求 25 字节 → 落入 32 字节 size class（class 3）
- 请求 1025 字节 → 落入 1152 字节 size class（class 15）
- 请求 32760 字节 → 仍属小对象，落入 32768 字节 size class（class 67）
这个过程在编译期固化，运行时只是查表 + 位运算，所以极快。但副作用明显：
- 内存浪费：25 字节对象实际占 32 字节，浪费 22%；1025 字节对象浪费约 12%
- 跨 size class 的 cache line 混用：不同业务对象若被分到同一 class，会共享同一
mcache链表，加剧 false sharing - 无法绕过：即使你用
sync.Pool预分配，池中对象仍按原始 size class 分配，不能“压缩”进更小 class
逃逸分析失败时，mallocgc 才真正接手——别指望编译器兜底
runtime.mallocgc 只在对象**确定逃逸到堆**后才被调用。它不参与逃逸判定，也不优化分配策略——它只执行分配动作。
也就是说，如果你写 u := &User{...}，而 User 因字段含指针或作用域外引用被判定为逃逸，那么 mallocgc 就按该对象实际大小（含 padding、对齐）走对应路径；它不会因为你“本意是临时用一下”就降级为栈分配，也不会自动聚合多个小对象。
最常被忽略的一点：
-
mallocgc的耗时主要不在系统调用，而在维护 span 的allocBits、更新mcache空闲链表、检查是否需要触发 GC —— 这些开销对 100 万个对象是线性叠加的，不是常数 - 微小对象的 tiny 打包和大对象的直通 mmap 都是为了缓解这个线性压力，但它们互斥，且不可组合：你无法让一个含指针的 12 字节对象既享受 tiny 打包，又避免堆分配
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
