年初做技术方案评审时我发现很多写了三五年 Java 的同事对 synchronized 的理解还停留在“加锁防止并发写错”的层面。一问到锁升级机制能把偏向锁和轻量级锁完整讲清楚的人屈指可数。作为 Java 面试八股文里性价比最高的一个考点synchronized 和 ReentrantLock 的区分几乎是每家公司必问的项目背后的对象头、Monitor、AQS、锁升级机制牵一发动全身。这篇文章把这条链路彻底拆开讲清楚每个环节的设计动机和踩坑点适合正在准备 Java 面试的人也适合那些日常写并发代码但始终没把锁原理搞透的同行。1. synchronized 的底层到底锁住了什么1.1 从字节码看 synchronized 的本质很多教程上来就讲“synchronized 是重量级锁”“synchronized 会自动释放锁”这些话其实掩盖了最核心的问题JVM 究竟是怎么知道一个锁被谁持有的写一段最简单的代码然后执行 javap -v 看字节码一切就清晰了。public class SyncDemo { private Object lock new Object(); public void test() { synchronized (lock) { System.out.println(locked); } } }反编译后能看到 test() 方法里出现了两条关键指令monitorenter 和 monitorexit分别对应进入临界区和退出临界区。注意编译器会生成两个 monitorexit——正常路径一个异常路径一个确保代码抛出异常时锁也能释放。这是 synchronized 比手动 Lock 更安全的最根本原因JVM 级别兜底。而如果直接在方法声明上加 synchronized字节码里看不到这两条指令而是会多出一个 ACC_SYNCHRONIZED 标志。JVM 调用方法时检查到这个标志就知道这是一个同步方法从而隐式地完成锁的获取与释放。两种方式的锁目标本质上是同一个东西——调用该方法或进入该代码块的实例对象也就是我们常说的“锁对象”。1.2 对象头里的 Mark Word 才是真正被改写的“锁位”要理解 synchronized 锁的对象是实例就必须看对象在 JVM 堆内存里的布局。一个 Java 对象由三部分构成对象头、实例数据、对齐填充。普通无锁对象的对象头里Mark Word 占 8 字节Klass Pointer 占 4 字节开启压缩指针时数组则会再多一个长度字段。关键的 8 字节 Mark Word 存的不是单纯一个“锁标记”它是一块复用区。JVM 根据对象当前的锁状态把这块区域的 bit 位重新解释成不同含义锁状态Mark Word 关键位含义无锁hashcode GC age biased_lock0 lock01偏向锁线程ID epoch GC age biased_lock1 lock01轻量级锁指向栈中锁记录的指针 lock00重量级锁指向 ObjectMonitor 的指针 lock10GC 标记空 lock11注意观察无锁和偏向锁的锁标志位都是 01区别只在前面的 biased_lock 位。这个设计的意图很明确偏向锁本质上是“假装没竞争”同一线程反复进入同步块时通过 CAS 把线程 ID 刷到 Mark Word 里后续再来就直接判断线程 ID 是否相同相同就放行不再做任何同步。面试里经常有人背“偏向锁会记录线程 ID”但说不出记录在哪里。答案就是这个 Mark Word。真正被 CAS 改写的不是 synchronized 语句本身而是锁对象头部的那 8 个字节。理解这一点后面所有锁升级的逻辑都能串起来。2. 锁升级机制从无锁到重量级的完整链条2.1 为什么要设计多级锁直接全上重量级不行吗在 JDK 1.6 之前synchronized 只有重量级锁这一种形态它的底层依赖操作系统的互斥量 Mutex Lock。线程获取不到锁时会被挂起从用户态切到内核态这个切换涉及完整的寄存器保存、恢复和调度器介入开销非常大。实测下来一次无竞争锁获取在早期的 JVM 上也需要微秒级耗时而有竞争时的阻塞唤醒则可能达到几十微秒甚至更高。但现实业务里的锁竞争模式并不是想象中的“所有线程都在抢同一把锁”。绝大多数情况下一个同步块只被同一个线程反复进入比如我们常用的无状态工具类、StringBuilder 的 append 方法。永远只有一个线程访问的同步代码块为什么要走内核态挂起唤醒JVM 的锁升级机制本质就是按竞争激烈程度给锁分了四个等级能省则省实在不行才动用操作系统级别的重量级锁。2.2 偏向锁只有一条线程反复进场的场景偏向锁解决的是“单人重复访问”的场景它的设计假设是这个锁对象大概率只被一个线程使用。线程第一次进入时通过 CAS 把自身线程 ID 写入 Mark Wordbiased_lock 位改为 1。之后这个线程再次进入同步块时只需要比较线程 ID 是否一致不需要 CAS不需要读内存屏障代价只有一个分支判断。偏向锁有个经常被忽略的细节JVM 启动后默认有 4 秒的偏向锁延迟期可用 -XX:BiasedLockingStartupDelay0 关闭延迟。因为 JVM 启动初期存在大量多线程场景JIT 编译、类加载此时竞争比较频繁延迟开启偏向锁反而能提升性能。如果第二条线程来竞争偏向锁会被撤销revoke。撤销流程很重——需要等待一个安全点SafePoint此时所有工作线程都会暂停在字节码边界。JVM 检查 Mark Word 里的持有线程是否还活着如果持有线程已退出同步块甚至已消亡就直接把对象头改成无锁状态否则升级为轻量级锁或重量级锁。这也是很多高并发项目添加 -XX:-UseBiasedLocking 参数的原因如果同步块竞争长期存在偏向锁反复撤销带来的 STW 停顿比绕过偏向锁直接走轻量级锁还要慢。2.3 轻量级锁第二个线程来了但尽量别阻塞轻量级锁针对的是“少量线程交替执行”的场景。偏向锁被撤销后如果对象头变成无锁状态新线程并不会立刻升级到重量级锁而是尝试通过 CAS 将 Mark Word 中的内容复制到自己线程栈的 Lock Record锁记录里然后修改对象头的锁标志位为 00并存储一个指向 Lock Record 的指针。这一步成功轻量级锁就建立起来了。如果 CAS 失败说明有多个线程在竞争JVM 会让抢不到锁的线程做自旋Spin也就是用一小段 CPU 时间不断尝试获取锁避免立刻被挂起。JDK 1.6 之后引入自适应自旋JVM 会根据同一个锁上次自旋的成功率动态调整这次自旋的次数不能简单理解为固定自旋 10 次。轻量级锁的退出也很有意思退出时仍然通过 CAS 把栈中 Lock Record 里的原始 Mark Word 写回对象头。如果写回成功说明期间没有其他线程竞争如果写回失败说明竞争升级了需要膨胀成重量级锁并且唤醒被挂起的线程。2.4 重量级锁竞争激烈时的托底方案当一个线程自旋等待超过阈值仍然拿不到锁轻量级锁就会膨胀为重量级锁。此时 Mark Word 里存储的指针指向一个 C 层面的 ObjectMonitor 对象这个对象维护着一个阻塞队列和所有线程的 wait 集合。锁的获取、释放、notify、wait 全部依赖操作系统 Mutex Lock 来完成。重量级锁最大的成本不在锁本身而在于线程调度。抢不到锁的线程会被操作系统真正地挂起进入 BLOCKED 状态等锁释放后系统再把它唤醒。一次挂起唤醒的往返可能消耗几十万条 CPU 指令这在高并发低临界区的场景下是致命的。值得注意的是锁升级是不可逆的。从偏向锁升级到轻量级再从轻量级升级到重量级后面的路径永远回不到前两档。JVM 的设计哲学是“宁可让竞争升级不在降级上做文章”这保证了公平性和可预测性但也意味着业务上遇到了错误使用性能问题只会越来越严重。2.5 锁升级的几个关键结论整理一下锁升级这条链路的触发条件和代价我用一张表汇总锁级别面向场景获取开销竞争时的处理无锁单线程访问极低进入偏向锁或轻量级锁偏向锁单线程反复进入线程ID对比撤销需要安全点轻量级锁少量线程交替/短自旋CAS 自旋自旋失败 → 膨胀重量级锁高竞争CAS 内核挂起阻塞队列等待关于锁升级面试中还有一个高频追问什么样的代码会触发锁消除和锁粗化锁消除是指 JIT 编译器检测到同步块内的对象不会被其他线程共享时直接把 synchronized 去掉典型场景是栈上分配的对象。锁粗化则相反把多个相邻同步块合并成一个更大的同步块减少反复加锁解锁的开销。这两个都属于 JVM 编译优化跟锁升级是两个维度的东西面试时能主动提出来往往能超出面试官的预期。3. ReentrantLock 和藏在背后的 AQS3.1 基础用法回顾ReentrantLock 是并发包 JUC 里最常用的显式锁API 上比 synchronized 丰富不少Lock lock new ReentrantLock(); try { lock.lock(); // do something } finally { lock.unlock(); }注意 finally 中 release 是必须的因为 ReentrantLock 不像 synchronized 那样由字节码自动管理释放。它提供了 tryLock()、lockInterruptibly()、Condition 等增强能力这些在面试中也是必问项。但面试官通常不会只停留在 API 层面他们会继续追问ReentrantLock 的可重入计数、公平性、条件队列都是怎么实现的答案几乎都指向同一个类——AbstractQueuedSynchronizer也就是 AQS。3.2 AQS 核心state 与 CLH 队列AQS 是一个并发框架它的核心理念是用 volatile int state 表示同步状态用双向链表队列CLH 变体管理等待线程。state 的语义由子类决定ReentrantLock 里 state 表示“当前持有锁的线程的重入次数”初始为 0重入一次加 1释放一次减 1减到 0 才真正释放锁。当一个线程调用 lock() 时AQS 的非公平锁实现会先尝试 CAS 把 state 从 0 修改为 1。修改成功设置当前线程为独占线程失败则走 acquire 流程tryAcquire 再次尝试可重入判断在此发生→ addWaiter 把当前线程包装成 Node 加入等待队列尾部 → acquireQueued 循环自旋检查前驱节点是否为头节点如果是就再次尝试获取锁否则检查中断标记并挂起。这里有个很多初学者搞不清楚的点AQS 等待队列里的线程不会一上来就挂起而是在队列里先“转圈”观察几次这在低竞争下能规避不必要的线程切换。真正要挂起时调用 LockSupport.park挂起状态下的线程只能靠前驱节点释放锁后的 unpark 唤醒。3.3 公平锁和非公平锁的实现差异ReentrantLock 构造函数里传入 true 创建公平锁false 或默认则创建非公平锁。两者的差异只有一个方法的实现公平锁的 tryAcquire 先调用 hasQueuedPredecessors()如果等待队列里已经有其他线程在排队直接返回 false自己乖乖去排队非公平锁则不管队列状态上来先 CAS 抢一下 state抢不到才去排队。非公平锁为什么在很多场景下吞吐量反而更高因为它允许新线程“插队”减少了线程挂起和唤醒的频次让 CPU 利用率更饱和。而公平锁几乎每来一个新线程就要 park/unpark 一次开销更大。实际业务里除非你明确需要“先到先得”的语义否则默认的非公平锁通常是最优解。公平锁的设计目的是防止饥饿但代价是吞吐量肉眼可见地下降。3.4 Condition 条件变量是增强版 wait/notifysynchronized 搭配的是 Object 的 wait/notify/notifyAll这些方法必须持有当前对象的 Monitor 才能调用。ReentrantLock 则提供了 Condition 接口通过 lock.newCondition() 创建条件队列调用 condition.await() 释放锁并等待调用 signal/signalAll 唤醒某个或所有等待线程。Condition 相比 wait/notify 最大的优势是可以有多条等待队列。比如一个容量有限的队列可以用两个 Condition 分别管理“队列不为空”和“队列不满”两个条件分别唤醒生产者或消费者减少无效唤醒。而 Object 的 wait/notify 只有一条等待队列notifyAll 会打断所有等待线程需要它们重新竞争条件性能上天然吃亏。4. synchronized 与 ReentrantLock 的硬核对比4.1 功能维度对比表维度synchronizedReentrantLock锁释放JVM 自动释放含异常路径必须手动 unlockfinally 中可重入支持支持state 计数可中断等待不支持lockInterruptibly() 支持超时等待不支持tryLock(timeout) 支持公平性非公平默认非公平可指定公平多条件队列wait/notify 单队列可建立多个 Condition底层实现对象头 Mark Word ObjectMonitorAQS LockSupport是否偏向锁JDK6 后有偏向锁优化无锁升级机制4.2 性能之争JDK6 之后答案变了早年很多人认为 synchronized 比 ReentrantLock 慢这个结论在 JDK 1.6 加入偏向锁、轻量级锁、适应性自旋后已经不再成立。在两个锁都处于热状态且无竞争时synchronized 在偏向锁层面只有一次线程 ID 比较ReentrantLock 则需要 CAS state 写 volatile开销并不比 synchronized 低。而在高竞争场景下两者的性能差异主要取决于临界区大小和自旋策略而不是锁本身。性能不是选择锁的最关键点了。真正的选择依据是功能需求需要超时、需要可中断、需要多路 Condition或者希望显式控制公平性就选 ReentrantLock不需要这些扩展能力优先用 synchronized代码更干净而且永远不用担心忘释放锁。4.3 选型建议的七条参考同步块极短且属于高频热点优先 synchronized配合 JIT 优化锁粗化、锁消除通常收益更好。需要实现“最多等待多少毫秒”这样的业务超时语义选 tryLock(timeout)。需要响应线程中断比如任务取消场景里线程被阻塞在锁上选 lockInterruptibly。需要多个条件队列分别唤醒生产者/消费者选 Condition。希望等待公平性严格、避免饥饿用公平锁。临界区只被单个线程访问用 synchronized 享受偏向锁。团队代码规范要求最简实现无扩展需求synchronized 永远最稳。5. 面试官连环问锁相关的高频陷阱5.1 wait/notify 必须在 synchronized 块里为什么这个题考的是对 Monitor 的掌控的理解。wait() 的语义是“释放当前锁阻塞当前线程等待被唤醒”。Java 强制要求 wait/notify 必须持有 Monitor 才能调用本质是为了避免一个经典问题如果线程 A 在调用 wait() 之前另一个线程 B 恰好调用了 notify()A 再进入 wait 就会永远错过通知发生死等。只有把 wait/notify 放在同步块里通过锁的互斥性保证“判断条件”和“挂起等待”是原子操作才能规避竞态条件。对应地ReentrantLock 里这个功能由 Condition.await/signal 承担同样要求先持有对应的 Lock否则会抛出 IllegalMonitorStateException。5.2 锁对象的选择字符串常量池是最隐蔽的坑我见过线上一个事故有同学用 String 作为锁对象比如 synchronized(str)以为锁的是“自己的 key”结果多个线程拿到的 String 指向常量池里的同一个字面量锁直接变成了全局锁把本应隔离的业务串在一起吞吐量掉到原来的十分之一以下。排查用了很久最后 jstack 里清晰的 BLOCKED 状态才暴露问题。正确的姿势是锁一个明确的、持有唯一引用的对象。如果要按业务维度加锁用 private final Object lock new Object() 这种每实例独占的锁对象或者用 ConcurrentHashMap 按 key 维度隔离锁。5.3 synchronized 的可重入是怎么实现的可重入的意思是同一个线程可以多次获取同一把锁。synchronized 里JVM 在执行 monitorenter 时会检查锁对象的 Monitor 持有者是不是当前线程如果是就把递归计数加一monitorexit 时计数减一减少到零才真正释放锁。ReentrantLock 里则是由 AQS 的 state 负责计数。两个方案本质一致都是“持有者 计数器”模型。5.4 快问快答高频十二题问题一句话答案synchronized 锁的是方法还是对象锁的是调用该方法的对象静态方法是 Class 对象锁升级结束后能降级吗不能JVM 没有锁降级路径偏向锁撤销可以避免吗可以用 -XX:-UseBiasedLocking 关闭偏向锁synchronized 支持超时吗不支持只能通过 Lock 的 tryLockwait/notify 需要释放锁吗wait 会释放锁notify 不会await/signal 需要在 lock 内吗需要否则抛 IllegalMonitorStateExceptionnotifyAll 会抬升所有等待线程吗是的但它们仍需重新竞争锁非公平锁为什么会“插队”tryAcquire 先 CAS 竞争不检查队列ReentrantLock 公平吗默认非公平可构造公平锁LockSupport.park 与 Thread.yield 有区别吗有park 可以精确唤醒指定线程AQS 等待队列是 FIFO 的吗入队是 FIFO获取锁优先级看公平策略为什么 Lock 必须在 finally 里 unlock防止临界区抛异常导致锁永久未释放如果你在面试中被要求口述 AQS 的 acquire 流程推荐按这个顺序回答tryAcquire 快速尝试 → addWaiter 入队 → acquireQueued 循环检查前驱 → 失败 park被唤醒后重新循环 → 中断性检查自行处理。能把这个链路说顺面试官基本会直接判定你对 JUC 底层有理解。这类八股题很考验“概念关联能力”。能主动把偏向锁的 STW 撤销、轻量级锁的自旋成本、重量级锁的内核切换三者串联起来讲比单点背诵强得多。面试官追问“那你们线上用的哪种锁”时能把参数调优经验说出来比如偏向锁延迟、自旋次数、关注 / 排除 Monitor 竞争才是真正的加分项。6. 实战经验我在生产环境踩过的锁的坑6.1 案例一String 锁对象引发的全局串行之前团队做了一个按商户维度做串行处理的模块第一版代码如下private void processByMerchant(String merchantId) { synchronized (merchantId.intern()) { // 处理该商户的订单任务 } }看起来按商户隔离实际业务量一大就出问题商家 A 和商家 B 的订单互相阻塞线程池打满任务堆积告警。问题本质是 intern() 让所有字符串都跑去常量池不同商家 ID 恰好命中了同一批字符串实体。这个案例给我们的教训是永远不要在代码里拿业务字符串变量直接作为锁对象如果确实想按业务维度做锁应该维护一个 Key 到锁对象的映射并且注意锁对象的存活周期。6.2 案例二轻量级锁升级后的卡顿另一个项目在 QPS 高峰期出现了莫名的线程 BLOCKED 比例上升jstack 里大量线程卡在重量级锁的 ObjectMonitor 等待队列上。分析后发现锁的临界区里有一段耗时的数据库查询一个线程持锁时间拉长后续线程不断自旋自旋到上限后批量挂起触发锁升级整个模块从低延迟模式切进了“排队模式”。修复策略很明确把数据库查询移出临界区锁内只保留内存状态的修改同时关掉偏向锁-XX:-UseBiasedLocking因为当时场景是典型的多线程高竞争偏向锁只会带来额外的撤销开销。调整后 BLOCKED 比例下降了一个数量级。这类问题在监控上最容易定位的方向就是“持锁时间 平均响应时间数倍”。6.3 案例三多路条件唤醒用 synchronized 很难写一个典型的生产者-消费者模型队列容量有限业务要求“满时挂起生产者空时挂起消费者”并且希望“新数据到达时只唤醒消费者不惊动生产者”。用 synchronized wait/notifyAll 很难做到精准唤醒只能 notifyAll所有等待线程都被唤醒再各自判断条件白白消耗 CPU。换成 ReentrantLock 后两条 Condition 分管理两种等待notFull 由生产者 await完成 put 后 signal notEmptynotEmpty 由消费者 await完成 take 后 signal notFull。唤醒是精确的不需要无谓的竞争。这段代码后来成为团队里 Condition 用法的标准示例。6.4 锁问题的排查工具整理遇到锁问题不要凭感觉猜。先上 jstack 拉线程快照重点看 java.lang.Thread.State 是 BLOCKED、WAITING 还是 TIMED_WAITING然后找“waiting to lock”后面的锁对象地址。再看锁对象的 Monitor Owner 是谁、持锁线程当前在干什么。如果用的是 ReentrantLockjstack 会显示 parking to wait for ...AQS 节点排查逻辑一样只是锁对象换成了 AbstractQueuedSynchronizer$ConditionObject 或者 Node。生产环境埋点建议同步关注指标等待锁的平均时长、持锁平均时长、锁竞争失败次数。JFRJava Flight Recorder里能直接看到 Lock Instances 和 Lock 阻塞统计不需要额外埋点代码。7. 几个容易被忽略的细节锁这块的内容面试里经常被追到更细的层面。比如偏向锁撤销为什么需要 SafePoint因为 JVM 需要保证撤销过程中不会有线程正在执行临界区代码只有全局暂停才能让所有线程都停在安全点上然后安全地改写对象头。又比如轻量级锁的 Lock Record 为什么在线程栈里因为它天然跟随线程栈存在不需要额外堆分配退出时直接写回 Mark Word 即可设计上就是尽量“轻”。另外一个常被忽视的话题是 volatile 和 synchronized 的关系。volatile 仅保证可见性和有序性不保证原子性synchronized 三性全包。两者组合使用的典型场景是双重检查锁的懒加载单例模式其中 volatile 是为了禁止指令重排防止拿到未初始化完成的对象引用。理解锁不能只盯着“互斥”要把它放到 JMMJava 内存模型的大图里去理解锁的释放建立 happens-before 关系解锁前对变量的修改在后续获取同一把锁的线程中必然可见。这是 synchronized 保证线程安全最底层的理论依据。从我个人经验来说每次面试别人问锁机制我从不要求对方背结论只让他讲一个自己实际调优过锁的场景。能讲出“当时为什么这么选”“升级后发生了什么”“用了什么排查手段”的人比把八股倒背如流的人好用得多。对看这篇文章的读者我建议你也做同样的事把你项目里的 synchronized 或 Lock 都梳理一遍拿 jstack 实测几次比纯看书管用得多。