如何通过内存对齐 Padding 提升 Go 结构体在 CPU 缓存行中的访问性能

在现代多核 CPU 架构中，内存访问的最小单位并非单个字节，而是被称为缓存行（Cache Line）的数据块，通常为 64 字节。当多个线程（或 Goroutine）并发修改位于同一个缓存行内的不同变量时，会触发 CPU 的缓存一致性协议，导致频繁的缓存失效。这种现象被称为伪共享（False Sharing）。

本文将展示如何通过在 Go 结构体中手动添加 Padding（填充）来强制将变量分配到不同的缓存行，从而大幅提升性能。

1. 问题的根源：伪共享

假设我们有一个简单的计数器结构体：

type Counter struct {
    A uint64
    B uint64
}

在 64 位系统上，uint64 占用 8 字节。由于 A 和 B 是连续存储的，它们极大概率位于同一个 64 字节的缓存行中。如果核心 1 更新 A，核心 2 更新 B，尽管它们在逻辑上互不干扰，但 CPU 必须在两个核心之间同步该缓存行的状态，导致严重的性能抖动。

2. 解决方案：手动 Padding

我们可以通过在变量之间填充足够的无用空间，确保它们落在不同的缓存行中。

type PaddedCounter struct {
    A uint64
    _ [56]byte // 填充 56 字节，使得 A 和 B 之间跨越一个 64 字节的缓存行
    B uint64
}

3. 性能对比基准测试

我们可以编写一个简单的基准测试（Benchmark）来观察差异。

package main

import (
\t\"sync/atomic\"
\t\"testing\"
)

type Counter struct {
\tA uint64
\tB uint64
}

type PaddedCounter struct {
\tA uint64
\t_ [56]byte
\tB uint64
}

func BenchmarkFalseSharing(b *testing.B) {
\tc := Counter{}
\tb.RunParallel(func(pb *testing.PB) {
\t\tfor pb.Next() {
\t\t\tatomic.AddUint64(&c.A, 1)
\t\t\tatomic.AddUint64(&c.B, 1)
\t\t}
\t})
}

func BenchmarkPadding(b *testing.B) {
\tc := PaddedCounter{}
\tb.RunParallel(func(pb *testing.PB) {
\t\tfor pb.Next() {
\t\t\tatomic.AddUint64(&c.A, 1)
\t\t\tatomic.AddUint64(&c.B, 1)
\t\t}
\t})
}

4. 运行结果

执行 go test -bench=.，你会发现 BenchmarkPadding 的速度通常比 BenchmarkFalseSharing 快 2 到 5 倍。这是因为 Padding 消除了多核之间的缓存竞争。

5. 总结

虽然 Padding 会增加内存的占用，但在高性能并发编程（如原子操作计数器、高性能队列）中，它是解决伪共享、榨干 CPU 性能的必备技巧。在设计核心组件时，务必考虑结构体字段在内存中的布局。