找工作时几乎每个后端岗位都绕不开这两个关键字synchronized 和 volatile。上一份项目里我做支付状态机的并发控制用 volatile 做状态标识、synchronized 做资源竞争保护踩了不少坑也把 HotSpot 源码层面的行为摸了一遍。这篇文章我把两个核心关键词的实现原理、底层指令、典型场景和容易误解的细节全部讲清楚尤其适合正在应付面试、或者真正想搞懂自己在写什么代码的开发者。先说结论volatile 的本质是内存屏障 禁止重排序synchronized 的本质是监视器锁 对象头状态流转。一个管可见性和有序性一个通吃原子性、可见性、有序性但它们都不是万能的。你会发现越到后面为什么 synchronized 在无竞争时几乎零开销、为什么 volatile 修饰的变量不能替代原子类这些问题答案都藏在硬件层和 JVM 编译器的组合逻辑里。1. 并发问题的底层源头为什么需要这两个关键字1.1 从 CPU 缓存到 Java 内存模型先问一个最基础的问题到底是什么导致了并发环境下程序结果不可控现代 CPU 核心里都有多级缓存L1、L2、L3每个线程跑在一个核上时首先访问的是自己的缓存和寄存器。Java 程序里的共享变量原始数据存在内存主内存里但线程读写变量时并不会每次都直接访问内存而是先把值读到自己的工作内存/寄存器中修改后再刷回内存。这层缓存带来的收益非常大但代价是一个线程修改了变量另一个线程在另一个核上读取到的是自己缓存里的旧值感知不到变化。这就是可见性问题。JMMJava 内存模型为了屏蔽不同硬件结构的差异抽象出一套统一规则它规定了变量都存在于主内存中每个线程有自己的工作内存里面保存了变量的副本线程对变量的所有操作必须在工作内存中进行不能直接操作主内存线程之间不能互相访问对方的工作内存只能通过主内存传递值基于这套规则JMM 用happens-before原则定义了哪些场景下的操作顺序性、可见性是有保证的。synchronized 和 volatile 正是 JMM 实现这些保证的两大工具。1.2 并发安全的三个要素谁管什么我们先建立一个比对框架。并发安全要解决三个问题特性含义synchronizedvolatile原子性一组操作要么都成功要么都失败不可分割能保证进入锁代码块时互斥操作不会交错不能保证只保证单个读写操作本身原子复合操作如 i 依然不安全可见性一个线程修改后其他线程能及时看到新值能保证释放锁时会把工作内存的新值刷新回主内存能保证volatile 写会强制刷主内存读强制从主内存取有序性编译器/CPU 不会对操作进行影响结果的乱序能保证锁内部的代码块在并发视角下有清晰的顺序边界能保证通过内存屏障禁止指令重排序从表里可以看出synchronized 是全通型的volatile 是专项型的。但两者并行不悖因为 synchronized 的实现代价更高、更重量级而很多场景其实只需要可见性和有序性的保证比如状态标志位的更新。2. synchronized 的实现原理从字节码到锁升级2.1 字节码层面的三条指令在 Java 代码里写 synchronized 有两种方式同步代码块和同步方法。同步方法实际上找 javap 反编译会发现它有 ACC_SYNCHRONIZED 标志位而同步代码块编译后生成的是两条指令// 示例代码 public class SyncDemo { private final Object lock new Object(); public void doWork() { synchronized (lock) { System.out.println(in critical area); } } }用 javap -v 反编译之后能看到核心字节码长这样public void doWork(); descriptor: ()V flags: ACC_PUBLIC Code: stack2, locals3, args_size1 0: aload_0 1: getfield #4 Field lock:Ljava/lang/Object; 4: dup 5: astore_1 6: monitorenter 7: getstatic #7 Field System.out:Ljava/io/PrintStream; 10: ldc #13 String in critical area 12: invokevirtual #14 Method PrintStream.println:(Ljava/lang/String;)V 15: aload_1 16: monitorexit ... Exception table: from to target type 7 15 17 any ... 17: aload_1 18: monitorexit 19: aload_0注意看monitorenter和monitorexit。每个对象在 JVM 内部都会关联一个 monitor监视器monitorenter就是尝试获取这个对象的 monitor 所有权monitorexit就是释放。而且编译器会自动生成一条异常路径下的 monitorexit异常表里 from 7 to 15 target 17这就是 synchronized 块抛出异常也会自动释放锁的语言层面保证不需要你手动 catch 写 finally。这里藏着一个小知识点可重入性。同一个线程可以多次对该 monitor 执行 monitorenter每进入一次monitor 里的计数器加 1每执行一次 monitorexit减 1直到计数为 0 才算真正释放。所以你可以在 synchronized 方法 A 里调用同一个锁对象的 synchronized 方法 B不会死锁。2.2 对象头与 Mark Word锁信息存在哪HotSpot 虚拟机里对象在堆内存中的布局分为三部分对象头Header、实例数据Instance Data、对齐填充Padding。对象头又包含 Mark Word 和 Klass Pointer类型指针锁的状态就是记录在 Mark Word 里的。在 64 位 JVM 里一个 Mark Word 是 64 位它的内容会根据锁状态而重用锁状态锁标志位Mark Word 存储内容无锁01对象哈希码、分代年龄、偏向锁标志位为 0偏向锁01线程 ID、epoch、分代年龄、偏向锁标志位为 1轻量级锁00指向栈中锁记录的指针重量级锁10指向 Monitor 对象的指针GC 标记11标记 GC 状态JVM 不在对象外单独维护一个锁标志变量而是直接复用对象头的这 64 位这为零开销加锁和锁升级提供了可能。2.3 synchronized 锁升级的四个阶段这是面试官最爱追问的细节也直接反映了 JVM 对 synchronized 的性能优化历程。JDK 1.6 之后synchronized 不再是一上来就是重量级锁而是根据竞争激烈程度走一套升级路线无锁 → 偏向锁 → 轻量级锁 → 重量级锁阶段一偏向锁在大多数实际场景里一个同步代码块长时间只有同一个线程在访问。偏向锁的设计思路就是让这个线程在第一次获取锁时记录下自己的线程 ID 到 Mark Word 里之后再次进入就不需要任何同步操作直接判断 Mark Word 里的线程 ID 是自己整个加锁过程零 CAS、零原子操作。但这个优化的前提是没有其他线程竞争。一旦有另一个线程尝试获取这把锁偏向模式就要撤销如果持有锁的线程已经退出临界区则把对象头恢复成无锁状态再交给新线程如果持有锁的线程还在临界区则膨胀为轻量级锁。阶段二轻量级锁多个线程交替进入临界区、但不会同时在临界区里长时间阻塞时用偏向锁就不合适了。JVM 会在每个线程的栈帧中创建一个 Lock Record锁记录空间线程尝试通过 CAS 把 Mark Word 替换为指向自己 Lock Record 的指针。如果替换成功说明获取锁成功如果失败说明锁已被占用线程进入自旋Spin不断重试 CAS。自旋的好处是避免了线程切换的系统调用开销坏处是如果持锁线程迟迟不释放自旋的线程会白白消耗 CPU。JDK 1.6 之后引入了适应性自旋JVM 会根据上一次自旋等待成功的次数动态调整自旋时间逻辑就是历史上容易等到就多等一会儿不容易等到就趁早放弃。阶段三重量级锁当存在多个线程真正同时竞争锁、自旋也等不到时轻量级锁会升级为重量级锁。重量级锁的实现依赖操作系统层面的互斥量mutex也就是 JVM 里的 ObjectMonitor。竞争的线程会被挂起进入阻塞状态等持有锁的线程释放后由内核唤醒。线程的挂起、恢复需要由用户态切换到内核态这是同步代价最大的环节。升级过程还有一个细节锁升级是单向的只能无锁→偏向→轻量→重量不能降级。原因也很简单Mark Word 里的信息一旦从线程栈指针变成 Monitor 指针要变回去成本很高而且 JVM 的老年代 GC 也会顺便清理一些多余的锁记录。2.4 为什么现在的 synchronized 优化了很多很多人印象里 synchronized 性能很差这其实是历史包袱。早期的 HotSpot 确实一个 synchronized 就直接进内核互斥线程切换成本极高导致连最简单的计数器加锁都比不上后面 JUC 包里的 Lock。JDK 1.6 的大版本优化偏向锁、轻量级锁、自旋锁、锁消除、锁粗化加入以后情况完全变了锁消除JIT 编译器在运行时通过逃逸分析确定一个锁对象只有当前线程能访问不在其他线程逃逸就会自动去掉这个锁的同步代码。锁粗化如果 JVM 检测到同一个线程反复对同一个对象加锁、释放锁比如循环里每一次都 synchronized但其实整个循环体才是完整临界区会扩大锁的粒度把多次加锁变成一次加锁。所以现代 JVM 下无竞争或低竞争的 synchronized 开销已经非常低和 Lock 的差距很小。真正需要关注性能瓶颈的往往是临界区本身的执行时间而不是加锁语法本身。3. volatile 的实现原理内存屏障与禁止重排序3.1 volatile 变量读写时的内存屏障策略先明确一点volatile 在 Java 字节码层面并没有任何特殊指令javap 反编译看它和一个普通字段读写是一样的。它的特殊之处完全体现在 JIT 编译器生成的机器码以及 JMM 对其施加的约束上。在 JSR-133 规范里对 volatile 变量的读写前后要插入内存屏障volatile 写之前的普通读写不能重排到写之后写之前插入 StoreStore 屏障写之后插入 StoreLoad 屏障volatile 读之后的普通读写不能重排到读之前读之后插入 LoadLoad 屏障和 LoadStore 屏障这些屏障在不同 CPU 架构上的实现不同。x86 处理器有较强的内存序TSO 模型只允许写读重排序而不允许写的写重排序、读的读重排序所以 JVM 在 x86 上对 volatile 写最夸张的做法是直接生成一条lock前缀指令比如lock addl $0, (%rsp)这条指令会把 CPU 的写缓冲器Store Buffer清空让之前所有写操作的结果对其它处理器可见同时让 volatile 写之前的读写不可能穿越到写之后。这就是 volatile 实现可见性和有序性的硬件基石。在实际项目里理解内存屏障不需要把每一条都背下来但你至少要有这个思维模型volatile 写 立即刷新到主内存 一个全屏障volatile 读 从主内存重新拉取 不允许前面指令乱窜。3.2 禁止重排序到底是在防什么重排序有三种来源编译器优化重排、CPU 指令并行重排、内存系统的重排。它们都会导致一个线程中看似有先后顺序的代码在另一个线程观察到的执行顺序是乱的。举一个最经典的案例懒加载单例的双重检查锁DCL。public class Singleton { private static volatile Singleton instance; public static Singleton getInstance() { if (instance null) { // 第一次检查 synchronized (Singleton.class) { if (instance null) { // 第二次检查 instance new Singleton(); } } } return instance; } }instance字段如果不用 volatile会出大问题。new Singleton()在 JVM 里并不是原子的它大概分解为三步分配堆内存调用构造函数初始化Singleton对象将instance引用指向这块内存正常顺序是 1-2-3但 JIT 和 CPU 可能将步骤重排序为 1-3-2。当线程 A 执行完 1-3引用已经指向内存但对象的构造函数还没执行完此时线程 B 进来执行if (instance null)发现不为 null直接 return instance然后访问还没初始化的对象字段就会拿到默认值甚至引发不可预知的错误。加上 volatile 之后volatile 写之前的所有操作包括到步骤 3都不会被重排到写之后保证了对象发布的安全。3.3 volatile 的 happens-before 规则JMM 里有一条专门针对 volatile 的规则对一个 volatile 变量的写操作happens-before 后续对这个变量的任意读操作。这句话的信息量很大。它意味着如果线程 A 写一个 volatile 变量线程 B 随后读到这个变量那么在 A 写之前的其它普通变量的修改结果对 B 也是可见的。volatile 的可见性传播不是只传播这一个变量而是类似一个屏障节点写 volatile 之前的所有写操作都会被冲洗出去读 volatile 之后的所有读操作都会被重新拉取。刚才的 DCL 例子里正因为instance是 volatile线程 A 在 synchronized 块内完成 new 操作并写入 volatile 字段后线程 B 看到 instance 非空时构造期间其它普通字段的赋值也对 B 可见这才是安全的发布。3.4 volatile 做不到什么复合操作的原子性这是 volatile 最大的坑。用它修饰一个 int 字段单次count或count x是原子的因为 Java 规范保证 32 位及以下基本类型的读写是原子的。但count不是单步操作它分解为读旧值、加一、写回三步三步之间其它线程可能插进来于是丢失更新不可避免。所以 volatile 的真实应用场景集中在纯状态标志位volatile boolean running、volatile boolean closed一写多读的配置刷新发布新配置时写把配置对象引用赋值给一个 volatile 字段单例发布DCL双重检查的开关如缓存重建标识遇到读改写check-then-act这类操作直接上 AtomicInteger、AtomicReference 或者 synchronized别硬用 volatile。4. synchronized 和 volatile 的全面对比与选型逻辑4.1 多维度对比表把这两个关键字放同一个表里看比单独描述更直观对比维度synchronizedvolatile本质基于 Monitor 的互斥锁经过锁升级优化基于内存屏障的读写约束保证原子性是临界区互斥否仅单次读写原子保证可见性是释放锁时刷新主内存是读写强刷新主内存保证有序性是块内统一约束是通过屏障禁止特定重排是否阻塞线程是会阻塞/自旋/挂起不阻塞编译器纯约束作用对象对象、类、代码块、方法仅字段实例字段和静态字段能否修饰 final 字段不能有意义地修饰 final不应修饰 final语义冲突底层指令monitorenter/monitorexitx86 下有 lock cmpxchg 系列x86 下有 lock addl全屏障无锁操作运行时代价有锁竞争时较高几乎可以忽略典型场景复合操作、多个变量一致性、临界区保护状态标志、安全发布、一写多读配置可重入是不涉及锁语义与线程生命周期阻塞中的线程可以被 jstack 看到 BLOCKED不阻塞无状态可见从实现原理层面还有一个重要区分synchronized 的可见性保证是操作边界式的——线程进入锁和退出锁的瞬间工作内存与主内存同步而 volatile 的可见性保证是指令级的——每次读写都同步。前者覆盖范围大、成本高后者频率更高、成本近乎零。4.2 选型时的三条经验准则写了多年并发代码我自己的选择逻辑归纳起来是三条一、能够用 volatile 表达的场景优先用 volatile。判断条件很严格不涉及复合计算、不依赖其它变量的旧值、不要求多个变量变化的原子关联。典型就是开关。二、涉及读改写、check-then-act、或者多个共享变量需要一起变化时用 synchronized 或 Lock。比如一个余额字段和一个交易状态字段必须保证同时更新volatile 做不到。三、追求高性能读的场景考虑原子类和 COW 容器替代。比如用AtomicReferenceArray保护 volatile 数组的元素或者用LongAdder做高并发计数器比 synchronized 和普通 volatile 都更合适。有一个容易搞错的点混合使用。在 synchronized 块里同时依赖 volatile 变量是可以的但要理清锁负责的是原子性volatile 负责的是跨锁的可见冲刷。不要把两者就成同一件事。4.3 从源码看两则的语义差异在 JMM 的语义模型里synchronized 和 volatile 也对应两种不同的抽象前者是互斥 内存屏障的完整模型后者是轻量级的读写约束模型。synchronized 块在 JMM 里遵循锁规则释放锁的操作 happens-before 后续获取同一把锁的操作。volatile 在 JMM 里遵循volatile 变量规则volatile 写 happens-before 后续 volatile 读。两者的差异直接反映在重排序限制的粒度上。synchronized 块内部依然可以被编译器重排只是不能跨过锁边界volatile 则是在变量访问点精确设置了屏障限制的是与 volatile 访问相邻的指令。所以从排序限制上看volatile 其实是更细腻的。5. 实战避坑常见问题与排查技巧5.1 volatile 的三个高频坑坑一volatile 数组的元素不可见不要以为volatile int[] arr之后arr[0]也自动具备 volatile 语义。volatile 修饰的是数组引用本身元素访问是普通的内存读写。如果要在并发下安全更新数组元素使用AtomicIntegerArray、AtomicLongArray或者synchronized包裹。想用 volatile 数组做元素级可见性的同学十有八九会踩这个。坑二long/double 的原子性误解Java 虚拟机规范允许 64 位的 long/double 读写被分为两次 32 位操作来执行所以没有 volatile 修饰时理论上存在一个线程读出高 32 位是旧值、低 32 位是新值的中间态。但现代 HotSpot 在 64 位平台上会将 long/double 的 8 字节对齐到总线宽度绝大多数情况下不会裂开。稳妥起见跨线程共享的 long/double 字段加 volatile 是最简单的防御做法。坑三volatile 不能解决用旧值判断的问题最典型的是if (!flag) flag true这种原子化的布尔判断。即使 flag 修饰为 volatile两个线程同时执行 if 判断时都可能读到一个旧值然后同时通过判断双方都执行了后续代码。这种场景需要AtomicBoolean.compareAndSet(false, true)不是 volatile 的职责。5.2 synchronized 的几个隐蔽坑坑一不要锁 Integer/Long 等包装类型Integer的-128到127之间有缓存池两个线程用同一个字面量锁对象时拿到的可能是同一个对象但一旦发生i操作引用指向的是新对象锁就等于换了一把。比如private Integer count 0; public void increment() { synchronized (count) { // 锁的是 count 本体 count; } }入门时很多人写出这种代码count自增后对象变了其它线程看到的锁对象已经不是同一个完全失去同步效果。正确写法是锁一个单独的 final 对象。坑二注意锁对象逃逸到字符串常量池synchronized (abc)这类写法要避免。字符串字面量在常量池里是全局共享的一旦两个不相关的模块用了同一个字符串字面量锁对象它们会互相阻塞。任何时候用专门的private static final Object LOCK new Object()都比字符串锁安全。坑三偏向锁的延迟时间HotSpot 默认开启了偏向锁延迟JVM 启动后大概 4 秒内创建的对象禁用偏向锁。原因是 JVM 启动初期类加载、GC 和各种内部线程竞争频繁偏向锁在这种场景下收益低。如果你在压测时发现程序启动前几秒 synchronized 耗时明显偏高大概率是踩到这个延迟不是代码写错了。开启了 -XX:UseBiasedLocking 的应用如果要验证锁状态建议在 JVM 稳定运行一段时间后再做 profile否则看到的锁震荡数据会误导你。坑四锁升级和逃逸分析带来的假象JIT 的锁消除让一个局部对象上的 synchronized 被直接优化忽略这在单线程场景下非常快。在 JUnit 单元测试里方法级别的 synchronized 经常不触发真实的锁竞争因为对象不逃逸。如果拿单元测试结果当作并发基准会得出严重偏离现实的数据。5.3 排查工具与观感经验在真实环境里排查 synchronized 和 volatile 相关问题我常用的手段jstack看线程栈如果大量线程处于java.lang.Thread.State: BLOCKED (on object monitor)说明重量级锁竞争激烈需要缩小临界区或者改用读写分离结构jstat和 JFR观察 monitor bias revoked 次数偏向锁撤销过于频繁时说明竞争已超过偏向锁适用区间对 volatile 变量使用-XX:PrintAssembly可以看到生成的机器码里是否有lock前缀指令JMH 做微基准测试测量时开启-XX:-UseBiasedLocking和默认参数各跑一次明确环境对结果的影响我个人在实际开发里维持一个习惯写并发共享变量前先问自己三个问题——这个变量要不要跨线程读要不要复合更新要不要状态依赖逐一回答完用 volatile 还是 synchronized 基本就清晰了。这两个关键字不是竞争者而是分工者。大家写完了先跑起来再用jstack好好看看积累几轮真实数据理解会远比背八股深刻。最后再分享一点真正复杂的高并发系统里面频繁出现的反而是一些细小的逻辑碎片一个 volatile 状态位、一个不可变对象、一份原子引用。synchronized 是兜底的安全网但不是高性能的万能符。设计上优先用不可变类和消息传递思想减少共享冲突比纠结某一行该加哪种锁重要得多。
找工作时几乎每个后端岗位都绕不开这两个关键字synchronized 和 volatile。上一份项目里我做支付状态机的并发控制用 volatile 做状态标识、synchronized 做资源竞争保护踩了不少坑也把 HotSpot 源码层面的行为摸了一遍。这篇文章我把两个核心关键词的实现原理、底层指令、典型场景和容易误解的细节全部讲清楚尤其适合正在应付面试、或者真正想搞懂自己在写什么代码的开发者。先说结论volatile 的本质是内存屏障 禁止重排序synchronized 的本质是监视器锁 对象头状态流转。一个管可见性和有序性一个通吃原子性、可见性、有序性但它们都不是万能的。你会发现越到后面为什么 synchronized 在无竞争时几乎零开销、为什么 volatile 修饰的变量不能替代原子类这些问题答案都藏在硬件层和 JVM 编译器的组合逻辑里。1. 并发问题的底层源头为什么需要这两个关键字1.1 从 CPU 缓存到 Java 内存模型先问一个最基础的问题到底是什么导致了并发环境下程序结果不可控现代 CPU 核心里都有多级缓存L1、L2、L3每个线程跑在一个核上时首先访问的是自己的缓存和寄存器。Java 程序里的共享变量原始数据存在内存主内存里但线程读写变量时并不会每次都直接访问内存而是先把值读到自己的工作内存/寄存器中修改后再刷回内存。这层缓存带来的收益非常大但代价是一个线程修改了变量另一个线程在另一个核上读取到的是自己缓存里的旧值感知不到变化。这就是可见性问题。JMMJava 内存模型为了屏蔽不同硬件结构的差异抽象出一套统一规则它规定了变量都存在于主内存中每个线程有自己的工作内存里面保存了变量的副本线程对变量的所有操作必须在工作内存中进行不能直接操作主内存线程之间不能互相访问对方的工作内存只能通过主内存传递值基于这套规则JMM 用happens-before原则定义了哪些场景下的操作顺序性、可见性是有保证的。synchronized 和 volatile 正是 JMM 实现这些保证的两大工具。1.2 并发安全的三个要素谁管什么我们先建立一个比对框架。并发安全要解决三个问题特性含义synchronizedvolatile原子性一组操作要么都成功要么都失败不可分割能保证进入锁代码块时互斥操作不会交错不能保证只保证单个读写操作本身原子复合操作如 i 依然不安全可见性一个线程修改后其他线程能及时看到新值能保证释放锁时会把工作内存的新值刷新回主内存能保证volatile 写会强制刷主内存读强制从主内存取有序性编译器/CPU 不会对操作进行影响结果的乱序能保证锁内部的代码块在并发视角下有清晰的顺序边界能保证通过内存屏障禁止指令重排序从表里可以看出synchronized 是全通型的volatile 是专项型的。但两者并行不悖因为 synchronized 的实现代价更高、更重量级而很多场景其实只需要可见性和有序性的保证比如状态标志位的更新。2. synchronized 的实现原理从字节码到锁升级2.1 字节码层面的三条指令在 Java 代码里写 synchronized 有两种方式同步代码块和同步方法。同步方法实际上找 javap 反编译会发现它有 ACC_SYNCHRONIZED 标志位而同步代码块编译后生成的是两条指令// 示例代码 public class SyncDemo { private final Object lock new Object(); public void doWork() { synchronized (lock) { System.out.println(in critical area); } } }用 javap -v 反编译之后能看到核心字节码长这样public void doWork(); descriptor: ()V flags: ACC_PUBLIC Code: stack2, locals3, args_size1 0: aload_0 1: getfield #4 Field lock:Ljava/lang/Object; 4: dup 5: astore_1 6: monitorenter 7: getstatic #7 Field System.out:Ljava/io/PrintStream; 10: ldc #13 String in critical area 12: invokevirtual #14 Method PrintStream.println:(Ljava/lang/String;)V 15: aload_1 16: monitorexit ... Exception table: from to target type 7 15 17 any ... 17: aload_1 18: monitorexit 19: aload_0注意看monitorenter和monitorexit。每个对象在 JVM 内部都会关联一个 monitor监视器monitorenter就是尝试获取这个对象的 monitor 所有权monitorexit就是释放。而且编译器会自动生成一条异常路径下的 monitorexit异常表里 from 7 to 15 target 17这就是 synchronized 块抛出异常也会自动释放锁的语言层面保证不需要你手动 catch 写 finally。这里藏着一个小知识点可重入性。同一个线程可以多次对该 monitor 执行 monitorenter每进入一次monitor 里的计数器加 1每执行一次 monitorexit减 1直到计数为 0 才算真正释放。所以你可以在 synchronized 方法 A 里调用同一个锁对象的 synchronized 方法 B不会死锁。2.2 对象头与 Mark Word锁信息存在哪HotSpot 虚拟机里对象在堆内存中的布局分为三部分对象头Header、实例数据Instance Data、对齐填充Padding。对象头又包含 Mark Word 和 Klass Pointer类型指针锁的状态就是记录在 Mark Word 里的。在 64 位 JVM 里一个 Mark Word 是 64 位它的内容会根据锁状态而重用锁状态锁标志位Mark Word 存储内容无锁01对象哈希码、分代年龄、偏向锁标志位为 0偏向锁01线程 ID、epoch、分代年龄、偏向锁标志位为 1轻量级锁00指向栈中锁记录的指针重量级锁10指向 Monitor 对象的指针GC 标记11标记 GC 状态JVM 不在对象外单独维护一个锁标志变量而是直接复用对象头的这 64 位这为零开销加锁和锁升级提供了可能。2.3 synchronized 锁升级的四个阶段这是面试官最爱追问的细节也直接反映了 JVM 对 synchronized 的性能优化历程。JDK 1.6 之后synchronized 不再是一上来就是重量级锁而是根据竞争激烈程度走一套升级路线无锁 → 偏向锁 → 轻量级锁 → 重量级锁阶段一偏向锁在大多数实际场景里一个同步代码块长时间只有同一个线程在访问。偏向锁的设计思路就是让这个线程在第一次获取锁时记录下自己的线程 ID 到 Mark Word 里之后再次进入就不需要任何同步操作直接判断 Mark Word 里的线程 ID 是自己整个加锁过程零 CAS、零原子操作。但这个优化的前提是没有其他线程竞争。一旦有另一个线程尝试获取这把锁偏向模式就要撤销如果持有锁的线程已经退出临界区则把对象头恢复成无锁状态再交给新线程如果持有锁的线程还在临界区则膨胀为轻量级锁。阶段二轻量级锁多个线程交替进入临界区、但不会同时在临界区里长时间阻塞时用偏向锁就不合适了。JVM 会在每个线程的栈帧中创建一个 Lock Record锁记录空间线程尝试通过 CAS 把 Mark Word 替换为指向自己 Lock Record 的指针。如果替换成功说明获取锁成功如果失败说明锁已被占用线程进入自旋Spin不断重试 CAS。自旋的好处是避免了线程切换的系统调用开销坏处是如果持锁线程迟迟不释放自旋的线程会白白消耗 CPU。JDK 1.6 之后引入了适应性自旋JVM 会根据上一次自旋等待成功的次数动态调整自旋时间逻辑就是历史上容易等到就多等一会儿不容易等到就趁早放弃。阶段三重量级锁当存在多个线程真正同时竞争锁、自旋也等不到时轻量级锁会升级为重量级锁。重量级锁的实现依赖操作系统层面的互斥量mutex也就是 JVM 里的 ObjectMonitor。竞争的线程会被挂起进入阻塞状态等持有锁的线程释放后由内核唤醒。线程的挂起、恢复需要由用户态切换到内核态这是同步代价最大的环节。升级过程还有一个细节锁升级是单向的只能无锁→偏向→轻量→重量不能降级。原因也很简单Mark Word 里的信息一旦从线程栈指针变成 Monitor 指针要变回去成本很高而且 JVM 的老年代 GC 也会顺便清理一些多余的锁记录。2.4 为什么现在的 synchronized 优化了很多很多人印象里 synchronized 性能很差这其实是历史包袱。早期的 HotSpot 确实一个 synchronized 就直接进内核互斥线程切换成本极高导致连最简单的计数器加锁都比不上后面 JUC 包里的 Lock。JDK 1.6 的大版本优化偏向锁、轻量级锁、自旋锁、锁消除、锁粗化加入以后情况完全变了锁消除JIT 编译器在运行时通过逃逸分析确定一个锁对象只有当前线程能访问不在其他线程逃逸就会自动去掉这个锁的同步代码。锁粗化如果 JVM 检测到同一个线程反复对同一个对象加锁、释放锁比如循环里每一次都 synchronized但其实整个循环体才是完整临界区会扩大锁的粒度把多次加锁变成一次加锁。所以现代 JVM 下无竞争或低竞争的 synchronized 开销已经非常低和 Lock 的差距很小。真正需要关注性能瓶颈的往往是临界区本身的执行时间而不是加锁语法本身。3. volatile 的实现原理内存屏障与禁止重排序3.1 volatile 变量读写时的内存屏障策略先明确一点volatile 在 Java 字节码层面并没有任何特殊指令javap 反编译看它和一个普通字段读写是一样的。它的特殊之处完全体现在 JIT 编译器生成的机器码以及 JMM 对其施加的约束上。在 JSR-133 规范里对 volatile 变量的读写前后要插入内存屏障volatile 写之前的普通读写不能重排到写之后写之前插入 StoreStore 屏障写之后插入 StoreLoad 屏障volatile 读之后的普通读写不能重排到读之前读之后插入 LoadLoad 屏障和 LoadStore 屏障这些屏障在不同 CPU 架构上的实现不同。x86 处理器有较强的内存序TSO 模型只允许写读重排序而不允许写的写重排序、读的读重排序所以 JVM 在 x86 上对 volatile 写最夸张的做法是直接生成一条lock前缀指令比如lock addl $0, (%rsp)这条指令会把 CPU 的写缓冲器Store Buffer清空让之前所有写操作的结果对其它处理器可见同时让 volatile 写之前的读写不可能穿越到写之后。这就是 volatile 实现可见性和有序性的硬件基石。在实际项目里理解内存屏障不需要把每一条都背下来但你至少要有这个思维模型volatile 写 立即刷新到主内存 一个全屏障volatile 读 从主内存重新拉取 不允许前面指令乱窜。3.2 禁止重排序到底是在防什么重排序有三种来源编译器优化重排、CPU 指令并行重排、内存系统的重排。它们都会导致一个线程中看似有先后顺序的代码在另一个线程观察到的执行顺序是乱的。举一个最经典的案例懒加载单例的双重检查锁DCL。public class Singleton { private static volatile Singleton instance; public static Singleton getInstance() { if (instance null) { // 第一次检查 synchronized (Singleton.class) { if (instance null) { // 第二次检查 instance new Singleton(); } } } return instance; } }instance字段如果不用 volatile会出大问题。new Singleton()在 JVM 里并不是原子的它大概分解为三步分配堆内存调用构造函数初始化Singleton对象将instance引用指向这块内存正常顺序是 1-2-3但 JIT 和 CPU 可能将步骤重排序为 1-3-2。当线程 A 执行完 1-3引用已经指向内存但对象的构造函数还没执行完此时线程 B 进来执行if (instance null)发现不为 null直接 return instance然后访问还没初始化的对象字段就会拿到默认值甚至引发不可预知的错误。加上 volatile 之后volatile 写之前的所有操作包括到步骤 3都不会被重排到写之后保证了对象发布的安全。3.3 volatile 的 happens-before 规则JMM 里有一条专门针对 volatile 的规则对一个 volatile 变量的写操作happens-before 后续对这个变量的任意读操作。这句话的信息量很大。它意味着如果线程 A 写一个 volatile 变量线程 B 随后读到这个变量那么在 A 写之前的其它普通变量的修改结果对 B 也是可见的。volatile 的可见性传播不是只传播这一个变量而是类似一个屏障节点写 volatile 之前的所有写操作都会被冲洗出去读 volatile 之后的所有读操作都会被重新拉取。刚才的 DCL 例子里正因为instance是 volatile线程 A 在 synchronized 块内完成 new 操作并写入 volatile 字段后线程 B 看到 instance 非空时构造期间其它普通字段的赋值也对 B 可见这才是安全的发布。3.4 volatile 做不到什么复合操作的原子性这是 volatile 最大的坑。用它修饰一个 int 字段单次count或count x是原子的因为 Java 规范保证 32 位及以下基本类型的读写是原子的。但count不是单步操作它分解为读旧值、加一、写回三步三步之间其它线程可能插进来于是丢失更新不可避免。所以 volatile 的真实应用场景集中在纯状态标志位volatile boolean running、volatile boolean closed一写多读的配置刷新发布新配置时写把配置对象引用赋值给一个 volatile 字段单例发布DCL双重检查的开关如缓存重建标识遇到读改写check-then-act这类操作直接上 AtomicInteger、AtomicReference 或者 synchronized别硬用 volatile。4. synchronized 和 volatile 的全面对比与选型逻辑4.1 多维度对比表把这两个关键字放同一个表里看比单独描述更直观对比维度synchronizedvolatile本质基于 Monitor 的互斥锁经过锁升级优化基于内存屏障的读写约束保证原子性是临界区互斥否仅单次读写原子保证可见性是释放锁时刷新主内存是读写强刷新主内存保证有序性是块内统一约束是通过屏障禁止特定重排是否阻塞线程是会阻塞/自旋/挂起不阻塞编译器纯约束作用对象对象、类、代码块、方法仅字段实例字段和静态字段能否修饰 final 字段不能有意义地修饰 final不应修饰 final语义冲突底层指令monitorenter/monitorexitx86 下有 lock cmpxchg 系列x86 下有 lock addl全屏障无锁操作运行时代价有锁竞争时较高几乎可以忽略典型场景复合操作、多个变量一致性、临界区保护状态标志、安全发布、一写多读配置可重入是不涉及锁语义与线程生命周期阻塞中的线程可以被 jstack 看到 BLOCKED不阻塞无状态可见从实现原理层面还有一个重要区分synchronized 的可见性保证是操作边界式的——线程进入锁和退出锁的瞬间工作内存与主内存同步而 volatile 的可见性保证是指令级的——每次读写都同步。前者覆盖范围大、成本高后者频率更高、成本近乎零。4.2 选型时的三条经验准则写了多年并发代码我自己的选择逻辑归纳起来是三条一、能够用 volatile 表达的场景优先用 volatile。判断条件很严格不涉及复合计算、不依赖其它变量的旧值、不要求多个变量变化的原子关联。典型就是开关。二、涉及读改写、check-then-act、或者多个共享变量需要一起变化时用 synchronized 或 Lock。比如一个余额字段和一个交易状态字段必须保证同时更新volatile 做不到。三、追求高性能读的场景考虑原子类和 COW 容器替代。比如用AtomicReferenceArray保护 volatile 数组的元素或者用LongAdder做高并发计数器比 synchronized 和普通 volatile 都更合适。有一个容易搞错的点混合使用。在 synchronized 块里同时依赖 volatile 变量是可以的但要理清锁负责的是原子性volatile 负责的是跨锁的可见冲刷。不要把两者就成同一件事。4.3 从源码看两则的语义差异在 JMM 的语义模型里synchronized 和 volatile 也对应两种不同的抽象前者是互斥 内存屏障的完整模型后者是轻量级的读写约束模型。synchronized 块在 JMM 里遵循锁规则释放锁的操作 happens-before 后续获取同一把锁的操作。volatile 在 JMM 里遵循volatile 变量规则volatile 写 happens-before 后续 volatile 读。两者的差异直接反映在重排序限制的粒度上。synchronized 块内部依然可以被编译器重排只是不能跨过锁边界volatile 则是在变量访问点精确设置了屏障限制的是与 volatile 访问相邻的指令。所以从排序限制上看volatile 其实是更细腻的。5. 实战避坑常见问题与排查技巧5.1 volatile 的三个高频坑坑一volatile 数组的元素不可见不要以为volatile int[] arr之后arr[0]也自动具备 volatile 语义。volatile 修饰的是数组引用本身元素访问是普通的内存读写。如果要在并发下安全更新数组元素使用AtomicIntegerArray、AtomicLongArray或者synchronized包裹。想用 volatile 数组做元素级可见性的同学十有八九会踩这个。坑二long/double 的原子性误解Java 虚拟机规范允许 64 位的 long/double 读写被分为两次 32 位操作来执行所以没有 volatile 修饰时理论上存在一个线程读出高 32 位是旧值、低 32 位是新值的中间态。但现代 HotSpot 在 64 位平台上会将 long/double 的 8 字节对齐到总线宽度绝大多数情况下不会裂开。稳妥起见跨线程共享的 long/double 字段加 volatile 是最简单的防御做法。坑三volatile 不能解决用旧值判断的问题最典型的是if (!flag) flag true这种原子化的布尔判断。即使 flag 修饰为 volatile两个线程同时执行 if 判断时都可能读到一个旧值然后同时通过判断双方都执行了后续代码。这种场景需要AtomicBoolean.compareAndSet(false, true)不是 volatile 的职责。5.2 synchronized 的几个隐蔽坑坑一不要锁 Integer/Long 等包装类型Integer的-128到127之间有缓存池两个线程用同一个字面量锁对象时拿到的可能是同一个对象但一旦发生i操作引用指向的是新对象锁就等于换了一把。比如private Integer count 0; public void increment() { synchronized (count) { // 锁的是 count 本体 count; } }入门时很多人写出这种代码count自增后对象变了其它线程看到的锁对象已经不是同一个完全失去同步效果。正确写法是锁一个单独的 final 对象。坑二注意锁对象逃逸到字符串常量池synchronized (abc)这类写法要避免。字符串字面量在常量池里是全局共享的一旦两个不相关的模块用了同一个字符串字面量锁对象它们会互相阻塞。任何时候用专门的private static final Object LOCK new Object()都比字符串锁安全。坑三偏向锁的延迟时间HotSpot 默认开启了偏向锁延迟JVM 启动后大概 4 秒内创建的对象禁用偏向锁。原因是 JVM 启动初期类加载、GC 和各种内部线程竞争频繁偏向锁在这种场景下收益低。如果你在压测时发现程序启动前几秒 synchronized 耗时明显偏高大概率是踩到这个延迟不是代码写错了。开启了 -XX:UseBiasedLocking 的应用如果要验证锁状态建议在 JVM 稳定运行一段时间后再做 profile否则看到的锁震荡数据会误导你。坑四锁升级和逃逸分析带来的假象JIT 的锁消除让一个局部对象上的 synchronized 被直接优化忽略这在单线程场景下非常快。在 JUnit 单元测试里方法级别的 synchronized 经常不触发真实的锁竞争因为对象不逃逸。如果拿单元测试结果当作并发基准会得出严重偏离现实的数据。5.3 排查工具与观感经验在真实环境里排查 synchronized 和 volatile 相关问题我常用的手段jstack看线程栈如果大量线程处于java.lang.Thread.State: BLOCKED (on object monitor)说明重量级锁竞争激烈需要缩小临界区或者改用读写分离结构jstat和 JFR观察 monitor bias revoked 次数偏向锁撤销过于频繁时说明竞争已超过偏向锁适用区间对 volatile 变量使用-XX:PrintAssembly可以看到生成的机器码里是否有lock前缀指令JMH 做微基准测试测量时开启-XX:-UseBiasedLocking和默认参数各跑一次明确环境对结果的影响我个人在实际开发里维持一个习惯写并发共享变量前先问自己三个问题——这个变量要不要跨线程读要不要复合更新要不要状态依赖逐一回答完用 volatile 还是 synchronized 基本就清晰了。这两个关键字不是竞争者而是分工者。大家写完了先跑起来再用jstack好好看看积累几轮真实数据理解会远比背八股深刻。最后再分享一点真正复杂的高并发系统里面频繁出现的反而是一些细小的逻辑碎片一个 volatile 状态位、一个不可变对象、一份原子引用。synchronized 是兜底的安全网但不是高性能的万能符。设计上优先用不可变类和消息传递思想减少共享冲突比纠结某一行该加哪种锁重要得多。
