深入剖析synchronized：从对象头到锁升级，彻底理解Java并发锁机制-北京尧图网络

在很多人的印象里synchronized就是 Java 里一把“重锁”性能差、不灵活能用Lock就尽量别碰它。但如果你现在还在用这个理由在代码里刻意回避synchronized那大概率是对它的认知还停留在 JDK 1.5 时代。实际上从 JDK 1.6 开始HotSpot 虚拟机对synchronized做了多轮重要优化引入了偏向锁、轻量级锁、锁升级等一系列机制现代 Java 里的synchronized早已不是当年的“重量级选手”。这篇文章我打算从底层彻底拆一遍synchronized锁机制。不空谈概念而是把对象头、Monitor、锁升级路径、内存语义这些核心知识点串起来顺便把面试里常见的几个刁钻问题和日常开发中容易踩的坑一起说清楚。无论你是准备面试、复习八股文还是想真正弄懂 Java 并发底层原理这篇都值得花十几分钟读完。1. synchronized 锁的“锁”到底是什么——对象头里的秘密很多初学者学synchronized时记住了“锁的是对象”但对“锁”这个抽象概念落在 JVM 里到底长什么样一无所知。这是理解整个synchronized机制的第一道门槛。1.1 一切要从 Java 对象的内存布局说起在 HotSpot 虚拟机中一个 Java 对象在堆内存里的布局分为三块对象头Object Header、实例数据Instance Data和对齐填充Padding。其中对象头是今天的主角。它主要由两部分组成Mark Word存储对象自身的运行时数据比如哈希码、GC 分代年龄、锁状态标志、偏向线程 ID 等。这也是synchronized锁机制最核心的“信息存储区”。Klass Pointer类型指针指向方法区的类元数据JVM 通过它来确定这个对象属于哪个类。注意如果对象是数组对象头里还会多一块记录数组长度的数据。Mark Word是一个 32 位或 64 位的位字段取决于 JVM 是 32 位还是 64 位。它本身是一块复用的内存区域会根据对象的状态存储不同的信息。这就像一块白板对象处于不同状态时白板上写的内容完全不同。1.2 Mark Word 各状态位的变化以 64 位 JVM 为例Mark Word是 64 位其中最低的 2 位或 3 位用于标识锁状态。锁状态锁标志位Mark Word 存储内容无锁01对象哈希码、分代年龄偏向锁101偏向线程 ID、偏向时间戳、分代年龄轻量级锁00指向栈中锁记录的指针重量级锁10指向 Monitor监视器锁的指针GC 标记11空不存储锁信息这就是一个非常重要的结论synchronized锁的信息就存在对象的 Mark Word 里。所以“锁一个对象”这件事底层做的其实是对对象头 Mark Word 的修改和状态切换。理解了这一点后续所有内容都会变得顺畅。比如为什么synchronized可以锁任意对象因为任何对象都有对象头都有 Mark Word也就都能承载锁状态。为什么synchronized是可重入的因为 Mark Word 里可以记录持有锁的线程信息偏向线程 ID或 Monitor 里的 owner同一个线程再次进入时只要判断持有者是自己就直接放行。1.3 锁和对象的关系一个生活化类比你可以把对象头里的 Mark Word 想象成酒店房间门口的一块状态牌。无锁状态就是“空闲”牌偏向锁是房间被某位客人长期预定牌上写着客人的名字显示“VIP 专属”轻量级锁是“客人在房间内正在使用请勿打扰”重量级锁则升级成酒店前台统一管理所有访客都要去前台排队登记才能进入房间。synchronized的一切底层逻辑都是围绕这块“状态牌”的切换来展开的。弄清楚这个基础接下来看 Monitor 和锁升级就会轻松很多。2. 从字节码到 Monitorsynchronized 的加锁路径拆解上一节说了锁状态存储在对象头里那synchronized代码块编译之后到底长什么样子它的执行路径是怎么走的这一节我带你把这条链路完整看一遍。2.1 字节码层面的两个指令monitorenter 和 monitorexit写一段最简单的代码public class SyncDemo { private final Object lock new Object(); public void test() { synchronized (lock) { System.out.println(do something); } } }用javap -verbose反编译test()方法你会看到关键字节码3: monitorenter 4: getstatic // java/lang/System.out ... 11: monitorexit ... 14: monitorexit // 异常路径上的退出指令你没看错一个synchronized代码块对应了monitorenter和monitorexit两条指令而且会有两条monitorexit。第一条是正常执行完同步代码块后退出第二条是方法内出现异常时通过异常表跳转执行保证锁一定会被释放。这背后的逻辑用大白话说就是每个对象在 JVM 内部都关联一个 Monitor 对象monitorenter尝试获取 Monitor 的所有权获取成功则计数器 1这就是可重入的实现基础monitorexit则把计数器 -1降到 0 代表释放锁。2.2 Monitorsynchronized 的核心调度器Monitor监视器锁是操作系统的管程模型在 JVM 里的具体实现。每一个被synchronized锁住的对象最终都会关联到一个ObjectMonitor对象HotSpot 源码里叫ObjectMonitor。ObjectMonitor内部有几个关键字段_owner记录持有锁的线程。_WaitSet存放调用了wait()方法而进入等待状态的线程队列。_EntryList存放阻塞等待锁的线程队列。_recursions记录重入次数。线程获取锁的过程简单来说是线程执行到monitorenter检查_owner是否为空。如果为空尝试通过 CAS 把_owner设为自己成功则抢锁成功。如果_owner已经是自己_recursions1表示重入了一次。如果_owner是别的线程当前线程进入_EntryList阻塞等待直到锁被释放。wait()和notify()的底层也和 Monitor 直接相关。调用wait()时线程会释放 Monitor 的所有权从_owner移到_WaitSet调用notify()时_WaitSet中的线程会回到_EntryList重新竞争锁。提示synchronized方法其实并不会显式用到monitorenter和monitorexit而是在方法常量池的ACC_SYNCHRONIZED标志位里做文章。JVM 根据这个标志判断是否需要先获取 Monitor 再执行方法体。两者在最终结果上是一致的只是编码位置不同。2.3 为什么需要“两次 monitorexit”我看到过很多刚接触字节码的同学对字节码里出现两条monitorexit感到很困惑。其实原因很简单JVM 必须保证锁在异常情况下也能释放否则一旦同步代码块里抛异常其他线程就会永远拿不到锁。编译器会自动在异常处理器路径上插入一条monitorexit配合异常表Exception Table实现锁的安全释放。这种设计体现了语言层面和 JVM 层面的严谨性——不管代码正常执行还是异常退出锁的释放路径都是确定的。这一点也提醒我们一件事synchronized的锁释放是 JVM 自动保证的不需要像ReentrantLock那样在finally里手动unlock()。3. 锁升级为什么现在的 synchronized 不再那么“重”了很多人对synchronized最大的误解就是它还停留在“一上来就向操作系统申请互斥量”的阶段。实际上JDK 1.6 以后HotSpot 开发者引入了锁升级机制让锁的状态可以随竞争激烈程度动态变化。3.1 无锁 → 偏向锁 → 轻量级锁 → 重量级锁JVM 的锁升级路径是单向的、不可逆的无锁 → 偏向锁 → 轻量级锁 → 重量级锁。我一个个说。无锁对象刚创建Mark Word 里存的是哈希码和分代年龄没有任何线程尝试获取锁。这时就是普通对象没有锁竞争的概念。偏向锁当第一个线程访问同步代码块时JVM 会在 Mark Word 里记录该线程的 ID通过 CAS 操作。之后再进入时只需要检查 Mark Word 里的偏向线程 ID 是否是自己。如果是直接进入不需要任何 CAS 或系统调用。这个设计的出发点是大多数场景下一段同步代码其实只有同一个线程在反复执行让同一个线程反复获取锁的成本被降到了极低。轻量级锁当第二条线程尝试获取偏向锁时说明存在竞争了。偏向锁会被撤销Revoke Bias升级为轻量级锁。获取锁的线程会在自己的栈帧中创建锁记录Lock Record通过 CAS 把对象头 Mark Word 替换为指向锁记录的指针。如果 CAS 成功表示拿到锁失败则自旋重试。重量级锁当 CAS 竞争非常激烈自旋超过一定次数或自旋线程数超过阈值仍未能拿到锁轻量级锁就会膨胀Inflate为重量级锁也就是进入ObjectMonitor的阻塞等待流程。重量级锁的获取和释放依赖操作系统底层的 Mutex线程会从用户态切换到内核态这才是真正“重”的地方。3.2 锁升级过程中的关键细节锁升级不是一句“竞争激烈就升级”那么简单里面有非常多值得深入理解的细节。先说偏向锁的撤销时机。偏向锁撤销并不是由持有锁的线程触发的而是由其他线程尝试获取偏向锁时触发的。触发后JVM 需要等待一个全局安全点Safe Point然后暂停持有偏向锁的线程判断该线程是否还活着。如果线程已经不活跃了直接把对象头置为无锁状态如果还活跃则尝试把偏向锁升级为轻量级锁。再说偏向锁的批量重偏向和批量撤销。如果一个类的对象频繁被不同的线程获取偏向锁每次都要撤销偏向锁开销会很大。JVM 引入了“批量重偏向”机制当同一个类的撤销偏向锁次数达到阈值默认 20时JVM 会认为偏向锁对于这个类的对象没有意义后续新创建的对象直接不再启用偏向锁如果达到阈值默认 40则会触发“批量撤销”把这个类所有对象的偏向锁全部撤销。3.3 偏向锁为什么在 JDK 15 以后被标记为废弃这里有个有趣的细节从 JDK 15 开始偏向锁被默认禁用并且在后续版本中被正式标记为废弃。原因是现代应用的线程竞争通常比过去更激烈加上偏向锁撤销需要安全点停顿这个停顿带来的延迟在某些场景下比省下来的获取锁开销还要大。也就是说JVM 团队自己都在根据硬件和应用场景的变化调整锁策略。你在学习八股文的时候如果只背“JDK 1.6 引入了偏向锁优化”而不关注版本演进面试时反而会被问到哑口无言。我自己在实际调优中的体感是偏向锁在低竞争、单线程反复进入同步块的场景下确实能省一点开销但优势在现代 JVM 的锁消除、锁粗化面前已经不明显了。普通业务代码根本不需要手动干预偏向锁的启停。3.4 锁消除和锁粗化编译器层面的两个隐藏优化锁升级是运行时的优化而锁消除和锁粗化主要发生在 JIT 编译阶段。锁消除是指 JIT 编译器通过逃逸分析发现某个锁对象根本不会被其他线程访问到于是直接把synchronized相关的加锁代码去除。比如在方法内部创建一个局部对象作为锁这个对象无法逃逸出方法加锁就是多余的。开启逃逸分析后JVM 会把这层锁直接“抹掉”。锁粗化则是相反方向的优化当 JVM 检测到同一把锁在短时间内被反复加锁、解锁而中间并没有其他线程竞争就会把多个连续的加锁解锁操作合并成一个范围更大的锁。比如在循环里反复对同一个对象加锁解锁JIT 会把锁粗化到循环外面减少锁操作次数。这两类优化都属于编译期的“智能行为”不需要开发者在代码里做任何事。但了解它们能帮你理解一个现象表面上看代码加了synchronized但实际运行时可能根本没有真的上锁。这也是为什么做并发性能测试时跑出来的结果经常和理论分析不一致——因为 JVM 的优化很多时候在你没意识到的情况下替你做了取舍。4. synchronized 的内存语义它不只是“互斥”聊完了锁的实现机制还有一个非常重要的维度容易被忽略那就是synchronized在 Java 内存模型JMM中的语义。面试中问“synchronized 能保证什么”很多人的回答只有“原子性”和“互斥性”把最重要的“可见性”和“有序性”漏掉了。4.1 加锁解锁与 happens-before 规则JMM 中定义了一条与synchronized直接相关的happens-before规则监视器锁规则对一个锁的解锁 happens-before 于后续对这个锁的加锁。这句话的意思是如果线程 A 先释放了锁退出synchronized代码块线程 B 后获取了同一把锁进入同一个synchronized代码块那么线程 A 在释放锁之前做的所有写操作对线程 B 都是可见的。也就是说synchronized不仅仅让代码块互斥执行还保证了数据在不同线程之间的传递。A 线程在同步块里修改的所有变量B 线程获取同一把锁后一定能看到最新值。这是通过底层的内存屏障实现的加锁时会执行读屏障Load Barrier解锁时会执行写屏障Store Barrier确保修改不会只停留在 CPU 缓存或寄存器里。4.2 为什么说“synchronized 能保证原子性”原子性保证的是“一个操作或多个操作要么全部执行且不被中断要么全部不执行”。synchronized保证原子性的方式是靠互斥——同步代码块同一时刻只能有一个线程执行其他线程无法插进来代码块内的多个操作自然也就不会被打断。但要注意一点synchronized的原子性是“粗粒度”的。它保证的是整个同步块所有操作的原子性而不是块内每一个独立操作的原子性。如果你在同步块外做了两步各自独立的操作这两步依然不是原子的。举个例子public class Counter { private int count 0; public void add() { synchronized (this) { count; } } }这里count本身包含“读取、加 1、写回”三步但在同步块内部执行时三步是一气呵成、不会被其他线程打断的所以最终结果是正确的。如果把count放到同步块外面即使单独看这一行代码也可能被并发线程交错执行导致结果错误。4.3 有序性与“锁内重排序”的边界synchronized也保证了有序性。在同步代码块内部代码的执行顺序在观察者看来是有序的——这里说的有序指的是单线程内的指令重排序不影响程序语义。JVM 允许在不改变单线程语义的前提下对指令进行重排序但这种重排序在多线程环境下可能产生问题。synchronized通过内存屏障限制了锁内代码的重排序范围锁内的读写操作不会跑到锁外面锁外的读写操作也不会进入锁内。举个例子双重检查锁Double-Checked Locking的问题本质上就出在指令重排序上。如果没有volatile修饰单例实例instance new Singleton()里的“分配内存、初始化对象、赋值引用”三步骤可能会被重排序成“分配内存、赋值引用、初始化对象”另一个线程在线程执行到“赋值引用”但“还没初始化完成”时读到非空引用拿到一个半初始化状态的对象。而给实例变量加上volatile后通过写屏障禁止了这种重排序。这里要强调的是synchronized保证了锁内的有序性但它本身并不能解决所有重排序问题尤其是锁外发生的读写。这也是为什么volatile和synchronized经常需要配合使用而不是互相替代。4.4 可见性的另一个观察角度很多人不理解“可见性”到底在解决什么问题。简单来说在多核 CPU 下每个线程可能运行在不同的核心上每个核心都有自己的 L1/L2 缓存。线程 A 修改了一个变量的值修改结果可能还停留在 A 所在核心的缓存里没有同步到主内存线程 B 读这个变量时读到的依然是主内存里的旧值。synchronized加锁解锁时底层会触发缓存同步机制解锁时的写屏障强制把当前线程的所有修改刷新到主内存加锁时的读屏障强制从主内存重新读取最新值。这样就能保证后续获取同一把锁的线程能看到修改。理解了这一点你就能明白为什么“在同步块里改了某个普通变量其他线程进入同一个同步块后一定能看到”——这不是 JVM 给你的“魔法”而是内存屏障实打实地做了数据同步。5. synchronized 与 ReentrantLock日常开发里怎么选面试题的经典问题就是“synchronized和ReentrantLock有什么区别”。由于上面花了很大篇幅讲synchronized这里我简单梳理一下两者的差异再给出实际选型建议。5.1 主要区别对照对比维度synchronizedReentrantLock锁类型非公平锁现代版本不支持公平模式公平锁 / 非公平锁可选锁获取方式自动加锁 / 自动释放手动 lock / 手动 unlock可中断性不响应中断lockInterruptibly 支持响应中断超时等待不支持tryLock(timeout) 支持多个条件队列一个锁只有一个 WaitSet可创建多个 Condition底层实现基于 MonitorJDK 内部优化基于 AQS LockSupport性能现代版本优化后已无明显劣势场景合适时同样优秀5.2 真实场景下的选型建议我的建议其实很简单能用synchronized就用synchronized需要灵活控制锁时再用ReentrantLock。为什么优先synchronized三点理由它不需要手动释放锁天然避免“忘记 unlock 导致死锁”的问题。Java 语言层面和 JVM 持续对它做优化可读性和可维护性更高。更简洁的代码意味着更少的出错概率。什么时候需要ReentrantLock当一个方法需要同时获取多个条件队列、需要超时获取锁、需要响应中断或者需要公平锁时synchronized确实无能为力。比如实现一个生产者消费者模型如果有多个条件缓冲区满、缓冲区空需要分别唤醒ReentrantLock 多个Condition就是最顺手的工具。5.3 锁降级和锁粗化的实际体验还有个容易被忽略的点asynchronized在锁竞争不激烈时偏向锁和轻量级锁的开销可能比ReentrantLock的 CAS 操作更低而锁竞争激烈时ReentrantLock的LockSupport.park/unpark和synchronized的 Monitor 阻塞在本质上都会涉及线程挂起与唤醒。现代 JVM 对两者的调度都做了大量优化实际性能差异在绝大多数业务场景下都可以忽略。与其纠结选哪个锁性能更好不如把心思放在降低锁竞争上——减小同步块范围、减少同步块内耗时、合理拆分锁粒度。这些才是真正能显著提升并发性能的手段。6. 高频面试陷阱与实战避坑经验最后一个板块聊点实际面试和开发中高频出现的问题以及我踩过的一些坑。6.1 面试高频问题synchronized锁得住什么最容易被忽略的点是锁的是对象而不是代码。public class BadLock { private Integer count 0; public void add() { synchronized (count) { count; } } }这段代码有什么问题问题在于count执行后变量指向了一个新的Integer对象。也就是说每次加锁锁的对象可能都变了完全失去了锁的意义。同理synchronized (String)拼接后也容易触发锁对象变化。还有一个经典误区synchronized锁两个不同的对象即使代码块内容相同也不会互斥。很多人面试时说“多个线程执行同一个方法里的同步块肯定互斥”这是不准确的。只有多线程争抢的是同一个对象的锁才会互斥。6.2synchronized锁住 String 和基本类型包装类的问题不要用String常量或者Integer这类包装类型作为锁对象。原因有两个String常量池的存在会让不同位置的相同字符串指向同一个对象如果你在多个地方用同一个字符串常量做锁而你本意是想分别锁不同资源就会意外地互相阻塞。包装类型在进行运算后会产生新对象锁对象悄然变化直接导致锁失效。正确做法是定义一个private final Object lock new Object();专门作为锁对象或者锁当前对象 this/类对象 Xxx.class。6.3 可重入性引起的误区synchronized是可重入的。也就是说同一个线程已经持有某个对象的锁再次进入该对象锁保护的代码块时不需要重新竞争锁直接放行。因为 Monitor 的持有者是自己时_recursions加一即可进入。这个特性在继承场景下容易引起困惑如果父类和子类的方法都加了synchronized子类方法调用父类方法时因为两把锁实际上是同一把锁的是this所以不会死锁。但如果父类方法锁的是this而子类方法锁的是子类自己的对象又有可能产生意料之外的互斥。6.4 锁对象为 null 会怎样synchronized作用于null对象上会在运行时抛出NullPointerException。如果在代码里动态传入锁对象一定要先判空。踩过一次真实的生产事故当时的代码里锁对象是从配置中心获取的一个对象 key有一次配置写错了key 对应的对象没初始化结果所有请求在同一行抛NPE。排查半天才定位到是锁对象为 null 导致的。6.5 我在实战中的三个核心建议第一个建议是锁粒度能小则小。不要在同步块里执行耗时的 I/O 操作或远程调用。锁内的等待时间越长其他线程阻塞的概率越大整个系统的吞吐量就越差。如果确实需要跨线程传递结果尽量把耗时操作挪到锁外。第二个建议是优先使用局部变量和无状态设计。很多情况下你根本不需要加锁。如果你能用局部变量、线程封闭、不可变对象来避免共享可变状态那比任何锁都高效。锁本质上是对共享可变状态的兜底方案而不是第一选择。第三个建议是多线程调试时加 JVM 参数辅助定位问题。比如-XX:PrintFlagsFinal查看锁相关参数默认值-XX:PrintSafepointStatistics查看安全点停顿。遇到诡异的性能问题先看锁竞争热点再看线程 dump。用好jstack观察线程状态比瞎猜有效得多。写在最后关于 synchronized 的一点个人体会学习synchronized的过程本质上也是理解 JVM 并发设计哲学的过程。从最初的无锁到偏向锁再到轻量级锁和重量级锁它展示了一条非常典型的渐进优化路线在无竞争时零开销在低竞争时尽量使用轻量手段在高竞争时才切换到操作系统级的重锁。这套思路本身就可以迁移到很多系统设计中——先保证正确性再在正确性的前提下做性能优化而不是一上来就用最重的方案。网上关于synchronized的八股文很多但真正把这些机制串起来能对着对象头讲清楚锁升级、能对着ObjectMonitor讲清楚阻塞唤醒、能对着 JMM 讲清楚可见性的人并不多。建议你读完这篇文章后自己动手用javap反编译一段同步代码再看一遍对象头结构印象会深很多。最后分享一个小技巧当你看到一段代码出现“多个线程同时读偶尔写”的场景时先别忙着加锁。想想能否用volatile、AtomicInteger、CopyOnWriteArrayList这些更贴合场景的工具。synchronized是很强大但用好并发工具箱里的每一个工具才是一个合格后端工程师该有的基本功。

