深入解析 Go 的秘密数据结构：CacheLinePad 的精细化优化

本文链接：https://blog.youkuaiyun.com/jsjbrdzhh/article/details/143868656

在现代多核处理器中，高效的缓存机制可以极大地提升程序性能，但也可能因为“伪共享”（False Sharing）问题导致性能下降。本文将深入探讨如何在 Go 语言中利用 CacheLinePad 数据结构，通过精细化优化来避免伪共享问题，提高程序性能。

1. 背景

在现代多核处理器中，CPU 缓存通常分为三级：L1、L2 和 L3，每一级缓存的大小、速度和共享方式都不同：

L1 缓存：速度最快，每个 CPU 核心独享，容量较小（通常 32KB - 64KB），分为指令缓存（L1I）和数据缓存（L1D）。
L2 缓存：比 L1 缓存稍大（通常 256KB - 1MB），每个 CPU 核心独享，速度稍慢。
L3 缓存：容量最大（通常 8MB - 64MB），所有 CPU 核心共享，速度比 L1、L2 缓存慢，但仍显著快于主存。

CPU 缓存以缓存行（Cache Line）为单位进行数据传输和存储。缓存行的大小通常是固定的，在 x86 架构中常见为 64 字节，而在 Apple M 系列等一些 ARM 架构处理器上可能达到 128 字节。

当 CPU 访问内存数据时，会以缓存行为单位将数据加载到缓存中。缓存行是缓存操作的基本单位，每次数据传输都是以缓存行为最小粒度的。

1.1 伪共享（False Sharing）

伪共享是指多个线程访问同一缓存行中不同变量时，导致频繁的缓存行失效，从而大大降低程序性能的问题。

示例：

type Data struct {
    x int64 // 线程 A 更新的变量
    y int64 // 线程 B 更新的变量
}

如果变量 x 和 y 位于同一缓存行中，那么当线程 A 更新 x 时，线程 B 中缓存的 y 也会因为缓存一致性协议而失效，即使线程 B 实际上并未使用 x 的值。这种情况下，两个变量并没有直接共享，但每次写操作都会导致另一方的缓存失效，形成了伪共享。

1.2 如何避免伪共享？

为了解决伪共享问题，可以采取以下方法：

变量填充（Padding）：在变量之间添加填充，使每个变量占据独立的缓存行。
```
type Data struct {
    x int64
    _ [7]int64 // 填充，使 x 和 y 位于不同的缓存行
    y int64
}
```
假设缓存行为 64 字节，int64 类型占 8 字节，填充 7 个 int64（共 56 字节），这样 x 和 y 就位于不同的缓存行中。
将变量分散到不同的结构体中：将经常被不同线程更新的变量放入不同的结构体，避免同一结构体被多个线程同时访问。
使用原子操作：在需要保证变量更新的原子性时，使用 sync/atomic 包提供的原子操作，尽可能减少缓存一致性协议的开销。
绑定 CPU 核心（CPU Affinity）：将线程绑定到指定的 CPU 核心上，减少多个线程同时访问同一缓存行的可能性。

1.3 单线程的缓存行优化

即使在单线程程序中，也有必要进行缓存行优化：

避免缓存行污染：如果频繁访问的变量分布在不同的缓存行上，会导致缓存频繁更替，增加缓存开销。应将频繁使用的数据集中在同一缓存行内，减少 CPU 从主存加载数据的频率。
数据布局优化：调整数据的内存布局，将经常一起访问的数据放在连续的内存中，提高缓存命中率。

示例：

下面是一个关于结构体内存对齐和缓存命中率的基准测试，比较了读取已对齐和未对齐结构体的性能。

未对齐的结构体：

type NonAlignedStruct struct {
    a byte   // 1 字节，需要填充 7 字节（内存对齐）
    b int64  // 8 字节
    c byte   // 1 字节，需要填充 7 字节（内存对齐）
}

已对齐的结构体：

type AlignedStruct struct {
    b int64     // 8 字节
    a byte      // 1 字节
    c byte      // 1 字节
    _ [6]byte   // 填充，使结构体大小为 16 字节
}

通过调整结构体字段的顺序和填充，使得结构体在内存中更加紧凑，提高缓存命中率。实际的基准测试显示，读取已对齐结构体的性能明显优于未对齐的结构体。

2. Go 运行时中的 CacheLinePad

2.1 运行时中的 CacheLinePad

Go 语言支持多种 CPU 架构，不同架构的缓存行大小可能不同。Go 运行时为了统一处理，针对不同的 CPU 架构定义了对应的缓存行大小。

首先，定义了统一的结构和变量：

// CacheLinePad 用于填充结构体，避免伪共享
type CacheLinePad struct{ _ [CacheLinePadSize]byte }

// CacheLineSize 是 CPU 的缓存行大小，不同的 CPU 架构可能不同
var CacheLineSize uintptr = CacheLinePadSize

然后，针对不同的 CPU 架构定义不同的 CacheLinePadSize：

ARM64 架构：
```
const CacheLinePadSize = 128
```
x86 和 AMD64 架构：
```
const CacheLinePadSize = 64
```

Go 运行时根据不同的 CPU 架构，定义了合适的缓存行大小，以此来避免伪共享问题。

2.2 `golang.org/x/sys/cpu` 包

Go 标准库中的 internal/cpu 包定义了 CacheLinePad，但属于内部包，不对外暴露。为了解决这个问题，Go 扩展库 golang.org/x/sys/cpu 提供了 CacheLinePad 的定义，开发者可以直接使用。

type CacheLinePad struct{ _ [CacheLineSize]byte }

这个结构体的实现与 Go 运行时中的 CacheLinePad 一致，只是将其公开，方便开发者在项目中使用。

2.3 Go 运行时中的应用场景

示例 1：semTable

在 Go 运行时中，semTable 用于管理信号量的等待队列。为了解决伪共享问题，semTable 的每个元素都使用了填充，使其大小对齐到缓存行大小。

type semaRoot struct {
    lock  mutex
    treap *sudog        // 平衡树的根节点
    nwait atomic.Uint32 // 等待者的数量，无需加锁读取
}

const semTabSize = 251

var semtable [semTabSize]struct {
    root semaRoot
    pad  [cpu.CacheLinePadSize - unsafe.Sizeof(semaRoot{})]byte // 填充
}

通过在 semaRoot 后添加填充，使每个 semtable 元素的大小与缓存行大小一致，避免不同线程操作时产生伪共享。

示例 2：mheap

在内存管理的 mheap 结构体中，也使用了 CacheLinePad 来避免伪共享。

type mheap struct {
    lock mutex
    pages pageAlloc
    // ... 其他字段省略
    _ cpu.CacheLinePad // 防止与后续字段产生伪共享

    arenas [1 << arenaL1Bits]*[1 << arenaL2Bits]*heapArena
    // ... 其他字段省略
}

在关键字段后添加 CacheLinePad，确保后续的 arenas 数组与前面的字段处于不同的缓存行中，避免并发访问时的冲突。

示例 3：stackpool

在 runtime/stack.go 中，stackpool 结构体也使用了 CacheLinePad，并采用了动态计算填充大小的方法。

var stackpool [_NumStackOrders]struct {
    item stackpoolItem
    _    [(cpu.CacheLinePadSize - unsafe.Sizeof(stackpoolItem{})%cpu.CacheLinePadSize) % cpu.CacheLinePadSize]byte
}