1. 这不是“加个synchronized就能跑通”的问题一次生产环境线程安全事故的复盘起点去年冬天某电商大促压测期间一个看似简单的库存扣减服务突然在凌晨两点开始持续超时。接口平均响应从80ms飙升至2.3秒错误率突破15%。运维告警堆成山而开发团队最初排查方向全是“是不是数据库慢了”“是不是Redis连接池不够”。直到凌晨四点一位老同事把线程dump文件拖进VisualVM放大到某个业务线程栈帧时指着一行inventory.decrementAndGet()轻声说“等等——这个AtomicInteger我们真以为它万能吗”这句话成了整个复盘的起点。我们后来发现问题根本不在原子类本身而在于它被嵌套在一个非原子的复合操作里先用get()读取当前值判断是否足够再用decrementAndGet()执行扣减。两个原子操作之间存在时间窗口多个线程并发时完全可能同时读到“库存充足”然后一起扣减导致超卖。这恰恰暴露了一个被大量开发者忽略的事实线程安全不是靠堆砌“线程安全类”就能自动获得的而是对整个操作语义边界的精确控制。这正是本文要深挖的核心——Java线程安全从来不是一道选择题“用锁还是用CAS”而是一张需要你亲手绘制的作战地图。这张图上synchronized和ReentrantLock是重武器但开火前得确认目标坐标volatile是信号旗只管传递状态不管执行逻辑CAS是精准点射但得防备ABA陷阱和自旋开销而wait/notify、Condition、CountDownLatch这些线程通信机制则是不同部队间的协同指令系统。它们各自有明确的职责边界、适用场景和致命短板。本文不讲概念定义不列API文档而是以一个真实可复现的库存服务为锚点逐层拆解每种机制在真实代码中如何落地、为何这样设计、踩过哪些坑、以及当它们组合使用时边界在哪里、雷区在何处。如果你曾写过private static volatile boolean flag false;却不确定它到底保证了什么或者在ConcurrentHashMap里加了锁还遇到死锁那这篇复盘就是为你写的。2. 锁机制从synchronized到AQS不是“加锁”而是“定义临界区”2.1 synchronizedJVM层面的“自动挡”但档位切换逻辑藏在字节码里很多开发者把synchronized当作最省事的方案却很少有人真正看过它编译后的字节码。我们用一个极简的库存扣减方法来观察public class InventoryService { private int stock 100; public void deduct(int amount) { synchronized (this) { if (stock amount) { stock - amount; System.out.println(扣减成功剩余 stock); } else { System.out.println(库存不足); } } } }反编译后关键字节码如下简化0: aload_0 1: dup 2: astore_1 3: monitorenter // 进入同步块获取monitor锁 4: aload_0 5: getfield #2 // 获取stock字段值 8: iload_2 9: if_icmplt 27 // 判断stock amount 12: aload_0 13: aload_0 14: getfield #2 17: iload_2 18: isub 19: putfield #2 // 执行stock - amount 22: getstatic #3 // 输出日志 ... 27: aload_1 28: monitorexit // 退出同步块释放monitor锁 29: goto 37 32: astore_2 33: aload_1 34: monitorexit // 异常路径也要释放锁 35: aload_2 36: athrow 37: return关键点在于monitorenter和monitorexit指令。JVM规范规定每个对象实例都有一个与之关联的monitor监视器monitorenter会尝试获取该monitor的所有权。如果monitor未被占用当前线程立即成为owner如果已被其他线程占用当前线程将被阻塞进入该monitor的Entry Set等待队列。而monitorexit则负责释放所有权并唤醒Entry Set中的一个等待线程。提示synchronized的“自动释放”特性本质是JVM在字节码层面强制插入了monitorexit指令无论正常执行完还是抛出异常。这是它比手动Lock更安全的根本原因——你无法绕过这个保障。但synchronized的“自动挡”也有代价。它的锁升级过程偏向锁→轻量级锁→重量级锁虽然优化了无竞争场景但在高竞争下monitorenter的开销远高于Lock.lock()。更重要的是它无法实现可中断等待、超时获取或公平锁。当你的业务要求“用户下单等待库存锁不能超过3秒超时就放弃”synchronized就无能为力了。2.2 ReentrantLock手动挡的精密控制但油门和刹车全在你手上ReentrantLock的设计哲学是“把控制权交还给开发者”。它基于AQSAbstractQueuedSynchronizer框架构建核心是一个state整型变量和一个FIFO等待队列。我们来看一个支持超时的库存扣减实现public class InventoryServiceWithLock { private final ReentrantLock lock new ReentrantLock(true); // true表示公平锁 private int stock 100; public boolean deductWithTimeout(int amount, long timeoutMs) throws InterruptedException { // 尝试在timeoutMs内获取锁失败则返回false if (!lock.tryLock(timeoutMs, TimeUnit.MILLISECONDS)) { return false; // 获取锁超时直接放弃 } try { if (stock amount) { stock - amount; return true; } else { return false; } } finally { lock.unlock(); // 必须在finally中释放这是手动挡的铁律 } } }这里的关键差异在于可中断性lock.lockInterruptibly()允许线程在等待锁时响应interrupt()信号避免无限期挂起。超时获取tryLock(long, TimeUnit)让业务逻辑可以优雅降级而不是死等。公平性构造时传入true确保等待时间最长的线程优先获取锁避免饥饿。但手动挡的风险也在此忘记在finally中调用unlock()就会造成永久性死锁。我见过最典型的错误是在try块里写了return却把unlock()放在了return之后——这段代码永远执行不到。正确的模式永远是lock.lock(); try { // 业务逻辑 } finally { lock.unlock(); // 这行必须存在且不能被任何条件跳过 }2.3 AQS所有显式锁的“发动机总成”理解它才能不被API表象迷惑ReentrantLock、CountDownLatch、Semaphore甚至FutureTask底层都依赖AQS。它的核心思想极其精炼用一个volatile int state变量表示同步状态用一个CLHCraig, Landin, and Hagersten变种的FIFO队列管理等待线程。AQS定义了两种资源共享方式独占式Exclusive如ReentrantLock同一时刻只允许一个线程持有锁。关键方法是tryAcquire(int)和tryRelease(int)。共享式Shared如Semaphore、CountDownLatch允许多个线程同时访问。关键方法是tryAcquireShared(int)和tryReleaseShared(int)。我们以ReentrantLock的非公平锁tryAcquire为例简化// NonfairSync.tryAcquire() final boolean nonfairTryAcquire(int acquires) { final Thread current Thread.currentThread(); int c getState(); // 读取当前state值 if (c 0) { // 如果锁空闲 if (compareAndSetState(0, acquires)) { // CAS设置state为acquires setExclusiveOwnerThread(current); // 设置当前线程为owner return true; } } else if (current getExclusiveOwnerThread()) { // 如果是重入 int nextc c acquires; if (nextc 0) throw new Error(Maximum lock count exceeded); setState(nextc); // 直接更新state无需CAS return true; } return false; }这段代码揭示了AQS的精髓所有复杂的锁行为最终都归结为对state变量的原子读-改-写操作。compareAndSetState(0, acquires)就是一次CAS操作它保证了“检查锁空闲”和“设置锁被占用”这两个动作的原子性。而重入时直接setState(nextc)是因为此时已知当前线程就是owner无需再做并发检查。注意AQS的state变量是volatile修饰的这保证了getState()读取的总是最新值且setState()的写入对其他线程可见。但volatile不保证复合操作的原子性所以state这种操作必须用CAS。3. volatile内存可见性的“单向广播站”不是线程安全的万能胶3.1 为什么volatile不能替代synchronized一个经典反例很多初学者认为“既然volatile能保证可见性那我把它加在stock字段上不就不用锁了吗” 我们来验证这个想法public class VolatileInventory { private volatile int stock 100; public void deduct(int amount) { // 问题在这里读取和写入是两个独立的volatile操作 if (stock amount) { // volatile read stock stock - amount; // volatile write但中间的计算不是原子的 } } }这段代码在多线程下必然出错。原因在于stock stock - amount这个表达式实际包含三个步骤int temp stock;volatile readtemp temp - amount;CPU计算stock temp;volatile write步骤1和3虽然是volatile操作但步骤2是纯本地计算且步骤1和3之间没有同步屏障。因此线程A读到stock100开始计算100-1090与此同时线程B也读到stock100计算100-1090然后A和B都把90写回stock。结果本应是80却变成了90——这就是经典的竞态条件Race Condition。volatile只保证了单个读或写操作的可见性与有序性它不提供原子性。它解决的是“一个线程修改了变量另一个线程何时能看到这个修改”的问题而不是“如何保证一个复合操作不被其他线程打断”的问题。3.2 volatile的真正战场状态标志与双重检查锁定DCLvolatile最不可替代的场景是作为轻量级的状态标志。比如一个服务的启动/停止开关public class ServiceController { private volatile boolean running false; // 关键volatile修饰 public void start() { if (!running) { // 启动耗时操作... running true; // volatile write } } public void stop() { running false; // volatile write } public boolean isRunning() { return running; // volatile read } }这里running的读写都是单个操作volatile完美满足需求start()中设为true后isRunning()在其他线程中一定能立刻读到true无需加锁。另一个经典应用是双重检查锁定Double-Checked Locking用于单例模式的延迟初始化public class Singleton { private static volatile Singleton instance; // 必须volatile public static Singleton getInstance() { if (instance null) { // 第一次检查 synchronized (Singleton.class) { if (instance null) { // 第二次检查 instance new Singleton(); // 问题就在这里 } } } return instance; } }为什么instance必须是volatile因为new Singleton()不是原子操作它分为三步分配内存空间在内存空间中初始化对象调用构造函数将instance引用指向分配的内存地址在JVM和CPU的重排序优化下步骤2和3可能被交换。即线程A执行到步骤3instance已指向一块内存但步骤2构造函数还没执行完尚未完成。此时线程B恰好执行第一次检查if (instance null)发现instance ! null就直接返回这个“半初始化”的对象导致NullPointerException或诡异的逻辑错误。volatile的禁止指令重排序特性强制保证了步骤2初始化一定在步骤3赋值之前完成彻底杜绝了这个问题。经验volatile的适用场景非常明确——当你只需要保证一个布尔值、整数或引用的读写可见性且该变量的读写操作本身是原子的、不依赖于其旧值时volatile是最佳选择。一旦涉及“读-改-写”如i、list.add()就必须升级到锁或CAS。4. CAS乐观锁的精密手术刀但需警惕ABA与自旋开销4.1 CAS的原子性原理CPU指令级的“比较并交换”CASCompare-And-Swap是java.util.concurrent包的基石。它的伪代码逻辑是boolean compareAndSet(expectedValue, newValue) { if (currentValue expectedValue) { currentValue newValue; return true; } else { return false; } }但关键在于这个“比较”和“交换”在硬件层面是一条不可分割的CPU指令如x86的cmpxchg。它由CPU直接保证原子性无需操作系统介入因此性能远高于synchronized或ReentrantLock。Java中Unsafe类提供了底层CAS能力而AtomicInteger等类是对它的封装。我们看AtomicInteger.getAndIncrement()的源码简化public final int getAndIncrement() { return unsafe.getAndAddInt(this, valueOffset, 1); } // Unsafe.getAndAddInt() public final int getAndAddInt(Object o, long offset, int delta) { int v; do { v getIntVolatile(o, offset); // 读取当前值volatile read } while (!compareAndSwapInt(o, offset, v, v delta)); // CAS尝试更新 return v; }这是一个典型的自旋Spin实现不断读取当前值v然后尝试用CAS将v更新为vdelta。如果成功跳出循环如果失败说明其他线程已修改了值就重新读取新值再次尝试。4.2 ABA问题不是“没变”而是“变了又变回来”CAS如何应对ABA问题是CAS最著名的缺陷。想象一个库存场景初始stock100。线程A读到100准备扣减10此时线程B抢先进来把100扣减到90又立刻补货加回100当线程A执行CAS时发现100100于是成功将100改为90。结果是两次操作B的扣减和补货被A的CAS“覆盖”了库存凭空少了10。解决方案是引入版本号。AtomicStampedReference正是为此设计// 创建时指定初始值和初始版本号 AtomicStampedReferenceInteger stockRef new AtomicStampedReference(100, 0); public boolean deductWithStamp(int amount) { int[] stampHolder new int[1]; int currentStock stockRef.get(stampHolder); // 同时获取值和版本号 int currentStamp stampHolder[0]; while (true) { if (currentStock amount) { // 尝试用CAS更新只有当值和版本号都匹配时才成功 if (stockRef.compareAndSet(currentStock, currentStock - amount, currentStamp, currentStamp 1)) { return true; } } else { return false; } // CAS失败重新读取最新值和版本号 currentStock stockRef.get(stampHolder); currentStamp stampHolder[0]; } }每次成功更新版本号stamp都会递增。即使值变回原样版本号也不同了CAS自然失败。这就像银行流水不仅要看余额还要看交易序号。4.3 自旋开销当“乐观”变成“盲目等待”如何优雅退场CAS的自旋策略在低竞争下效率极高但在高竞争下线程会陷入“读-失败-重试”的死循环白白消耗CPU。LongAdder就是针对此问题的优化方案public class InventoryCounter { private final LongAdder counter new LongAdder(); public void deduct(int amount) { counter.add(-amount); // 内部采用分段计数Striped64 } public long getStock() { return counter.sum(); // 汇总所有分段的值 } }LongAdder的思路是“化整为零”它内部维护一个Cell[]数组每个线程尝试更新时先通过哈希算法定位到一个特定的Cell进行CAS。只有当该Cell竞争激烈时才扩容数组增加新的Cell。这样多个线程的操作被分散到不同的内存位置极大降低了CAS冲突概率。sum()方法则遍历所有Cell求和。实测数据在100个线程并发调用increment()时LongAdder的吞吐量通常是AtomicLong的5倍以上。但它的代价是sum()不是强一致的——它返回的是一个近似快照值适用于统计类场景如QPS计数而不适用于强一致性要求的库存扣减。踩坑经验不要迷信“无锁”。LongAdder的sum()在极端情况下可能比实际值小因为某些线程的更新还未被sum()看到。如果你的业务要求“每次查询库存必须绝对准确”那LongAdder就不合适必须回到ReentrantLock或StampedLock。5. 线程通信从wait/notify到JUC工具协同作战的指挥系统5.1 wait/notifyObject级别的原始信号灯但必须与synchronized捆绑wait()和notify()是Java最基础的线程协作机制但它们的使用规则极其严格必须在synchronized同步块中调用调用对象必须是synchronized锁住的那个对象wait()会释放锁notify()不会释放锁。一个经典的生产者-消费者模型public class BoundedBuffer { private final ListInteger buffer new ArrayList(); private final int capacity 10; public void produce(int item) throws InterruptedException { synchronized (this) { while (buffer.size() capacity) { // 必须用while不是if this.wait(); // 释放this锁进入等待队列 } buffer.add(item); this.notifyAll(); // 唤醒所有等待者生产者唤醒消费者消费者也可能唤醒生产者 } } public int consume() throws InterruptedException { synchronized (this) { while (buffer.isEmpty()) { // 同样必须用while this.wait(); } int item buffer.remove(0); this.notifyAll(); return item; } } }为什么必须用while循环而不是if假设三个消费者线程都在wait()此时一个生产者notifyAll()三个消费者全部被唤醒。但只有一个能成功remove()另外两个会因buffer.isEmpty()再次进入wait()。如果用if第二个消费者被唤醒后会直接执行remove(0)导致IndexOutOfBoundsException。notify()和notifyAll()的选择也至关重要。notify()只唤醒一个等待线程但无法保证唤醒的是哪个线程。在复杂场景下如多个条件等待它可能导致信号丢失或死锁。notifyAll()虽然开销稍大但能确保所有相关等待线程都有机会重新检查条件是更安全的选择。5.2 ConditionLock的“多路复用”信号系统告别单一等待队列ReentrantLock配合Condition解决了synchronized只能有一个隐式等待队列的痛点。我们可以为不同条件创建独立的Conditionpublic class BoundedBufferWithCondition { private final ReentrantLock lock new ReentrantLock(); private final Condition notFull lock.newCondition(); // 缓冲区不满条件 private final Condition notEmpty lock.newCondition(); // 缓冲区不空条件 private final ListInteger buffer new ArrayList(); private final int capacity 10; public void produce(int item) throws InterruptedException { lock.lock(); try { while (buffer.size() capacity) { notFull.await(); // 等待notFull条件释放lock } buffer.add(item); notEmpty.signal(); // 唤醒等待notEmpty条件的线程 } finally { lock.unlock(); } } public int consume() throws InterruptedException { lock.lock(); try { while (buffer.isEmpty()) { notEmpty.await(); // 等待notEmpty条件 } int item buffer.remove(0); notFull.signal(); // 唤醒等待notFull条件的线程 return item; } finally { lock.unlock(); } } }Condition的优势在于精准唤醒。生产者调用notFull.await()后只会被notFull.signal()唤醒消费者调用notEmpty.await()后只会被notEmpty.signal()唤醒。这避免了synchronized中notifyAll()唤醒所有线程造成的“惊群效应”提升了效率。5.3 CountDownLatch与CyclicBarrier面向场景的“倒计时”与“集合点”CountDownLatch和CyclicBarrier都用于协调多个线程的到达但语义截然不同特性CountDownLatchCyclicBarrier用途一个或多个线程等待其他线程完成一组操作多个线程互相等待直到全部到达一个屏障点计数器初始化后只能递减不可重置到达后自动重置可重复使用触发动作计数器为0时所有等待线程被释放最后一个线程到达时所有线程被释放并可执行barrierAction一个库存预热场景系统启动时需要并行加载商品、价格、库存三个维度的数据全部加载完成后服务才对外提供。public class InventoryPreloader { private final CountDownLatch latch new CountDownLatch(3); public void preload() throws InterruptedException { // 并发启动三个加载任务 new Thread(this::loadProducts).start(); new Thread(this::loadPrices).start(); new Thread(this::loadStocks).start(); latch.await(); // 主线程等待直到latch计数为0 System.out.println(预热完成服务启动); } private void loadProducts() { // 加载商品逻辑... latch.countDown(); // 完成后计数减1 } private void loadPrices() { // 加载价格逻辑... latch.countDown(); } private void loadStocks() { // 加载库存逻辑... latch.countDown(); } }而CyclicBarrier更适合“多线程协作完成一个任务”的场景比如分布式ID生成器中多个节点需要定期同步时间戳public class TimeSyncBarrier { private final CyclicBarrier barrier new CyclicBarrier(3, () - { // 当3个线程都到达时执行此回调同步时间 System.out.println(时间同步完成); }); public void syncTime() throws InterruptedException, BrokenBarrierException { // 模拟各节点执行自己的时间校准逻辑 Thread.sleep(100); barrier.await(); // 等待其他节点 } }关键区别CountDownLatch是“一等多”主线程等子线程CyclicBarrier是“多等多”所有线程互等。选错会导致程序永远卡住。6. 组合拳实战一个高并发库存服务的完整实现与避坑指南6.1 需求再确认什么是真正的“线程安全库存”在动手编码前我们必须厘清业务语义。一个电商库存服务通常需要满足强一致性任何时刻数据库记录的库存数 系统中所有未完成订单占用的库存 可售库存。防超卖并发扣减时绝不允许stock变为负数。高性能在大促峰值下QPS需达到10万/秒。可降级当核心库存服务不可用时能快速切换到本地缓存或限流策略。这意味着我们不能只考虑单机内存中的int stock而必须将数据库事务、缓存一致性、分布式锁纳入整体设计。本文聚焦单机JVM内的核心机制但会明确指出与外部系统的衔接点。6.2 方案选型对比为什么最终选择“Redis Lua脚本 本地CAS”混合架构我们评估了三种主流方案方案核心机制优点缺点适用场景纯数据库乐观锁UPDATE inventory SET stockstock-? WHERE id? AND stock?强一致性无需额外组件高并发下数据库压力巨大连接池易打满中小流量强一致性要求极高Redis分布式锁RedlockSET resource_name random_value NX PX 30000解耦数据库性能好锁失效时间难精确控制网络分区下可能失效分布式系统容忍短暂不一致Redis Lua脚本 本地CASLua脚本在Redis端原子执行扣减本地用AtomicLong做二级缓存原子性由Redis保证本地CAS加速读取Lua脚本可实现复杂逻辑需要Lua脚本编写能力调试稍复杂高并发强一致性高性能双重要求最终选择了第三种。理由很务实Redis的单线程模型天然保证了Lua脚本的原子性而AtomicLong在本地做读缓存将90%的读请求拦截在JVM内只有写请求才穿透到Redis。这既满足了强一致性写操作原子又实现了高性能读操作零延迟。6.3 核心代码实现从原子操作到异常兜底的完整链路Component public class InventoryService { Autowired private StringRedisTemplate redisTemplate; // 本地库存缓存用于高频读取 private final AtomicLong localStockCache new AtomicLong(-1); // -1表示未初始化 private final ScheduledExecutorService refreshScheduler Executors.newSingleThreadScheduledExecutor(); // Redis Lua脚本原子扣减 private static final String LUA_DEDUCT_SCRIPT local stock tonumber(redis.call(GET, KEYS[1])) if not stock or stock tonumber(ARGV[1]) then return -1 else return redis.call(DECRBY, KEYS[1], ARGV[1]) end; private final DefaultRedisScriptLong deductScript new DefaultRedisScript(LUA_DEDUCT_SCRIPT, Long.class); public InventoryService() { // 启动时异步加载库存到本地缓存 refreshLocalCache(); // 每30秒刷新一次本地缓存防止长时间不一致 refreshScheduler.scheduleAtFixedRate( this::refreshLocalCache, 0, 30, TimeUnit.SECONDS); } private void refreshLocalCache() { try { String stockStr redisTemplate.opsForValue().get(inventory:1001); long stock stockStr ! null ? Long.parseLong(stockStr) : 0; localStockCache.set(stock); } catch (Exception e) { // 日志记录但不中断主流程 log.warn(Refresh local cache failed, e); } } /** * 扣减库存 * param itemId 商品ID * param amount 扣减数量 * return 扣减后剩余库存-1表示失败库存不足或异常 */ public long deduct(String itemId, int amount) { try { // 1. 先尝试本地CAS扣减乐观快速失败 long current localStockCache.get(); if (current ! -1 current amount) { long updated current - amount; // CAS更新如果失败说明本地缓存已过期走Redis if (localStockCache.compareAndSet(current, updated)) { return updated; } } // 2. 本地CAS失败走Redis原子扣减 String key inventory: itemId; Long result redisTemplate.execute( deductScript, Collections.singletonList(key), String.valueOf(amount) ); if (result ! null result 0) { // Redis扣减成功更新本地缓存 localStockCache.set(result); return result; } else { return -1; // 库存不足 } } catch (Exception e) { log.error(Deduct inventory failed for item {}, itemId, e); // 降级返回本地缓存值可能不准但保证可用 return localStockCache.get(); } } /** * 查询库存只读走本地缓存 */ public long getStock(String itemId) { return localStockCache.get(); } }6.4 生产环境踩坑实录那些文档里不会写的细节坑1本地缓存的“脏读”与“雪崩”现象大促期间发现部分商品库存显示为负数。根因localStockCache.compareAndSet(current, updated)在高并发下多个线程同时读到current100都计算100-1090然后都CAS成功导致本地缓存被多次减为90而Redis只被扣减了一次。修复移除本地CAS扣减改为本地只读缓存。扣减操作一律走Redis Lua脚本本地缓存仅用于getStock()查询。deduct()方法中localStockCache.get()只用于快速判断“大概率不足”不参与决策。坑2Redis连接池耗尽现象deduct()方法大量超时redisTemplate.execute()耗时飙升。根因StringRedisTemplate默认连接池大小为8而我们的QPS峰值达5万连接池瞬间打满。修复配置LettuceClientConfiguration将maxActive设为500maxIdle设为200并启用usePooltrue。坑3Lua脚本的原子性边界现象Lua脚本执行成功但业务逻辑后续报错导致库存已扣减但订单未创建出现“幽灵扣减”。根因Lua脚本只保证Redis操作原子不保证整个业务事务。必须在业务层实现补偿机制。修复引入消息队列。deduct()成功后发送一条“库存扣减成功”消息订单服务消费该消息创建订单若订单创建失败则发送“库存回滚”消息由库存服务执行INCRBY操作。最后一点心得线程安全不是终点而是起点。一个真正可靠的库存系统必须是“JVM内核机制 分布式协调 业务补偿”三层防御体系。本文所讲的锁、CAS、volatile、通信机制只是第一层——它们决定了你的代码在单机上能否正确运行。而第二层Redis、ZooKeeper和第三层消息队列、Saga事务才是保障分布式系统最终一致性的关键。永远记住没有银弹只有根据业务场景精心组装的解决方案。