开头部分这样写上次写完线程生命周期之后有不少读者留言说想继续深入。今天这第三篇就专门把“线程同步”这个坑讲透。为什么要单开一篇因为在多线程编程里线程怎么创建、怎么启动只是入门线程之间怎么配合、怎么保证数据不错乱才是真正的工作。说句得罪人的话我在面试里见过不少人线程池参数背得滚瓜烂熟一遇到多线程共享变量数据错乱、偶发死锁、程序明明在跑但结果就是不对马上抓瞎。这类问题十有八九都出在同步上。这篇博文默认你已经掌握了 Java 多线程的基本创建方式和生命周期主要内容包括为什么需要同步、synchronized 的底层与使用细节、Lock 体系的灵活用法、volatile 和原子类的边界、wait/notify 线程协作、死锁的定位与规避以及最后的实战方案选型。系列前两篇讲的是线程创建和生命周期这篇会在基础之上补上并发编程最关键的拼图。如果你正准备面试或者项目里刚好被并发问题折腾得头疼这篇文章应该能给你省下不少查资料的时间。1. 为什么需要线程同步1.1 从一个经典的并发事故现场说起先抛一个小实验。两个线程同时对同一个 int 变量做 1 万次加一操作你猜最后结果是多少正常数学逻辑是 2 万。但实际跑起来结果大概率是 19995、19987甚至更低。每次运行还不一样。这就是并发编程里最典型的“竞态条件”。代码长这样public class UnsafeCounter { private static int count 0; public static void main(String[] args) throws InterruptedException { int threadCount 2; int loopCount 10000; Thread[] threads new Thread[threadCount]; for (int i 0; i threadCount; i) { threads[i] new Thread(() - { for (int j 0; j loopCount; j) { count; } }); threads[i].start(); } for (Thread t : threads) { t.join(); } System.out.println(count count); } }多次运行后你可能会看到 count 19989、20000运气好时、19967 之类的结果。问题就出在count这一行。很多新手觉得这是一次“读一下、加一下、写回去”的原子操作但实际上它在 CPU 层面需要好几条指令才能完成。两个线程的指令如果交错执行就会出现“丢失更新”的情况两个线程都读到了旧值 10各自加 1 后都写回 11结果明明是两次操作最终只加了一次。这里有几个基本概念需要先对齐。多个线程同时访问的代码区域叫“临界区”多个线程同时读写同一个共享变量导致结果不可预期的现象叫“竞态条件”“原子性”指的是一组操作要么全部执行成功要么全部不执行中间不允许被其他线程插入。线程同步要解决的核心问题就是让临界区内的代码具备原子性保证一组操作在线程调度时不被拆散。1.2 从字节码看 i 为什么不是原子的如果只用“CPU 指令交错”来解释有些人可能还是没感觉。那我们把count编译后的字节码拉出来看一眼。对编译后的 class 文件执行javap -c UnsafeCounter你会看到类似下面这样的指令序列getstatic // 读取 count 的当前值 iconst_1 // 常量 1 入栈 iadd // 执行加法 putstatic // 把结果写回 count每一步之间都可能发生线程上下文切换。线程 A 执行完getstatic拿到 10时间片用完了线程 B 也拿到 10然后完成加一写回 11线程 A 恢复执行后它手里拿的还是那个过期的 10加一以后写回 11。这个线程 A 的操作就被“覆盖”了。这正是我要强调的并发问题不是玄学是实打实的指令交错。只要多个线程同时进入临界区而临界区没有同步保护结果就不可预期。所以在 Java 里需要一把“锁”让同一时刻只有一个线程能进入临界区其他线程必须在门外等。2. synchronizedJava 内置的锁前面挖了坑现在来填坑。Java 里最基础、最常用的同步手段就是synchronized关键字。它可以在三个位置使用修饰实例方法、修饰静态方法、包裹代码块。虽然姿势不同但底层逻辑一致进入临界区前先获取锁退出时释放锁。2.1 synchronized 的三种基本用法用 synchronized 修饰实例方法是同步效果最直观的写法public synchronized void increment() { count; }这种情况下锁是当前实例对象 this。同一个对象调用这个方法时只有一个线程能进入不同对象调用锁各不相同互不干扰。用代码块的方式能更精确地控制锁的范围避免整段方法被锁住public void increment() { // 非临界区代码不需要同步 String logMsg Thread Thread.currentThread().getName() entering; // 只把临界区包起来 synchronized (this) { count; } }函数式写法也支持直接锁任意对象后续会细说。第三种是静态方法加锁。静态方法属于类级别锁的对象是这个类的 Class 对象而不是某个实例。也就是说即使你创建了 100 个实例它们调用这个静态方法时也会互相竞争同一把锁。public static synchronized void staticIncrement() { count; }这三种用法对应着不同的锁目标也是面试里常挖坑的地方。面试官经常问两个线程分别调用同一个类的两个不同 synchronized 实例方法能不能同时进入答案是不能因为两个方法锁的都是同一个 this 对象。但如果一个是实例方法、一个是静态方法就能同时进入因为它们的锁目标不同一个是实例对象一个是 Class 对象。2.2 锁的对象决定了同步效果很多初学 Java 多线程的同学最容易踩的坑是以为加了 synchronized 就万事大吉结果换个写法锁失效了。常见反例如下public class BadSync { private int count 0; public void increment() { synchronized (new Object()) { // 每次调用都 new 一个新锁对象 count; } } }这段代码等于没加锁。两个线程各自拿了一把新锁谁也拦不住谁。正确的做法是确保所有线程竞争的是同一个对象。最稳妥的方式是声明一个专用锁public class GoodSync { private final Object lock new Object(); private int count 0; public void increment() { synchronized (lock) { count; } } }为什么要专门搞一个final Object lock因为这样既不会把锁暴露给外部又能保证所有进入该方法的线程拿的是同一把锁。还有个容易被忽略的细节如果用String常量作为锁对象只要常量值相同JVM 里的 String 对象可能是同一个两个毫不相干的业务模块可能因此互相阻塞。我后面实战部分会专门讲这个真事先记住结论尽量使用private final Object做锁别图省事用字符串。2.3 锁升级从占座到叫保安不少人听过一个说法JDK 1.6 之前 synchronized 性能差之后做了优化。到底优化了什么其实就是引入了锁升级机制。synchronized 不再一上来就是重量级锁而是根据竞争激烈程度在四种状态之间升级无锁 → 偏向锁 → 轻量级锁 → 重量级锁。可以这样理解。偏向锁像是图书馆占座线程 A 第一次进来在锁对象上写了个标记“这个位置是 A 的”只要没有别的人来抢A 以后每次进出都不需要再办任何手续直接对号入座。轻量级锁像是有人来抢座位了A 和 B 开始用 CAS比较并交换自旋抢占谁抢到谁进抢不到的多试几次不立刻挂起毕竟线程挂起再唤醒很耗时。如果抢的人越来越多自旋也解决不了问题就升级为重量级锁由操作系统管着抢不到锁的线程直接进入阻塞队列排队等待唤醒。这个升级过程也解释了为什么 synchronized 在低竞争场景下性能并不差。所以你不用一上来就嫌弃它很多业务场景用它完全够了。3. Lock 与更灵活的同步姿势JDK 5 开始引入了java.util.concurrent.locks.Lock接口最常用的实现是ReentrantLock。如果说 synchronized 是一把全自动锁Lock 就是一把手动挡的锁功能更多但需要你自己操作解锁。3.1 ReentrantLock 的标准姿势最标准的使用方式如下Lock lock new ReentrantLock(); public void increment() { lock.lock(); try { count; } finally { lock.unlock(); } }记住一个铁律lock()之后必须在 finally 里调用unlock()。否则临界区抛异常锁就永远释放不了其他线程全部卡死。这种“必须手动释放”的特性是 Lock 和 synchronized 最大的使用差异。ReentrantLock 叫“可重入锁”意思是同一个线程可以多次获取同一把锁而不会把自己卡死。比如一个方法加了 lock方法内部又调用了另一个需要同一把 lock 的方法这个线程能正常进去锁内部维护了一个计数器每次进入加一每次释放减一减到零才真正释放。synchronized 也是可重入的这一点两者一致。3.2 tryLock 与锁超时避免无限等待我实际项目里用得比较多的是tryLock它能解决一个 synchronized 很难处理的痛点等锁超时。比如第三方接口在锁内部超时了synchronized 会让所有等待线程一直阻塞直到持锁线程恢复而tryLock允许我们设置最长等待时间超时后走降级方案而不是傻等。if (lock.tryLock(2, TimeUnit.SECONDS)) { try { // 拿到了锁执行临界区逻辑 count; } finally { lock.unlock(); } } else { // 2 秒还没拿到锁直接走降级逻辑避免卡死 System.out.println(获取锁超时走降级处理); }这个能力在处理部分接口超时、批量任务总超时等场景非常实用。当然代价是代码复杂度上来了你多了一个 else 分支需要处理。3.3 synchronized 还是 Lock怎么选这是老生常谈的话题。直接给结论日常业务代码优先用 synchronized只有当你需要“尝试获取锁”“可中断获取锁”“公平锁”或“多个条件变量”时再考虑 ReentrantLock。公平锁这里简单提一句它是指多个线程在等待锁时按先来后到的顺序获取而不是抢占。ReentrantLock 构造时传入true即启用公平锁Lock fairLock new ReentrantLock(true);但公平锁会牺牲一部分吞吐量实际业务里大多数场景不需要。读多写少的场景还可以考虑ReentrantReadWriteLock读写锁允许多个读线程同时访问写线程独占。不过写锁容易饥饿如果读线程非常多写线程可能长期拿不到锁。JDK 8 以后的StampedLock通过乐观读进一步优化了读性能但 API 更复杂有空可以单独水一篇。4. volatile 与原子类轻量级同步方案说完重量级的锁再来看两个轻量级选手volatile关键字和java.util.concurrent.atomic包下的原子类。它们的同步力度没有锁重但在合适场景下很香。4.1 volatile 只解决可见性不解决原子性先看一段常见代码public class VolatileDemo { private static boolean flag false; public static void main(String[] args) throws InterruptedException { Thread t new Thread(() - { while (!flag) { // 死循环等待 } System.out.println(flag 变化了线程结束); }); t.start(); Thread.sleep(100); flag true; // 主线程修改 flag } }如果不加 volatile这个程序很可能永远无法退出。原因在于线程之间的“可见性”问题每个线程在运行时会把共享变量复制一份到自己的工作内存主线程修改了 flag 的副本工作线程可能一直读着自己本地缓存里的旧值看不到刷新。volatile做的事情就是强制每次读取共享变量时都从主内存拿最新的值并且禁止 CPU 指令重排序。它解决了“可见性”和一定程度上的“有序性”但解决不了“原子性”。这就要说回最开始的count问题了。就算把count声明为volatile int count 0两个线程自增结果还是可能出错。因为 volatile 只保证“读到的 count 是最新的”但读、加、写三个步骤之间依然可能被其他线程插入丢失更新照样发生。记住这一条面试遇到 volatile 必考“它为什么不保证原子性”回答能到这里基本就稳了。4.2 AtomicInteger 与 CAS 乐观锁思想既然count不是原子的那能不能造一个原子版的count可以AtomicInteger 就能干这件事AtomicInteger count new AtomicInteger(0); // 等价于 count但整个操作为原子操作 count.incrementAndGet();AtomicInteger底层的核心机制是 CAS全称 Compare And Swap中文叫“比较并交换”。CAS 的操作逻辑是先读取内存值 V计算得到新值 B准备写回之前再比对一次内存值 V如果 V 没变过就用新值 B 替换如果 V 变了就重试。整个过程是 CPU 指令级别的原子操作不需要加锁。CAS 是一种“乐观锁”思想它假设并发冲突不严重先尝试操作失败了再重试synchronized 则是“悲观锁”先锁住资源再操作。两者各有适用场景。CAS 在并发竞争激烈时大量线程会不断自旋重试CPU 飙高这时候就未必比 synchronized 好。4.3 复合操作的坑先检查后执行原子类解决了很多单一变量的原子问题但它解决不了“复合操作”的原子性。比如扣库存你先判断库存是否大于 0再执行扣减。这两个操作分开看都是原子的但合在一起中间依然可能被其他线程插入导致超卖。if (stock.get() 0) { // 判断 stock.decrementAndGet(); // 扣减 }这段逻辑在并发下会有问题两个线程同时判断库存大于 0然后一起扣减库存变成负数。要保证这两个操作作为一个整体不被拆散要么用 synchronized 包起来要么用compareAndSet这类方法自己写重试逻辑int current; int next; do { current stock.get(); if (current 0) { // 库存不足直接返回 return; } next current - 1; } while (!stock.compareAndSet(current, next));这个模式叫 CAS 循环也是很多并发组件内部的实际写法。理解了它你就掌握了并发编程中“自旋 CAS”这一大流派的核心思路。5. 线程协作wait/notify 与生产者消费者锁解决的是“互斥”但很多场景光互斥还不够线程之间还需要“协作”。比如生产者把队列写满了需要停下来等消费者消费消费者把队列清空了需要等生产者生产。这类线程间通信在 Java 里最经典的实现就是wait()和notify()。5.1 wait/notify 的三个关键规则第一wait()、notify()、notifyAll()这三个方法必须在线程持有锁的前提下调用也就是必须放在 synchronized 块或者 synchronized 方法里。否则会抛IllegalMonitorStateException。第二wait()会释放当前线程持有的锁并进入等待状态。这一点和Thread.sleep()完全不同sleep 不会释放锁它只是让线程暂停执行。所以在 synchronized 块里调用 sleep其他线程依然进不去而调用 wait其他线程就有机会拿到锁进入临界区。这个区别是面试高频题一定记牢。第三notify()唤醒一个正在等待的线程但唤醒之后并不会立刻释放锁。当前线程必须等自己的 synchronized 块执行完、锁释放后被唤醒的线程才有机会重新抢锁。notifyAll()则是唤醒所有等待线程让它们一起去抢锁。实际工程里 notifyAll 更安全因为 notify 如果唤醒的线程恰好不满足条件它还会继续 wait可能导致“信号丢失”。5.2 生产者消费者的完整写法一个典型的生产者消费者模型用 synchronized wait/notify 实现大概长这样class SharedQueue { private final LinkedListInteger queue new LinkedList(); private final int capacity 5; public synchronized void produce(int value) throws InterruptedException { while (queue.size() capacity) { wait(); // 队列满了等消费者消费 } queue.offer(value); System.out.println(生产 value 当前队列 queue.size()); notifyAll(); } public synchronized int consume() throws InterruptedException { while (queue.isEmpty()) { wait(); // 队列空了等生产者生产 } int value queue.poll(); System.out.println(消费 value 当前队列 queue.size()); notifyAll(); return value; } }生产者线程调用 produce消费者线程调用 consume。队列满时生产者 wait队列空时消费者 wait状态变化时通过 notifyAll 唤醒对方。这是多线程协作最经典的模板建议能默写。5.3 if 与 while虚假唤醒的教训注意上面代码里我用的是while (queue.size() capacity)而不是if。这不是随手写的是因为存在“虚假唤醒”现象。即使没有线程调用 notify等待线程也可能因为操作系统底层原因被偶尔唤醒。如果是 if 判断被唤醒后直接往下执行但此时队列可能还是满的插入就会出错。用 while 循环可以在被唤醒后再次检查条件条件不满足就继续 wait这才万无一失。这是很多线上事故的根源。我见过一个支付通知场景开发用 if 判断任务状态结果两个线程同时被唤醒同一笔订单被处理了两次。排查到最后就是因为当时的 if 判断没有覆盖掉虚假唤醒或者说没有应对多线程唤醒后的重新校验。面对这类状态判断统一用 while 才是正确姿势。6. 死锁必踩的坑与定位方法6.1 手写一个死锁死锁是并发编程里最容易理解、也最让人头疼的问题。先看一个标准的死锁现场public class DeadlockDemo { private static final Object lockA new Object(); private static final Object lockB new Object(); public static void main(String[] args) { Thread t1 new Thread(() - { synchronized (lockA) { System.out.println(线程1拿到了锁A); try { Thread.sleep(100); } catch (InterruptedException e) {} synchronized (lockB) { System.out.println(线程1拿到了锁B); } } }); Thread t2 new Thread(() - { synchronized (lockB) { System.out.println(线程2拿到了锁B); try { Thread.sleep(100); } catch (InterruptedException e) {} synchronized (lockA) { System.out.println(线程2拿到了锁A); } } }); t1.start(); t2.start(); } }运行后线程 1 持有锁 A 等锁 B线程 2 持有锁 B 等锁 A谁也不让谁程序卡死在那里。产生死锁必须同时满足四个条件互斥条件、请求保持条件、不可剥夺条件、循环等待条件。只要打破其中任何一个死锁就能解除。6.2 jstack 定位死锁线上出现死锁最直接的手段是用 JDK 自带工具定位。先在终端输入jps -l找到目标 Java 进程的 PID再执行jstack PID threaddump.txt打开 threaddump.txt最后面如果出现这样的内容基本就实锤了Found one Java-level deadlock: Thread-1: waiting to lock monitor 0x000000000... Thread-0: ...jstack 会直接告诉你死锁双方各自持有哪把锁、在等待哪把锁、代码在哪一行。这个工具真的是排查并发问题的救命稻草。有时候问题不一定是真死锁而是某个线程长时间不释放锁导致其他线程全部 BLOCKEDjstack 同样能看到线程卡在哪个方法、持有什么锁。遇到线上问题第一反应应该是拿线程快照而不是瞎猜。6.3 避免死锁的实操建议死锁难排查但其实不难预防。我在项目中常用的几个原则是第一多个线程加多个锁时保证每个线程获取锁的顺序一致。比如大家都先拿锁 A 再拿锁 B不再有人先 B 后 A循环等待就断了。第二能用 tryLock 的地方尽量用 tryLock设置超时时间拿不到锁就放弃而不是无限等。第三缩小锁范围。一个方法里同时锁多个对象时仔细确认是否需要同时持有能拆开就别合在一起。第四尽量避免在持锁期间调用外部方法特别是远程调用。远程方法耗时不确定一旦超时锁一直被占用很容易引发连锁阻塞。7. 实战中的同步方案选择与性能优化7.1 先对照场景选方案很多人学了一堆并发工具到实际场景又不知道用哪个。我按常见业务场景整理了一张选型表业务场景推荐方案理由多线程操作共享 int 变量简单的自增/自减AtomicInteger / AtomicLong无锁、性能好、代码简单对多个字段做一致性更新synchronized 代码块直接、可靠、不易出错需要等待锁超时、可中断、公平锁ReentrantLock提供 tryLock、lockInterruptibly 等能力读多写少读操作可以并行ReentrantReadWriteLock读读不互斥提高吞吐量状态开关、可见性保证如退出标记volatile只保证可见性不涉及复合操作多线程集合操作ConcurrentHashMap / CopyOnWriteArrayList并发容器内部已做同步普通场景够用生产者消费者队列BlockingQueue 系列直接提供阻塞队列实现避免重复造轮子还有一个容易被忽略的点能用并发容器解决的问题尽量不要自己去加锁。比如ConcurrentHashMap内部已经用了 CAS 分段锁等机制直接用它比自己包装一个 HashMap 再手动同步高效得多。7.2 锁粒度不是越多越好同步的代价是性能损耗和并发度下降。锁的范围越大实际上越接近串行执行。所以控制锁粒度很有必要。基本原则有两条锁住临界区的代码越少越好锁内不要做耗时操作。反面典型public synchronized void process(ListInteger list) { // 大量不涉及共享变量的计算 for (Integer item : list) { // do something... } count; }这个方法把无关耗时操作全部锁死了。如果只是count需要保护就应该只锁住那一小段。反过来锁粒度也不是越小越好。比如在循环里反复加锁、解锁锁的获取释放开销可能超过执行本身这时候就该把锁提到循环外做一次“锁粗化”。7.3 我自己踩过的三个坑写到这里分享几个我在真实项目里踩过的坑希望后来者别走老路。第一个坑是拿字符串常量当锁。我之前给两个不同的业务模块定义了相同的字符串常量payLock作为锁对象结果两个模块之间莫名其妙互相阻塞支付和退款接口互相卡死。排查了很久才意识到字符串常量在 JVM 里默认会被 intern两个模块引用的是同一个对象。从那以后我的所有锁对象都改成private static final Object LOCK new Object()顺手还排查了一遍历史代码。第二个坑是在 synchronized 块里调用远程 RPC。有一次第三方渠道接口超时锁一直被占着整个下单流程全部堵住事故等级直接拉满。后来我遵守了一条铁律绝对不在持锁状态下调用外部接口先把数据复制到局部变量释放锁再远程调用或者用 tryLock 加超时兜底。第三个坑是没搞清楚 volatile 的边界。当时用volatile Long修饰一个统计字段做自增操作跑了一段时间后数据少了不少。一开始怀疑是数据库问题后来发现就是丢失更新。改成AtomicLong之后数据就准了。这个经历再次印证了那句话volatile 保证可见性但不保证原子性。说起来线程同步这事真正理解了之后就一句话管住共享可变状态。能不用共享就不用共享能用不可变对象就用不可变对象非共享不可就把可变的部分隔离好最后才考虑加锁或者上并发容器。顺序别搞反不然代码越写越复杂问题越修越多。最后再分享一个实用的小习惯写多线程代码的时候顺手把 jstack 线程快照导出来看一眼尤其是程序在跑但结果不对的时候。多线程问题的调试思路和普通业务 bug 不太一样很多偶发性问题靠肉眼 review 看不出来让工具帮你定位比自己瞎猜高效得多。