Go语言Mutex实现中读取m.state未用原子操作是否存在竞态条件？
你困惑的这个问题其实涉及到Go竞态检测器的特殊规则，以及sync.Mutex底层实现的设计逻辑，咱们分开说清楚：
为什么不同包的竞态检测结果不一样？
Go的竞态检测器对标准库中的sync这类核心同步原语包有豁免机制。因为sync包是Go并发模型的基础，里面的代码都是Go团队精心编写、严格验证过的底层实现——这些代码大量使用手动内存可见性控制和原子操作，本身就是用来解决并发问题的，如果竞态检测器对它们报警，反而会产生大量无意义的误报。
所以当你把测试代码放到sync包内部时，竞态检测器会自动跳过对这段代码的检测；而像os/exec这类非同步原语的标准库包，没有这个豁免规则，所以你的测试代码放在里面时，检测器会正常识别出竞态问题。
sync.Mutex中直接读取m.state是否存在竞态？
答案是不存在实际的安全风险，这个直接读取是设计好的安全操作，原因有两个：
乐观读取+原子验证的逻辑
你看到的old := m.state是一个“乐观读取”操作，后续代码并不会直接基于这个old值做修改，而是会通过原子操作（比如后续的atomic.CompareAndSwapInt32）来验证这个状态是否有效。如果读取到的old是过期的，原子操作会失败，代码会进入循环重新读取最新的m.state值，不会基于错误状态做出错误决策。原子操作的内存可见性保证
m.state的所有修改都是通过原子操作完成的（比如你看到的atomic.CompareAndSwapInt32，还有其他地方的atomic.AddInt32等）。根据Go的内存模型，原子操作会建立happens-before关系：任何对m.state的原子修改，都会对后续读取该值的goroutine可见。即使某次直接读取到了旧值，后续的循环也会通过原子操作获取到最新状态，不会出现永久的不一致。
这种“先快速读，再原子验证”的方式是标准库中常见的性能优化——既避免了每次都走原子读的开销，又通过后续的原子操作保证了并发安全。
内容的提问来源于stack exchange，提问作者jack
