什么不变量确保 Go 的线程本地分配器可以在不获取全局锁的情况下处理小对象请求？

对问题的回答

历史

Go 的内存分配器源自 TCMalloc，这是谷歌为 C++ 多线程服务器设计的线程缓存 malloc。运行时实现了多级缓存，专门用于消除并发程序中的锁内容竞争。这一设计优先考虑 throughput 而非小对象快速通道中的内存效率。

问题

在高度并发的服务中，要求每次分配都获取一个全局堆锁会使 goroutines 串行化并破坏 throughput。挑战在于提供 O(1) 的分配延迟，而无需在常见情况下进行同步，同时维持安全性。传统的 malloc 实现存在缓存行 bouncing，当多个 CPU 竞争同一个锁字时。

解决方案

运行时维护一个每个 P 的缓存 (mcache)，其中包含 67 个大小类别的跨度。当 goroutine 分配一个小对象 (≤32KB) 时，它要么递增一个边界指针，要么从其 mcache 中的线程本地空闲列表中弹出，这不需要原子操作。关键的不变量是任何时刻一个 mcache 仅由一个 P 独占，且分配永远不会跨越 P 边界，从而避免了共享的可变状态。

type PriceTick struct {
    Symbol uint32
    Price  float64
}

func ProcessTick() {
    // 从 mcache 分配 16 字节而不加锁
    tick := &PriceTick{}
    _ = tick
}

生活中的情况

一个高频交易平台每秒处理 500,000 个市场数据事件，每个事件需要临时的 24 字节结构体用于价格归一化。最初的实现利用一个全局的 sync.Pool 来存储这些对象，但在负载下成为了一个严重的争用点，消耗了 35% 的 CPU 时间用于原子操作和缓存一致性流量。

解决方案 A：手动池分片

团队考虑手动将池分成 256 个内部子池，通过 goroutine ID 哈希选择。优点：在缓存行之间分散争用。缺点：不均匀的利用造成空闲分片的内存膨胀，且当本地分片空了而其他分片还有空闲对象时，需要复杂的饥饿处理。

解决方案 B：每个工作者的区域

他们评估了为每个工作者 goroutine 预先分配大型内存区域并使用增量指针分配。优点：零争用和极快的分配路径。缺点：需要手动内存管理，如果重置指针的处理不当，会有内存泄漏的风险，并会使异步边界的对象生命周期跟踪变得复杂。

解决方案 C：栈分配和批处理

选择的方法重构事件处理器，尽可能使用值结构而不是指针，并将事件批量处理 1000 个以摊平分配的成本。优点：完全消除了短期数据对堆的压力，并且不需要同步原语。缺点：要求显著重构之前期望指针语义的接口，并增加了每个 goroutine 的栈使用量。

结果

通过实施解决方案 C，该服务消除了热路径中 99% 的堆分配。P99 延迟从 12 毫秒降至 180 微秒，垃圾回收周期减少了 85%，使服务能够满足其亚毫秒的 SLA 要求。

候选人常常忽视的问题

在从固定大小的跨度分配不同大小的对象时，Go 如何限制内存碎片？

Go 采用 67 个不同的大小类别，具有特定的粒度（8 字节步长，最多到 512 字节，然后是更大的间隔）。对象被向上舍入到最近的类别大小，从而将内部碎片限制在大约 12.5%。外部碎片被最小化，因为每个 mspan 包含的对象正好属于一个大小类别，从而防止小对象锁定大型内存块。

为什么运行时在分配期间清除堆位图而不是用户可见的内存？

分配器在 heapArena 元数据结构中维护类型信息和指针位图，而不是在对象头中。当内存被分配时，仅在必要时将指针插槽指示的位图清零；数据内存在被突变者请求或在并发清扫期间按需清零。这种方法推迟了工作，提高了缓存局部性，并减少了分配过程中所需的内存带宽。

什么强迫跨度在垃圾回收期间从 mcache 过渡回 mcentral？

在 GC 清扫阶段，运行时检查 mcache 实例中持有的跨度。如果一个跨度不包含已分配对象（所有插槽都已释放），则 P 将其返回给 mcentral 而不是保留它。这防止了内存囤积，确保在处理器之间平衡分配空闲内存，但这会产生重新获取中心锁的成本。