go内存分配基于span和mcache三级缓存，小对象分配几乎无系统调用；gc采用三色标记+混合写屏障，stw仅初始标记和标记终止两个极短阶段；常见问题源于对象过多或生命周期过长，优化应优先复用、池化和控制生命周期。
Go 内存分配基于 span 和 mcache，不是传统 malloc
Go 运行时把堆内存划分为大小不一的 span（页块），每个 span 管理固定尺寸的对象。分配小对象时，P（Processor）会从本地 mcache 中快速获取；mcache 没有可用 span 时，才向 mcentral 申请；mcentral 不足则向 mheap 申请新页。这种三级缓存结构大幅减少锁竞争，也意味着小对象分配几乎无系统调用开销。
注意：栈上分配由编译器静态决定（逃逸分析），只要变量不逃逸，就根本不会进堆——这是最有效的“内存优化”。可通过 go build -gcflags="-m -l" 查看逃逸情况，比如闭包捕获局部变量、返回局部变量指针、切片扩容超出栈容量等都会导致逃逸。
GC 使用三色标记 + 混合写屏障，STW 仅在两个极短阶段
Go 1.22+ 的 GC 是并发、增量式、基于三色标记法的垃圾回收器。它把对象分为白（未扫描）、灰（待扫描）、黑（已扫描且其引用全为黑）三类。关键在于写屏障：当程序修改指针时，运行时插入一条指令，把被写入的对象标灰，并确保所有可达对象最终不会被误回收。
目前 STW（Stop-The-World）只发生在：
• 初始标记（mark start）：暂停所有 Goroutine，做根对象快照（如全局变量、栈上指针），耗时通常 • 标记终止（mark termination）：重新扫描可能因写屏障遗漏的少量灰对象，再做一次微小 STW，一般 其余阶段（标记、清扫、重置）全部与用户代码并发执行。
立即学习“go语言免费学习笔记（深入）”；
常见内存问题不是“GC 太慢”，而是“对象太多”或“生命周期太长”
GC 延迟低 ≠ 内存占用低。高频创建短命对象（如循环中 new struct、字符串拼接、JSON 解析生成大量 map[string]interface{}）会导致：
- 分配速率高 → mcache 频繁向 mcentral 申请 → 增加锁争用和 CPU 开销
- 年轻代对象来不及被下一轮 GC 回收就堆积 → 堆增长 → GC 触发更频繁（即使每次很快）
- 大对象（>32KB）直接走 mheap 分配，不进 mcache，且清扫后归还 OS 较慢（默认延迟 5 分钟），容易造成 RSS 持续偏高
典型例子：一个 HTTP handler 每次都 json.Unmarshal 到 map[string]interface{}，实际会生成数十个嵌套 map、string、slice header 对象；换成预定义 struct + json.Decoder 复用缓冲区，可降低 60%+ 堆分配量。
实用优化手段：复用、池化、控制生命周期
不用盲目调 GC 参数（如 GOGC），优先从代码层减少压力：
- sync.Pool 适合临时对象复用：如 []byte 缓冲、JSON 解析中间结构体、HTTP 头部 map。注意 Pool 中对象无序、无保证存活，不能存放含 finalizer 或跨 goroutine 共享状态的对象
- 对频繁切片操作，用 make([]T, 0, N) 预分配容量，避免多次扩容拷贝；append 后若不再增长，可考虑 shrink（通过切片截断再 copy 到新 slice）释放多余底层数组
- 大对象（如 1MB 以上 buffer）尽量复用或用 mmap 显式管理；必要时调 debug.FreeOSMemory() 强制归还（慎用，会引发 STW）
- 用 pprof heap profile 定位高分配点：go tool pprof http://localhost:6060/debug/pprof/heap，重点关注 alloc_objects 和 inuse_objects 差值大的地方
