费曼来信：为什么 8 个想省钱的工人，却挤坏了一个“保险箱抽屉”？——聊聊 Go 语言中的伪共享

读完步子哥关于 Go 语言伪共享（False Sharing） 的解析，我脑子里立刻跳出一个关于“办公资源争夺”的画面。 为了让你明白为什么改一个变量的位置能让性能暴涨 10 倍，咱们来聊聊 CPU 的“小聪明”。

1. 缓存行：那个“按打批发”的抽屉

CPU 为了快，从主内存里拿数据时不是一个字节一个字节拿的。它有个习惯：按块拿。 这块东西叫“缓存行（Cache Line）”，通常是 64 字节。 这就好比你去超市买鸡蛋，人家不散卖，一次必须买一打（一盒 12 个）。

• 规则：只要盒子里有一个蛋碎了（变量被修改），整个盒子就得扔掉（缓存失效），重新去超市买一盒新的。

2. 伪共享：那个“阴差阳错”的尴尬

在你的并行计算里，你有 8 个工人（Goroutine）在数钱。

• 慢的版本：你给 8 个工人每人发了一个钱包（LocalCount），但你为了省事，把这 8 个钱包塞进了同一个保险箱抽屉（同一个缓存行）里。
• 后果：工人 A 往钱包里存了 1 块钱（修改变量）。CPU 发现抽屉里的数据变了，立刻大喊一声：“抽屉脏了，大家都别用了！”于是，正在其他 7 个钱包里数钱的工人都得停下手里的活，等着那个抽屉从大仓库（内存）里重新搬过来。

大家明明在干独立的活，却在物理层面被迫“排队串行”。这就是所谓的“伪共享”。

3. 逃逸分析：那个“多管闲事”的管家

为什么声明在外部就会出事？ 因为 Go 的管家（编译器）发现你的钱包要给子孙（Goroutine）用，他觉得放在桌子上（栈）不安全，非要把它锁进地库（堆）。 由于地库里的钱包通常是挨着放的，这 8 个 int64（正好 64 字节）就刚好挤进了一个抽屉。

4. 费曼式的防御：制造“物理隔阂”

解决办法其实就是一句话：“离远点。”

• 方案 A（最优雅）：把钱包发给工人自己带着（变量声明在 Goroutine 内部）。这样钱包就留在了工人自己的办公桌上（栈），物理地址差了十万八千里，根本不可能进同一个抽屉。
• 方案 B（暴力）：如果你非要放在一起，那就给每个钱包周围塞满“填充物（Padding）”。比如在每个 int64 后面塞 56 个字节的废纸，强迫每个钱包独占一个抽屉。

费曼式的感悟： 所谓的“高性能”，并不是你写出了多么复杂的算法。 而是你理解了底层硬件的“强迫症”，并顺着它的脾气去排兵布阵。 伪共享告诉我们：逻辑上的独立不代表物理上的自由。 如果你想让你的程序飞起来，别只管逻辑对不对，去看看你的数据是不是在微观世界里“挤成了一团”。 #Golang #ParallelComputing #FalseSharing #CacheLine #EscapeAnalysis #FeynmanLearning #智柴性能实验室🎙️