深入剖析synchronized：从对象头到锁升级，彻底理解Java并发锁机制

相关推荐

VisualDL深度学习可视化工具实战指南

MATLAB部署AOD-Net去雾模型：从Caffe导入到推理实践

开放式代码评审全解析：从理念到落地的团队实践指南

更多资讯

论文格式不求人：Word批量设置数字和字母为Times New Roman的三种方法

ESP32开发板更换适配指南：从引脚配置到音频编解码器

LLVM项目仓库完全入门：从源码构建到编写你的第一个Pass

NVIDIA控制面板不见了？五种方法帮你找回

UI-TARS Desktop 使用指南：如何用自然语言让 AI GUI Agent 操作电脑，从零跑通第一个自动化任务

Babysitter+Claude Code插件安装教程：2条命令完成原生marketplace安装

今日更新

深入解析Transformer多头注意力机制与工程优化

OpenClaw 的 Skills 跑学习任务，模型通道改到 TaoToken 通道行不行？

ChatGPT报错Oops, an error occurred! 全链路排查指南

本周精选

深入解析Transformer多头注意力机制与工程优化

OpenClaw 的 Skills 跑学习任务，模型通道改到 TaoToken 通道行不行？

ChatGPT报错Oops, an error occurred! 全链路排查指南

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？