允许脏读的Go代码是否线程安全？含字符串/数值类型疑问

一、rate.Limiter指针的情况 #

即使允许脏读，这段代码依然不是线程安全的，核心原因有两点：

• rate.Limiter的Allow()方法会修改自身结构体的内部状态（比如令牌桶计数），多个goroutine同时调用同一个Limiter实例的Allow()，本质是对实例内部状态的并发读写，这种操作本身就会引发数据竞争，导致令牌计数逻辑混乱、结果不可预期，和是否允许脏读无关。
• 当有goroutine更新TestLimiter指针时，其他goroutine可能在指针切换的瞬间同时操作旧实例和新实例，加上每个实例内部的并发操作，会让整个逻辑的一致性彻底失控。go run -race检测出的7个竞争，就包含了指针读写竞争和实例内部状态的竞争，这些都不是“脏读”能掩盖的风险。

二、换成string或数值类型的情况 #

要分两种场景判断：

• 单纯的读写操作：如果只是直接对string或数值类型（int、float等）做赋值和读取，允许脏读的前提下是安全的。Go语言对这类原生类型的单个读写操作是原子性的（只要类型符合机器字长，比如64位系统上的int64），不会出现读到半更新的损坏值，只是可能读到旧数据，这符合“允许脏读”的前提。
• 复合操作：如果是像i++这种先读、再修改、最后写入的复合操作，哪怕是数值类型，也绝对不是线程安全的。这类操作拆分为多个步骤，并发执行时会导致数据竞争，最终得到错误的结果。

内容的提问来源于stack exchange，提问作者Marlin