2. Race Condition 原理：数据竞争定义、临界区、原子性破坏、内存可见性问题

竞态条件（Race Condition）是并发编程中最隐蔽、最危险的敌人。当多个 goroutine 并发访问同一内存位置，且至少有一个是写操作时，若执行顺序不可控，程序的行为就会依赖于调度器的“运气”。本章从四个核心维度拆解竞态条件的本质：数据竞争的定义、临界区的识别、原子性破坏的后果，以及内存可见性问题。

2.1 数据竞争的定义

在 Go 内存模型中，数据竞争（Data Race）是指两个或多个 goroutine 同时访问同一个内存位置，且至少有一个访问是写操作，并且这些访问没有通过同步机制（如互斥锁、通道、原子操作）进行协调。

// 典型数据竞争示例
var counter int

func main() {
    go func() {
        for i := 0; i < 1000; i++ {
            counter++ // 写操作
        }
    }()
    go func() {
        for i := 0; i < 1000; i++ {
            counter++ // 写操作
        }
    }()
    time.Sleep(time.Second)
    fmt.Println(counter) // 结果不确定，通常小于 2000
}

2.2 临界区

临界区（Critical Section）是访问共享资源的代码片段，同一时刻只允许一个 goroutine 进入。临界区的识别是并发安全设计的第一步。

• 进入条件： 只有获得锁或通过通道获取许可的 goroutine 才能进入。
• 退出条件： 操作完成后必须释放锁或归还许可，否则其他 goroutine 会永久阻塞。
• 粒度控制： 临界区应尽量小，只包裹必要的共享访问代码，避免不必要的性能损失。

var (
    counter int
    mu      sync.Mutex
)

func increment() {
    mu.Lock()         // 进入临界区
    counter++         // 共享资源访问
    mu.Unlock()       // 退出临界区
}

2.3 原子性破坏

原子性（Atomicity）是指一个操作要么全部执行且不可中断，要么完全不执行。在并发环境下，看似简单的 counter++ 实际上包含三个步骤：读取、加一、写回。当多个 goroutine 交错执行这些步骤时，原子性被破坏，导致结果错误。

// 原子性破坏演示
var balance int = 100

// goroutine 1: 存款 50
balance = balance + 50  // 读取 100 → 计算 150 → 写回 150

// goroutine 2: 取款 30
balance = balance - 30  // 读取 100 → 计算 70 → 写回 70

// 最终结果可能是 70 或 150，而不是正确的 120

2.4 内存可见性问题

内存可见性（Memory Visibility）是指一个 goroutine 对共享变量的修改，能否被其他 goroutine 及时看到。由于 CPU 缓存、编译器优化、指令重排等因素，一个 goroutine 的写入可能暂时停留在本地缓存中，其他 goroutine 读取到的仍然是旧值。

• CPU 缓存： 每个核心有自己的 L1/L2 缓存，写操作可能延迟刷新到主存。
• 编译器优化： 编译器可能将变量暂存在寄存器中，不写回内存。
• 指令重排： CPU 和编译器可能改变指令执行顺序，导致其他 goroutine 看到不一致的状态。

2.5 四种竞态场景对比