竞态：原子性、可见性、有序性

病一：原子性 —— counter++ 不是一步

这是最有名的一个。counter++ 看起来是一条语句，编译成机器码是三条指令：

counter++    编译成:

    LOAD   r1 ← [counter]     ; 从内存(或缓存)读到寄存器
    ADD    r1 ← r1 + 1        ; 在寄存器里加一
    STORE  [counter] ← r1     ; 写回内存

; 三条指令之间,可以被抢占、可以被另一个核插队。

如果两个线程的 LOAD 挨在一起，它们会读到同一个旧值，然后各自加一、各自写回 —— 两次自增，只生效了一次。

下面这个 demo 是真的在做这件事：它把两个线程的 LOAD/ADD/STORE 指令流随机交错执行，然后统计结果。先点几次「换一次随机交错」，看看单次的 trace；然后按「跑 1000 次」看分布。

药：让那三条指令变成不可分割的一步

@Volatile var counter = 0     // ❌ 这样写，counter++ 照样会丢更新!

counter++    // 还是三步:LOAD / ADD / STORE
             // volatile 只保证「每次 LOAD 都读到最新值、每次 STORE 都立刻可见」
             // 它不保证这三步之间不被打断。

病二：可见性 —— 那个永远退不出的循环

class Worker {
    private var running = true        // ❌ 没有 volatile

    fun run() {
        while (running) {             // 工作线程
            doWork()
        }
        println("停止了")              // ← 可能永远执行不到
    }

    fun stop() {
        running = false               // 主线程,想让它停下来
    }
}

主线程调了 stop()，但工作线程可能永远看不到，永远循环下去。

为什么？回忆第 6 章的两个谎言：

• 缓存：工作线程把 running 缓存在它那个核的 L1 里，一直读缓存。主线程的写在另一个核的写缓冲区/缓存里。
• 编译器优化：更狠。编译器看到循环体里没人改 running，直接把它提到循环外面（这叫「循环不变量外提」）：

  tmp = running        ; 只读一次!
  while (tmp) {        ; 然后永远读寄存器
      doWork()
  }
  ; 这在单线程语义下是完全合法的优化。

注意：加锁也能解决可见性（进入/退出锁都有屏障），但对一个布尔标志来说，锁太重了 —— volatile / atomic 是为这种场景准备的。

病三：有序性 —— 那个错了十年的双检锁

这是最精妙、也最能说明问题的一个例子。单例模式的「双重检查锁定」（DCL）：

class Singleton {
    companion object {
        private var instance: Singleton? = null    // ❌ 没有 volatile

        fun get(): Singleton {
            if (instance == null) {                // 第一次检查(无锁,快)
                synchronized(this) {
                    if (instance == null) {        // 第二次检查(有锁,安全)
                        instance = Singleton()     // ← 就是这一行,埋了十年
                    }
                }
            }
            return instance!!
        }
    }
}

这段代码看起来无懈可击：加了锁、检查了两次、性能也好（大部分调用不用进锁）。它在 Java 世界里被抄了十年。

它是错的。

凶手：instance = Singleton() 不是一步

instance = Singleton()   实际上是三步:

  ① 分配内存
  ② 调用构造函数，初始化对象
  ③ 把 instance 指向那块内存

; JVM 和 CPU 都可以合法地把 ② 和 ③ 重排成:

  ① 分配内存
  ③ 把 instance 指向那块内存    ← 此时 instance != null,但对象还没构造完!
  ② 调用构造函数

; 因为在单线程视角下,②③ 换序毫无区别。

于是这个交错就要命了：

药：一个关键字

private @Volatile var instance: Singleton? = null   // ✅ volatile 禁止了 ②③ 重排

但更好的药是：根本别写 DCL。

// ✅ Kotlin 的正解 —— 一行,而且线程安全由语言保证
object Singleton { ... }              // object 声明,JVM 类加载器保证线程安全

// ✅ 或者延迟初始化
val instance by lazy { Singleton() }  // 默认就是 LazyThreadSafetyMode.SYNCHRONIZED

// ✅ Java 的正解:静态内部类(利用类加载的线程安全保证)
private static class Holder {
    static final Singleton INSTANCE = new Singleton();
}
public static Singleton get() { return Holder.INSTANCE; }

两个容易混的词：data race vs race condition

这两个词常被混用，但它们不是一回事，而且区分它们有实际价值：

// 这段代码完全没有 data race —— 每次访问都加了锁。
// 但它有 race condition —— 而且是个经典的账户超额扣款漏洞。

func Withdraw(acc *Account, amount int) bool {
    mu.Lock()
    balance := acc.Balance      // 读:安全
    mu.Unlock()

    if balance < amount {       // ← 检查
        return false
    }

    mu.Lock()
    acc.Balance -= amount       // ← 执行(和上面的检查之间,别人插进来了!)
    mu.Unlock()
    return true
}
// 两个线程同时读到 balance = 100,都通过了检查,
// 然后各扣 100 → 余额变成 -100。

三病一表

下一章：既然要加锁 —— 锁本身是怎么工作的？为什么没竞争的锁几乎免费？以及，两把锁怎么就变成了一场永久的僵局。