前言
在解释伪共享（false sharing）之前，有必要简要介绍一下 CPU 架构中缓存是如何工作的。CPU 缓存中的最小单位是缓存行（cache line）（如今，CPU 中常见的缓存行大小为 64 字节）。因此，当 CPU 从内存读取一个变量时，它会同时读取该变量附近的所有变量。图 1 是一个简单的例子：
当 core1 从内存读取变量 a 时，它会同时将变量 b 读入缓存。（顺便说一句，我认为 CPU 从内存批量读取变量的主要原因是基于空间局部性理论：当 CPU 访问一个变量时，它可能很快就会读取旁边的变量。）
这种缓存架构存在一个问题：如果一个变量像图 2 那样存在于不同 CPU 核心的两个缓存行中：
当 core1 更新变量 a 时：
即使变量 b 没有被修改，它也会导致 core2 的缓存失效，因此 core2 将重新加载缓存行中的所有变量，如图 4 所示：
这就是所谓的伪共享：一个核心更新一个变量会迫使其他核心也更新缓存。我们都知道，CPU 从缓存读取变量比从内存读取要快得多。因此，当这个变量总是存在于多核中时，这将显著影响性能。解决这个问题的常见方法是缓存填充（cache padding）：在变量之间填充一些无意义的变量。这将迫使一个变量单独占用一个核心的缓存行，所以当其他核心更新缓存变量时，不会使该核心从内存中重新加载变量。
让我们使用下面的 Go 代码片段简要介绍这个伪共享的概念。
这里是一个包含 3 个 uint64 的 Go 结构体，
type NoPad struct {
a uint64
b uint64
c uint64
}
func (myatomic *NoPad) IncreaseAllEles() {
atomic.AddUint64(&myatomic.a, 1)
atomic.AddUint64(&myatomic.b, 1)
atomic.AddUint64(&myatomic.c, 1)
}
还有另一个我在变量之间添加了 [8]uint64 以进行填充的结构体：
type Pad struct {
a uint64
_p1 [8]uint64
b uint64
_p2 [8]uint64
c uint64
_p3 [8]uint64
}
func (myatomic *Pad) IncreaseAllEles() {
atomic.AddUint64(&myatomic.a, 1)
atomic.AddUint64(&myatomic.b, 1)
atomic.AddUint64(&myatomic.c, 1)
}
然后我编写了一个简单的代码来运行基准测试：
func testAtomicIncrease(myatomic MyAtomic) {
paraNum := 1000
addTimes := 1000
var wg sync.WaitGroup
wg.Add(paraNum)
for i := 0; i < paraNum; i++ {
go func() {
for j := 0; j < addTimes; j++ {
myatomic.IncreaseAllEles()
}
wg.Done()
}()
}
wg.Wait()
}
func BenchmarkNoPad(b *testing.B) {
myatomic := &NoPad{}
b.ResetTimer()
testAtomicIncrease(myatomic)
}
func BenchmarkPad(b *testing.B) {
myatomic := &Pad{}
b.ResetTimer()
testAtomicIncrease(myatomic)
}
在 2014 年的 MBA 上运行的基准测试如下：
$> go test -bench=.
BenchmarkNoPad-4 2000000000 0.07 ns/op
BenchmarkPad-4 2000000000 0.02 ns/op
PASS
ok 1.777s
基准测试的结果显示，性能从 0.07 ns/op 提高到了 0.02 ns/op，这是一个很大的改进。你也可以在其他语言（如 Java）中测试这一点，我相信你会得到相同的结果。在你将其应用到生产环境之前，你应该了解两个关键点：
1.确保了解你系统中 CPU 的缓存行大小：这与你使用的缓存填充大小有关。
2.填充更多变量意味着你将消耗更多的内存资源。运行基准测试并确保你的投入是值得的。
P.S.
之所以选择翻译此文，是因为我正在写关于 Go 结构体内存对齐的文章，需要介绍「伪共享」这个概念，受限于篇幅所限，就决定针对伪共享这个概念单独写一篇文章。我在查阅资料过程中发现此文讲解浅显易懂，于是想着把此文翻译下共读者查阅。不过虽然这篇文章思路清晰易懂，但作者提供的基准测试代码并不够严谨，我在 2022 款 M2 芯片的 MBA 上测试得到如下结果：
$ go test -bench=. -v
goos: darwin
goarch: arm64
pkg: false-sharing
BenchmarkNoPad
BenchmarkNoPad-8 1000000000 0.09618 ns/op
BenchmarkPad
BenchmarkPad-8 1000000000 0.1065 ns/op
PASS
ok false-sharing 2.368s
跟作者的结果完全相反，哈哈。我们可以写一个简单的基准测试来验证使用 cache padding 来解决 false sharing 的效果：
package main
import (
"sync/atomic"
"testing"
)
func BenchmarkPadding(b *testing.B) {
b.Run("without_padding", func(b *testing.B) {
nums := [128]atomic.Int64{}
i := atomic.Int64{}
b.RunParallel(func(pb *testing.PB) {
id := i.Add(1)
for pb.Next() {
nums[id].Add(1)
}
})
})
b.Run("with_padding", func(b *testing.B) {
type pad struct {
val atomic.Int64
_ [8]uint64
}
nums := [128]pad{}
i := atomic.Int64{}
b.RunParallel(func(pb *testing.PB) {
id := i.Add(1)
for pb.Next() {
nums[id].val.Add(1)
}
})
})
}
在 without_padding 场景中，由于 nums 数组的元素可能共享相同的缓存行，多个 goroutine 同时修改相邻元素时会导致缓存行失效，从而降低性能。而在 with_padding 场景中，通过在高频访问的变量之间加入缓存填充 _ [8]uint64，使得每个元素都占据独立的缓存行，减少了这种缓存行的失效情况，预期能观察到性能的提升。
执行基准测试代码，输出如下：
$ go test -bench=. -v
goos: darwin
goarch: arm64
pkg: false-sharing
BenchmarkPadding
BenchmarkPadding/without_padding
BenchmarkPadding/without_padding-8 55441728 22.09 ns/op
BenchmarkPadding/with_padding
BenchmarkPadding/with_padding-8 1000000000 1.075 ns/op
PASS
ok false-sharing 4.255s
基准测试的结果显示，性能从 22.09 ns/op 提高到了 1.075 ns/op。
这段代码由原文评论区提供，你可以自行尝试验证。