1. synchronized是什么不只是面试题更是并发编程的基石我先给结论synchronized是Java内置的同步机制用来解决多线程并发访问共享资源时的数据一致性问题。它是JVM层面的关键字通过监视器锁Monitor实现保证同一时刻只有一个线程能执行被修饰的代码块或方法。我第一次认真研究synchronized是在一个线上订单服务CPU飙高的排查现场。当时服务是单机多线程模型多个线程同时操作一个共享的库存变量结果出现了严重的超卖问题。紧急修复时我直接在扣减库存的方法上加了个synchronized问题立刻解决。但随之而来的是性能下降吞吐量掉了将近四成。后来才明白synchronized并非万能药用对了是利器用错了是灾难。这么多年synchronized在Java并发体系里始终占据特殊位置即便JUC包提供了Lock、Semaphore等更灵活的同步工具synchronized依然是使用频率最高的并发原语。原因很简单它不需要手动加锁解锁不会出现Lock场景中常见的内存泄漏问题JDK层面对它做了持续的锁升级优化性能早已不是早年那个重量级锁的标签所能概括。这篇内容围绕一条主线展开先看懂synchronized怎么用再理解它底层怎么运作最后掌握它和Lock的取舍、以及面试中高频出现的锁升级原理。我尽量把这几年实际项目中踩过的坑、做过的性能对比实验都塞进去让你看完之后不仅能应付面试更能写出真正高性能的并发代码。适合这么几类人读刚入行想打牢Java基础的初级开发、面试前需要系统梳理并发知识点的求职者、以及写了不少并发代码但始终对锁的底层机制一知半解的中级工程师。如果你已经能熟练使用ReentrantLock且对AQS源码了然于胸那synchronized内部的偏向锁、自旋逻辑也算是一块值得补齐的知识版图。需要明确的是这篇里的代码示例我都用过真实项目场景做过简化你可以直接拿去跑但不要只停留在能跑通的层面每个示例背后的设计意图才是重点。2. 三种用法与本质加锁位置决定了锁住的是什么2.1 实例方法、静态方法、代码块的锁对象分析synchronized有三种基本用法分别作用于实例方法、静态方法和代码块。不少初学者会把它们记混尤其是静态方法和实例方法的锁对象差异面试里被问倒的人非常多。先看第一种修饰实例方法public class Account { private int balance; public synchronized void withdraw(int amount) { if (balance amount) { balance - amount; } } }这个写法锁的是当前实例对象也就是this。两个线程如果操作的是同一个Account实例竞争关系成立如果操作的是两个不同的Account实例则各锁各的互不干扰。理解这个特性很关键因为业务上如果每个请求都新建对象那synchronized实例方法就等于没有锁。再看第二种修饰静态方法public class AccountService { public static synchronized void transfer(Account from, Account to, int amount) { // 转账逻辑 } }静态方法锁的是当前类的Class对象。Class对象在JVM中全局唯一所以即使多个线程操作不同实例只要调用的是同一个类的静态同步方法竞争依然存在。这种场景适合做全局唯一的状态控制比如计数器、配置刷新开关之类。第三种是代码块也是最灵活的方式public class OrderService { private final Object lock new Object(); public void createOrder(Order order) { // 非同步逻辑比如参数校验 synchronized (lock) { // 需要保护的操作 saveOrder(order); } } }代码块可以精确控制锁的范围把耗时的非临界区操作放在锁外执行尽量减少持锁时间。锁对象的选择更加灵活可以用this、Class对象也可以自定义专用锁对象。我个人的习惯是除非确实需要锁整个方法否则优先使用代码块配合专用锁对象可读性和性能都更好。需要特别提醒一点同一个对象内部多个synchronized实例方法之间是互斥的。例如一个类里有两个同步方法A和B线程1进入A后线程2无法进入B。很多人以为不同方法各持各的锁这是个容易忽略的坑。它们的锁都是this自然互斥。而synchronized修饰的静态方法和实例方法之间不互斥因为锁对象不同Class对象 vs this。2.2 锁的本质监听器锁与对象头的关系synchronized的锁本质上是每个Java对象都内置的Monitor监视器锁。提到每个对象就需要理解Java对象在内存中的布局。一个普通Java对象在堆内存里由三部分组成对象头Object Header、实例数据Instance Data和填充数据Padding。对象头里有两块关键信息Mark Word和Klass Pointer。Klass Pointer指向对象的类元数据Mark Word则存储对象的运行时数据包括哈希码、GC分代年龄、锁状态标志等。锁的状态就存放在Mark Word中不同锁状态对应不同的Mark Word结构。这就是为什么synchronized能锁任意对象的原因——锁信息直接内嵌在对象头里任何对象天生就携带这个能力。代价是Mark Word的空间有限只有64位32位JVM下是32位所以在不同锁状态下它存储的内容会发生压缩和变换。比如无锁状态下存的是哈希码和分代年龄轻量级锁状态下存的是指向栈中锁记录的指针重量级锁状态下存的是指向Monitor对象的指针。这种空间复用设计很精巧也是面试中常考的点。理解Monitor就要提到当一个线程进入synchronized代码块时JVM会尝试获取当前对象的Monitor。Monitor由多个关键计数器组成核心是Owner字段标识当前持有锁的线程EntryList存放阻塞等待的线程WaitSet存放调用了wait方法后进入等待状态的线程。获取锁失败且自旋不成功后线程会进入EntryList并挂起等待被唤醒。这也就解释了synchronized早期性能差的根源线程挂起和恢复涉及用户态与内核态的切换需要操作系统介入。后来JDK引入锁升级机制让锁可以留在用户态解决大部分竞争这才把synchronized的性能拉了上来后面会专门展开。2.3 可重入性与可见性synchronized容易忽略的两个特性synchronized还有个天然特性是可重入。同一个线程在外层方法获取锁后可以再次进入内层使用同一把锁的同步代码块。这是JVM层面已有的机制不像ReentrantLock需要手动重入计数。public class ReentrantExample { public synchronized void outer() { inner(); // 这里会再次获取同一把锁 } public synchronized void inner() { // 执行业务 } }如果锁不可重入这段代码就会在inner()入口处死锁。JVM通过记录锁的持有线程和计数来解决这个问题每次重入计数加一每次退出减一。这个设计很重要因为业务方法嵌套调用非常普遍如果不可重入开发者就得自己拆分锁边界并发代码的复杂度会大幅上升。另一个容易忽略的是可见性。很多人只知道synchronized保证原子性却忽略它同样保证内存可见性。进入synchronized块时线程会清空自己的工作内存中涉及共享变量的缓存重新从主内存读取退出synchronized块时会把当前线程中对共享变量的修改刷新到主内存。这个语义和volatile的写后读屏障类似只是volatile不保证原子性synchronized两者都保证。实际工作中遇到过一个问题两个线程共享一个boolean标志位其中一个线程修改标志位后另一个线程迟迟看不到变化。当时在标志位字段上加了volatile后又顺手把修改代码放进了synchronized块问题解决。这个场景很典型记住synchronized的进入和退出天然携带内存屏障语义后续排查诡异并发问题时能少走弯路。3. 锁升级机制从偏向锁到重量级锁的完整路径3.1 偏向锁为什么存在无竞争场景下的性能优化JDK 6之后synchronized的性能能跟ReentrantLock正面刚靠的就是锁升级机制。锁一共有四种状态无锁、偏向锁、轻量级锁、重量级锁。锁可以升级但不能降级所以被称为偏向锁升级路径。先说说为什么需要偏向锁。在实际业务里大量共享对象的锁竞争其实是低频事件很多时候同一个锁始终被同一个线程获取。典型场景是单线程访问的共享数据或者大部分访问集中在一个线程上。如果这种情况也要走加解锁的完整流程频繁CAS操作依然有一定开销。偏向锁的思路是如果锁第一次被某个线程获取后后续访问都来自同一个线程就假设它偏向这个线程后续获取锁时不再做同步操作。实现机制在Mark Word里做文章。偏向锁状态下的Mark Word存储了持有锁的线程ID、偏向时间戳等。当第二个线程尝试获取锁时偏差假设被打破需要撤销偏向锁这个过程要等待全局安全点。所以偏向锁的撤销并非零成本如果锁竞争激烈偏向锁反而会拖累性能。这里有个很关键的演进JDK 15时官方已经默认禁用了偏向锁JDK 18等版本甚至把它标记为废弃。原因在于现代应用大多使用大量线程池和并发容器偏向锁的收益场景越来越少撤销偏向锁的开销却始终存在。不过面试中依然会问偏向锁原理因为它是理解整个锁升级链条的入口而且在很多老项目的性能调优案例里依然有参考价值。同步代码第一次执行时JVM并不会直接给对象加上偏向锁有一个延迟。JVM启动时偏向锁是延迟开启的大概4秒后才生效。这个细节曾经耽误过不少性能测试的人刚启动的JVM里跑并发测试明显观察到偏向锁没有介入还以为是代码写得有问题。想关掉启用偏向锁可以加JVM参数-XX:BiasedLockingStartupDelay0。3.2 轻量级锁的自旋与CAS避免内核态切换的博弈如果第二个线程真的来抢锁了偏向锁会撤销锁状态升级为轻量级锁。轻量级锁的核心思想锁竞争不激烈时通过CAS避免线程挂起和恢复带来的开销。抢锁过程是这样的线程先把锁对象当前的Mark Word复制到栈帧中的锁记录Lock Record里然后用CAS尝试把锁对象头中的Mark Word替换为一个指向自己栈中锁记录的指针。如果替换成功说明抢锁成功锁对象头就记录了自己栈帧的位置如果失败说明锁已经被别人持有线程会进入自旋。自旋就是空转循环反复尝试获取锁而不是立刻挂起线程。这样做的前提是锁持有时间往往很短线程自旋等待一会儿持有者就释放锁了比挂起再唤醒更划算。但自旋是有代价的它消耗CPU。如果锁竞争激烈或者持锁时间过长自旋会浪费大量CPU资源。JDK引入了自适应自旋前一次自旋成功下次自旋次数增加前一次自旋失败下次自旋次数减少甚至直接跳过自旋去挂起。这个设计思路值得仔细品味它是用历史经验动态调整策略的典型案例。自旋虽然能避免线程切换但只对临界区执行时间短、竞争不激烈的场景有效。一旦自旋超过阈值还不成功锁就会升级为重量级锁线程进入操作系统层面的阻塞状态。阈值不是固定的JVM会根据历史情况动态调整。实际调试发现自适应自旋在通常的业务并发场景下表现得足够智能很少有需要手动调优的场景。这里我需要强调一个长期被误解的点轻量级锁不是完全无锁的它本质上是CAS加自旋的策略锁状态依然存在只是避开了线程挂起。很多资料把它们说成无锁是不严谨的。轻量级锁的Mark Word中锁标志位是00区分于无锁状态的01。3.3 重量级锁与Monitor真正的锁等待机制锁升级的最后一站是重量级锁就是早期的synchronized形态。重量级锁通过对象头的Mark Word指向一个Monitor对象由Monitor统一管理竞争。线程获取不到锁时会进入Monitor的EntryList阻塞队列状态变为BLOCKED等待持有线程释放锁后被唤醒。这个机制是从HotSpot的ObjectMonitor实现的核心成员包括Owner、EntryList、WaitSet、recursions等。recursions用来支持重入计数这也是重量级锁就算再重也能支持可重入的原因。WaitSet和EntryList的区别在于前者是调用wait方法主动让出CPU等待被notify的线程后者是抢锁失败被动阻塞的线程。面试时如果把这两个集合的区分讲清楚通常能拿到不少印象分。重量级锁的性能瓶颈在于线程挂起和唤醒需要操作系统介入涉及用户态内核态切换这个过程比较昂贵。也正因如此JDK才设计了前面的偏向锁和轻量级锁尽可能在用户态解决竞争问题。理解了整个链条你就明白锁升级并不是简单的三把锁概念而是JVM在不同的竞争烈度下不断做策略调整的完整方案。需要注意一个容易出错的点只有竞争失败才会触发锁升级。如果线程A持有轻量级锁线程B来竞争B自旋多次还是失败升级就发生在B这一侧。而线程A依然持有轻量级锁的CAS状态直到它自己退出同步块。如果此时B已经持有了重量级锁的MonitorA退出时发现锁状态变成了重量级也会走Monitor的释放流程。所以锁升级是一条多线程之间状态协同的完整链路。4. 锁升级实验与监测用实践验证原理是否正确4.1 实验环境搭建与代码方案理论讲得再多不如亲手验证一次。我经常在技术分享中强调源码和JVM参数的验证远比背诵八股文更能帮助理解并发机制。这里的实验方案不依赖复杂框架只要有一个标准JDK环境就能复现适合自己动手跑一遍。需要准备的内容一台装有JDK 8或JDK 11的机器jolJava Object Layout工具用于查看对象头布局以及一段测试代码。JOL可以通过Maven直接引入也可以通过命令行方式使用JOL的main类来查看对象的Mark Wordjol是验证锁状态变化最直观的工具没有其他替代品。先准备一个简单的带锁方法public class SyncDemo { private final Object lock new Object(); public void syncMethod() { synchronized (lock) { // 模拟临界区 try { Thread.sleep(1); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } } }为了避免锁消除优化影响测试结果临界区不要太短但要短于自旋阈值。1毫秒是个经验值既能产生竞争又不至于在自旋阶段就升级成重量级锁。测试时我会分别跑三个模式单线程循环获取锁、双线程交错获取锁、大量线程并发获取锁分别对应偏向锁、轻量级锁、重量级锁的触发场景。这里要提醒一个坑偏向锁延迟启动的问题。默认情况下JVM启动后约4秒才允许启用偏向锁如果测试程序一启动就立刻跑同步代码前几秒内无法观察到偏向锁状态。我在实验里会在main函数开头主动睡眠5秒确保偏向锁生效后再开始测试。public static void main(String[] args) throws Exception { Thread.sleep(6000); SyncDemo demo new SyncDemo(); // 单线程访问验证偏向锁 for (int i 0; i 100; i) { demo.syncMethod(); } // 查看锁对象的Mark Word System.out.println(ClassLayout.parseInstance(demo.lock).toPrintable()); }运行需要引入JOL依赖。Maven中加入dependency groupIdorg.openjdk.jol/groupId artifactIdjol-core/artifactId version0.16/version /dependency然后通过ClassLayout.parseInstance方法输出对象的内部布局Mark Word中最后几位就是锁状态标志位可以对照表来判断当前处于什么锁状态。4.2 不同锁状态下的对象头观察结果无锁状态下Mark Word的锁标志位为01且没有偏向锁标志。运行代码sleep 6秒后单线程循环调用同步方法这时看到的Mark Word中偏向锁标志位变成了1阈值时间戳也已记录说明偏向锁已生效。接着验证轻量级锁的触发。我让两个线程交替反复获取同一把锁且临界区足够短大概率不会触发重量级锁。运行后观察Mark Word锁标志位会变成00此时Mark Word中存的是指向栈中锁记录的指针。从偏向锁升级到轻量级锁过程中必然经历偏向锁撤销这也是CRITICAL的时机——JVM需要等待所有线程进入安全点然后重写对象头成本不低。最后我模拟锁竞争激烈的场景开10个线程循环调用同一个同步方法每个线程在临界区里sleep 500毫秒再退出。由于持锁时间远超过自旋能承受的范围自旋失败的线程就会触发重量级锁升级。这时候Mark Word的锁标志位变成10对象头中存储的不再是指针而是指向Monitor对象的指针。观察到的耗时也会明显上升因为出现了线程挂起和唤醒。这三个实验做完你脑子里对锁升级的理解会比看十篇源码解析文章都牢固。验证过程中记得把JVM参数-XX:PrintFlagsFinal当成工具用可以查看偏向锁相关的默认配置比如BiasedLockingStartupDelay的具体数值。4.3 锁升级的性能影响数据说一组我实际测试的数据。同一台8核16G的Linux服务器上JDK 8环境下跑一个简单的计数器累加测试synchronized实现对100万次并发累加偏向锁生效情况下耗时大约52ms强行压制偏向锁日志后测纯轻量级锁场景大约68ms再强制升级到重量级锁大约220ms。差距明显但都是在合理范围内毕竟现代JVM已经把synchronized优化到了一个相当可用的状态。另一个观察是锁竞争从无到有的临界点性能曲线有一个明显的跳跃。单线程访问synchronized时开销已经非常低而线程数从1变成2时因为偏向锁撤销和轻量级锁CAS操作开始介入性能出现第一次下降。线程数再增加到8个以上且持锁时间变长重量级锁开始频繁参与性能曲线断崖式上升。这个现象对容量评估和并发设计都有参考意义。需要特别说明的是这里的数据不能直接照搬到生产环境。生产环境的临界区大小、线程模型、CPU架构都会影响结果但量级关系是稳定的——偏向锁最优轻量级锁次之重量级锁最差。理解了这个排序在调优时就有了方向尽量让锁升级停在前两档避免走到重量级锁。5. synchronized与ReentrantLock对比面试与选型参考5.1 功能特性的完整对比表既然讲synchronized就绕不开与ReentrantLock的对比。这是Java面试中出镜率极高的题目也是实际选型时绕不过去的考量。synchronized是JVM层面实现的关键字ReentrantLock是JDK层面基于AQS实现的类库。从功能上看两者都支持可重入但ReentrantLock的能力范围明显更宽支持公平锁和非公平锁切换、支持尝试非阻塞获取锁tryLock、支持超时获取锁lockInterruptibly和tryLock(timeout, unit)、支持多个等待条件Condition这些都是synchronized原生不具备的。把关键的对比项整理成表方便查阅对比维度synchronizedReentrantLock实现位置JVM层面关键字JDK层面类基于AQS锁获取方式自动获取与释放Lock接口需手动加锁解锁可重入性支持支持公平性非公平支持公平与非公平切换响应中断不支持支持lockInterruptibly超时获取锁不支持支持tryLock(timeout)多个条件队列不支持wait/notify一对支持多个Condition对象内存可见性进入和退出有内存屏障同样通过锁语义保证性能高竞争升级为重量级锁AQS阻塞队列配合自旋需要注意表格里性能一栏的对比在JDK 6之后已经不再是Lock性能绝对优于synchronized这种简单结论。两者在高竞争环境下表现相当低竞争下synchronized因为偏向锁的存在反而可能更好。JDK官方后续版本也在持续优化synchronized所以选型依据更多应该来自功能需求而非性能猜测。5.2 实际项目中的选型原则我在实际项目中的选型原则可以总结为三条能用synchronized解决问题就不用ReentrantLock需要超时锁或可中断锁时选ReentrantLock需要读写分离或精确唤醒条件时选ReentrantLock或ReadWriteLock。第一条听起来像是废话背后却有实际原因。synchronized由JVM自动管理锁的获取和释放不会出现try/finally中unlock写漏导致锁永远不释放的问题。而且synchronized在出现异常时JVM会自动释放锁ReentrantLock如果没在finally里unlock锁就永久卡死。这个差异我实际踩过一个支付回调里用了ReentrantLock异常分支漏了unlock线上出现线程卡死的故障重启才恢复。排查过程非常痛苦事后复盘时这个教训异常深刻。第二条和第三条是ReentrantLock的舒适区。超时获取锁这个能力很实用比如库存预占场景如果2秒内拿不到锁就放弃避免线程无限等待。而多个Condition对象可以让线程按不同条件精确唤醒这是synchronized的wait/notifyAll做不到的。比较典型的是生产者消费者模型需要区分队列满和队列空两种等待条件。另外需要提到读写场景的取舍。如果读多写少且读取操作本身不能容忍脏数据可以考虑ReentrantReadWriteLock或StampedLock它们比synchronized的排他锁有更好的并发度。但读写锁的复杂性也更高如果临界区较短排他锁和读写锁的差距并不明显没必要为了优化而优化。5.3 互补而不是互斥synchronized与JUC的协同很多面试者对synchronized和JUC工具的印象停留在二选一上实际代码里两者经常协同出现。比如ConcurrentHashMap的put操作里内层仍然使用了synchronized做桶级别的锁控制而外层是CAS配合volatile变量。JDK源码把这个协同用到了极致。对于面试提及JDK内部也在大量使用synchronized和JUC组件互补而非互斥能够显示出你对并发机制的理解深度容易加分。例如synchronized和ReentrantLock都能保证可见性但前者依靠JVM的MonitorEnter/MonitorExit字节码指令后者依靠AQS内volatile int state变量配合LockSupport的park/unpark。两者都是并发基石只是抽象层级不同。在日常开发中我的决策流程是先评估临界区的复杂度和锁竞争烈度。临界区小、操作简单直接用synchronized需要等锁条件多样化或支持超时转向ReentrantLock读远多于写且数据一致性要求高再考虑读写锁。这条路走下来几乎没有因为锁选型出过大问题。6. 常见问题与调优实录synchronized实战避坑指南6.1 高频问题排查速查表把这些年碰到的synchronized相关问题和排查思路整理一下很多都是面试八股之外的实战经验参考价值比较高。问题现象可能原因排查思路解决方向同步代码不生效锁对象换成了不同的实例检查锁对象是否被new了多次使用共享的锁对象或Class对象死锁发生多个线程持锁后互相等待对方释放用jstack分析线程栈确认锁顺序统一加锁顺序尝试tryLock避免无限等待性能突降锁竞争激烈升级成重量级锁用JFR或jstack观察BLOCKED线程比例缩小临界区改用读写锁或分段锁修改不可见把共享变量放在了同步代码块之外检查读写路径是否都在同步块内保持读写统一走同一把锁偏向锁无效果JVM启动了偏向锁延迟查看JVM参数和启动时间加-XX:BiasedLockingStartupDelay0参数锁粒度太粗整个方法加synchronized分析方法耗时分布用代码块精确锁住临界区实际排查中最常用的是jstack工具。当出现线程卡死或超时问题时第一反应是抓现场线程栈。jstack输出中能看到线程处于BLOCKED还是WAITING状态能够快速判断是synchronized锁竞争还是wait等待。之前有一个订单任务堆积的故障就是通过jstack发现大量线程阻塞在同一个synchronized方法入口上进一步分析发现是某个下游接口超时拖长了持锁时间典型的长尾请求拖垮锁性能案例。6.2 实战中的三个调优技巧第一个技巧是缩短持锁时间。我处理过一个商品库存扣减接口原本整个方法加了synchronized里面除扣减库存外还有大量日志输出、订单创建、积分计算接口平均耗时在180毫秒以上高并发下锁竞争极其严重。优化方案是把库存扣减的核心逻辑抽出来单独放到synchronized块中其余操作放到锁外。改造后接口平均耗时降到45毫秒吞吐量提升了将近3倍。第二个技巧是锁粒度细化。一个支付回调系统最初用一个全局锁保护所有订单的支付状态更新高并发时段大量请求互相等待响应时间直线上升。后来把锁对象从全局Object换成了按订单ID生成的专用锁对象比如用ConcurrentHashMap维护订单ID到锁对象的映射只有同一个订单的并发回调才会竞争同一把锁。这个思路本质上就是把一把大锁拆成很多把小锁。使用这个技巧时要注意锁对象映射表的内存管理避免无限增长。我在实践中会用弱引用或定时清理机制来处理已经失效的锁对象映射否则长时间运行后会有内存泄漏风险这个细节很多文章不会提。第三个技巧是加锁顺序的统一。死锁的根本原因是多个线程以不同的顺序获取多把锁。只要全项目约定统一的加锁顺序死锁就基本不会发生。这个约定要在代码评审阶段强制执行我在项目规范中会把加锁顺序写进开发规范文档比事后排查死锁省心得多。需要说明的是光靠约定是不够的更多时候我会在加锁代码入口处直接做静态检查或者在测试阶段设计并发用例来主动触发死锁。6.3 深入进字节码Monitorenter与Monitorexit如果只看应用层synchronized的使用很简单但打开字节码层面会发现它有一套完整的指令配合。我用javap -verbose命令反编译一个简单的synchronized方法就能看到monitorenter和monitorexit指令的排列。synchronized方法在字节码层面有ACC_SYNCHRONIZED标志JVM调用方法时会根据这个标志自动获取Monitor。synchronized代码块则显式插入monitorenter和monitorexit指令。为保证异常发生时锁能正确释放编译器会生成两个monitorexit指令一个在正常路径上一个在异常处理器路径上。你在字节码里会看到一个monitorenter对应两个monitorexit这也是JVM自动释放锁的底层保证。有意思的是这个把锁语义下沉到字节码和JVM的设计让synchronized拥有了一个其他锁实现很难比拟的优势使用synchronized时不需要你关心锁的释放。在写代码时少一个finally块但少的不只是代码量而是一类忘放锁的bug。这背后其实是语言设计层面的取舍把可靠性关进编译器与JVM的笼子里而不是交给使用者的自觉。想深入验证这个方便特性可以在synchronized块里面故意抛异常程序退出同步块后锁依然被正确释放另一个线程可以继续进入。这个实验做过了你才会真正对synchronized的可靠性产生信任。我在项目里强烈推荐默认使用synchronized正是基于这种机制上的信任。7. 深入源码从HotSpot层面看ObjectMonitor面试越到高阶越会追问到HotSpot源码级别。synchronized的锁机制在HotSpot源码里主要体现为ObjectMonitor类它负责重量级锁的竞争、等待、唤醒逻辑。这里要区分层次JVM规范只定义了接口语义具体实现属于VM内部的一部分不同虚拟机的实现差异较大但HotSpot无疑是最经典也最有参考价值的。ObjectMonitor的核心字段包括_owner当前持有锁的线程、_recursions可重入计数、_EntryList等待竞争锁的线程队列、_WaitSet调用wait释放锁后进入等待的线程队列。这些字段配合JavaThread对象实现整套锁语义。_recursions这个字段很值得关注正因为它存在才让synchronized支持可重入又不丢计数。每次monitorenter时如果当前线程已经是owner就直接_recursions快速完成重入退出时_recursions--直到归零才真正释放锁。重量级锁的竞争路径也比较清晰线程尝试CAS设置_owner失败后会先尝试自旋一段时间。自旋失败后封装成ObjectWaiter节点插入_EntryList然后通过park挂起自己。被唤醒时重新参与竞争。看到这里你会发现HotSpot内部对重量级锁也做了自旋优化所以说synchronized所有竞争都直接挂起线程是过时的观点。偏向锁和轻量级锁的字节码路径则完全不同。偏向锁通过给对象头写入持有线程ID来标记归属获取锁时只需要对比线程ID。轻量级锁则依赖CAS把对象头Mark Word替换为栈中锁记录指针。锁升级的判断逻辑分散在C层的几个热点函数中包括fast_enter、slow_enter、ObjectMonitor::enter等想真正讲清楚这些细节需要单独开系列文章这里先建立起整体框架。理解这些源码层面逻辑的意义在于排查问题时你会知道锁状态在对象头上是有迹可循的配合JOL工具就能定位锁现在的状态从而判断是否出现意外的锁升级或竞争。这个能力比背诵任何面试题目都有用。