mspan是Go运行时管理堆上固定大小页块的中间结构，对应连续虚拟内存并存储元信息，而非直接分配内存或存放用户数据。
mspan 是什么，不是什么
它不是 Go 运行时里“分配内存”的最终执行者，而是管理 heap 上固定大小页块的中间结构。一个 mspan 对应一段连续的虚拟内存（通常是 8KB 的倍数），但它本身不存用户数据，只存元信息：起始地址、页数、对象大小等级（spanclass）、空闲链表指针、是否被清扫等。
容易误以为 mspan 和 malloc 直接对应——其实它更像“仓库货架”，真正放东西的是它管理的那些空闲插槽（mcache 或 mcentral 拿走后切分出的对象）。
怎么查当前程序里活跃的 mspan
Go 不提供公开 API 直接遍历 mspan，但可通过运行时调试接口间接观察：
- 启动程序时加
GODEBUG=gctrace=1，GC 日志里会打印 span 扫描数量，但不暴露细节 - 用
runtime.ReadMemStats可拿到总堆页数（HeapSys - HeapIdle），反推大致 span 数量级（每 span 至少 1 页） - 真要看到具体
mspan地址和状态，得用dlv调试器 attach 后执行：print runtime.mheap_.allspans
，再逐个 inspect 字段——注意：这是未导出字段，不同 Go 版本偏移可能变
别指望在生产环境靠代码枚举 mspan，这是运行时内部视图，稳定性和性能都不支持。
立即学习“go语言免费学习笔记（深入）”；
mspan 的 spanclass 怎么影响分配行为
spanclass 编码了两个关键信息：对象大小等级（0–67）和是否含指针。它决定这个 mspan 能不能被 mcache 拿去服务某类 make 或 new 分配。
比如：spanclass=48 表示该 span 管理 144 字节对象、且含指针；而 spanclass=49 是同样大小但不含指针——GC 会跳过扫描后者，节省时间。
- 小对象（≤32KB）走
spanclass查表分配，速度极快；大对象直接走mheap_.allocSpan按页申请，不进 spanclass 分类 - 同一个
spanclass下的所有mspan在mcentral里共用一条空闲链表，但每个 P 的mcache只缓存其中一部分 - 写代码时无法指定
spanclass，但可以通过调整结构体字段顺序（把指针集中放前面/后面）或用unsafe.NoEscape影响逃逸分析，间接改变分配路径
为什么你改不了 mspan 的 sizeclass 或回收策略
因为 mspan 的生命周期完全由运行时 GC 控制：分配时从 mcentral 拿，归还时要么进 mcache 局部缓存，要么回 mcentral，最终由 sweep 阶段决定是否返还给操作系统。
- 没有用户可控的 “释放 mspan” 接口，
runtime.GC()也不强制回收 span，只是触发清扫逻辑 - 即使某段内存长期不用，只要还在
mcentral空闲链表里，就仍算HeapInuse，不会归还 OS（除非整个 span 空且满足scavenger条件） - 想压低 RSS？重点不在 span 管理，而在减少小对象高频分配+及时让变量逃逸出作用域，避免 span 长期被
mcache持有
底层结构越稳定，上层越难干预——mspan 就是这么个“只读内核态组件”，看懂它有助于诊断卡顿或内存泄漏，但别想着绕过运行时去手动调度。
