Java 竞态条件（Race Condition）

竞态条件Race Condition竞态问题多个线程同时访问共享可变资源最终结果依赖于线程调度、CPU 执行时序不同的执行顺序会得到不一样、不符合预期的结果。一句话核心正确结果要求一组操作不可分但多线程把这组操作打散交错执行了。⚠️ 竞态 ≠ 一定出错是概率性 bug复现极其不稳定是最难排查的一类线程安全问题。一、两个必备前提缺一不会产生竞态共享资源多个线程访问同一个变量 / 对象资源可变存在写操作只读不会竞态竞态本质分为两块竞态条件Race Condition逻辑时序问题操作交错内存可见性问题CPU 缓存、JVM 指令重排属于配套的线程安全问题经常和竞态一起出现二、经典例子count最常见竞态 Democount不是一条 CPU 指令它是三步复合操作1. 读取 count 当前值load 2. 值 1add 3. 写回 countstore这三步不具备原子性线程可以在任意一步被切换。代码示例public class RaceDemo { private static int count 0; public static void add() { count; } public static void main(String[] args) throws InterruptedException { Runnable task () - { for (int i 0; i 10000; i) { add(); } }; Thread t1 new Thread(task); Thread t2 new Thread(task); t1.start(); t2.start(); t1.join(); t2.join(); // 预期20000实际大概率小于20000 System.out.println(count); } }错误时序拆解重点初始 count 0 t1: load → 读到 0 【CPU切换t1暂停】 t2: load → 读到 0 t2: add → 1 t2: store → count1 【切回t1】 t1: add → 1 t1: store → count1两个线程都做了 1结果只 1丢失更新Lost Update这就是典型竞态。✅ 重点不是变量本身有问题是 **“读 - 改 - 写” 这一组操作没有原子保护**。三、竞态条件的分类3 大类1. 读 - 改 - 写 竞态上面 countLost Update最常见一组load → modify → save 只要中间被打断就丢更新。 类似i i - 1、自增自减、累加、扣余额。2. 先检查后执行Check-Then-Act检查然后执行先判断状态再基于判断结果做操作判断和操作之间线程被切换。经典场景懒加载单例DCL 不加 volatile 就踩这个坑、余额判断扣款、判空然后 new 对象。示例伪代码if (instance null) { // check instance new Singleton(); // act }时序t1 判断 instancenull线程切到 t2t2 也判断 instancenullt2 new 对象赋值切回 t1t1 继续 new创建两个实例 check 和 act 不是原子的中间窗口就是竞态窗口。3. 复合校验更新Read-Modify-Check先读计算再校验最后写入。业务里非常多库存扣减超卖、转账。// 伪代码超卖场景 if (stock 0) { stock stock - 1; }t1 读到 stock1还没扣减t2 也读到 stock1两个都扣减 → stock-1超卖。 电商超卖就是典型竞态问题。四、容易混淆的概念竞态条件 vs 数据竞争Data Race很多人把两者混在一起JMM 规范里是分开定义数据竞争 Data Race两个线程无同步地访问同一个共享变量至少一个是写。 数据竞争是语法层面现象。竞态条件 Race Condition因为执行时序交错导致业务逻辑结果错误。关系数据竞争 是竞态条件的常见诱因但有数据竞争不一定结果错有竞态也不一定来自数据竞争。 比如某些时序交错刚好每次结果都对属于 “隐藏竞态偶然不出错”。五、JMM 带来的叠加问题指令重排、可见性竞态除了线程切换交错还会被 JMM 放大可见性线程把变量读到 CPU 高速缓存修改后没及时刷入主存别的线程看不到最新值volatile解决可见性、禁止重排但不能保证原子性volatile int count解决不了 count 竞态指令重排序JIT、CPU 为了性能打乱代码执行顺序DCL 单例就是因为对象 new 分为分配内存、初始化、引用赋值三步重排会出现引用不为 null 但对象还没初始化完成。重要坑volatile 能防重排和可见性不能解决 RMW 读改写的原子竞态。六、Java 里解决竞态的方案按分类方案 1synchronized 同步锁互斥锁最通用保证临界区代码原子执行同一时间只有一个线程进入临界区。private static int count 0; // 锁住方法临界区count public synchronized static void add() { count; }原理monitor 锁进入加锁、退出解锁临界区内操作不会被其他线程干扰。 优点简单缺点排他阻塞竞争激烈时性能差。方案 2Lock 显式锁ReentrantLock和 synchronized 语义一致功能更强可中断、公平锁、尝试锁、多条件变量。private static final ReentrantLock lock new ReentrantLock(); private static int count 0; public static void add() { lock.lock(); try { count; } finally { lock.unlock(); } }方案 3CAS 无锁乐观锁Atomic 系列适合读多写少场景java.util.concurrent.atomicAtomicInteger、AtomicLong底层 CPU 硬件指令cmpxchg硬件层面原子的读改写没有阻塞。private static AtomicInteger count new AtomicInteger(0); public static void add() { count.incrementAndGet(); // 原子自增不会竞态 }CAS 缺点自旋消耗 CPU、ABA 问题、不能一次性保护多个变量。方案 4线程封闭避开共享根治竞态不共享可变变量自然不存在竞态局部变量栈封闭每个线程栈独立ThreadLocal每个线程独有副本不共享方案 5不可变对象Immutable共享对象一旦创建永远不改只有读没有写天然线程安全String、BigInteger、自己写的 final 字段类。没有写操作直接消除竞态前提。方案 6并发容器 / 原子复合引用多变量需要一起原子更新AtomicReference、AtomicStampedReference或者使用ConcurrentHashMap等并发集合注意并发容器只能保证单个方法线程安全多个方法组合操作依然会竞态// ❌ 即使是ConcurrentHashMap下面这两行组合依然竞态 if (map.containsKey(key)) { map.put(key, val); }containsKey和put两个独立原子操作中间有空隙属于 Check-Then-Act 竞态这个是高频面试坑。七、竞态的特征排错识别要点偶现 bug压力大、CPU 忙才容易复现本地跑一万次没问题生产偶尔翻车日志很难定位日志打印本身有同步加日志之后竞态可能消失Heisenbug 海森堡 bug问题和并发调度强相关和业务代码语法无关修复思路找到【共享可变变量】找到【非原子复合操作】加同步 / 原子封装八、面试高频总结口诀竞态共享可变 非原子操作时序交错结果不定count load-modify-store三步无原子典型 Lost UpdateCheck-Then-Act先判断后执行中间空隙是竞态窗口volatile 解决可见、重排不解决 RMW 原子竞态ConcurrentHashMap 单个方法安全多方法组合依然竞态解决手段synchronized、Lock、AtomicCAS、线程封闭、不可变九、拓展怎么定位线上竞态问题看现象数值不对、超卖、重复创建、状态错乱压力越高概率越高审查代码找共享成员变量检查有没有 “读→计算→写”、“if 判断然后修改”工具Jcstress专门测试竞态并发正确性OpenJDK 官方工具、junit 并发压测、JProfiler 看锁竞争