前几天我在学习内存屏障的时候搜到一篇文章「Golang Memory Model」，其中在介绍 CPU 缓存一致性的时候提到一个例子，带给我一些困惑，本文记录下解惑过程。
既然是在介绍 CPU 缓存一致性的时候举的例子，那么理所应当与此有关，看代码：
代码语言：javascript复制package main
import "time"
func main() {
running := true
go func() {
println("start thread1")
count := 1
for running {
count
}
println("end thread1: count =", count)
}()
go func() {
println("start thread2")
for {
running = false
}
}()
time.Sleep(time.Hour)
}当我们通过「go run main.go」运行代码的时候，会发现第一个 goroutine 永远不会结束，就好像 running = false 没有生效一样。对此，文章把原因归结为 CPU 缓存一致性中的线程可见性问题，可是我前后看了几遍也没有看出个所以然来。细心的小伙伴不难发现代码存在 data race 问题：多个 goroutine 并发读写 running 变量，不过当我们通过「go run -race main.go」再次运行代码的时候，有趣的事情发生了，第一个 goroutine 正常结束了！
理论上，既然存在 data race 问题，那么出现什么结果都可能，但是好奇心驱使我继续研究了一下，这次使用的工具是 SSA（how to read），它可以展现出从源代码到汇编的过程中，编译器都做了哪些工作，并且可以把结果生成 html 文件：
代码语言：javascript复制shell> GOSSAFUNC=main go build -gcflags="-N -l" ./main.goSSA 工具最方便的地方是它可以把源代码和汇编通过颜色对应起来：
main 函数的 ssa
说明：Golang 中的汇编一般指 Plan9 汇编，推荐阅读「plan9 assembly 完全解析」。
不过为什么「running = false」这行源代码没有对应的汇编呢？这是因为 SSA 的工作单位是函数，上面的结果是 main 函数的结果，而「running = false」实际上属于 main 函数里第 2 个 goroutine，相当于 main.func2，重新运行 SSA：
代码语言：javascript复制shell> GOSSAFUNC=main.func2 go build -gcflags="-N -l" ./main.go如此一来就能看到「running = false」这行源代码对应的汇编了：
main.func2 函数的 ssa
其中，PCDATA 是编译器插入的和 GC 相关的信息，在本例中可以忽略，剩下的几个 JMP 跳来跳去，好像是个圈哦，就是一个空 for，和「running = false」完全没有关系。
不过既然带有 race 检测的代码工作正常，那么不妨一并生成 SSA 看看结果如何：
代码语言：javascript复制shell> GOSSAFUNC=main.func2 go build -race -gcflags="-N -l" ./main.go结果如下图所示，除了 JMP，还有 MOV 操作，正好对应「running = false」：
main.func2 函数的 ssa
如此一来，我们的困惑终于解开了。问题代码中的循环之所以不会结束，和所谓的「CPU 缓存一致性中的线程可见性问题」并没有任何关系，只是因为编译器把部分代码看成死代码，直接优化掉了，这个过程称之为「Dead code elimination」，不过当激活 race 检测的时候，编译器并没有执行优化死代码的流程，所以看上去又正常了。
最后，推荐一篇文章，和本文的例子相似：谈谈 Golang 中的 Data Race（及续）。
