用户甲熟悉Java并发编程的朋友，大概率都经历过这样一个阶段：背了无数次synchronized的用法，知道它能保证原子性、可见性和有序性，能修饰方法、代码块，可一旦被问到“synchronized底层到底怎么实现的”“对象头里到底存了什么”“内存屏障和它有什么关系”，就容易卡壳。市面上讲synchronized的文章不少，但很多要么只停留在字节码层的monitorenter/monitorexit，要么直接甩出大片源码注释，真正能把对象头、锁升级、内存屏障这条链路串清楚的并不多见。这篇文章我想换个角度，不贴大段HotSpot源码，而是把这条完整链路拆开揉碎，从Java对象在内存里长什么样开始，一路讲到锁升级、重量级锁的Monitor机制，再到JIT编译阶段锁消除、锁粗化，最后落到硬件层面的内存屏障，一次讲透。不管是还在啃Java基础准备面试，还是已经在实际项目里排查并发问题，这篇文章都值得你花二十分钟认真读完。
1. 从一次面试追问说起：synchronized到底把锁放哪了
先讲个真实场景。有次帮朋友做模拟面试，前几轮八股文都答得挺流畅，问到“synchronized加锁之后，锁的信息储存在哪里”这个问题时，对面沉默了几秒，然后说“存在锁对象里吧”。这个回答方向是对的，我再追问“具体是锁对象的哪个位置？里面存的又是什么？”他就答不上来了。
这个问题的准确答案，藏在Java对象的内存布局里。任何一个Java对象，在HotSpot虚拟机里都由三部分组成：对象头（Object Header）、实例数据（Instance Data）和对齐填充（Padding）。其中对象头又包含两部分：Mark Word（标记字）和Klass Pointer（类型指针），如果对象是数组，还会多一个记录数组长度的字段。
Mark Word就是synchronized锁信息真正的落脚点。它在64位JVM上占8个字节，这64个bit会根据对象所处的状态，存储完全不同的信息：无锁状态下存的是对象哈希码、GC分代年龄；偏向锁状态下存的是持有锁的线程ID、偏向时间戳；轻量级锁状态下存的是指向线程栈中Lock Record的指针；重量级锁状态下存的是指向堆中Monitor对象的指针。
这就牵扯出一个很多初学者没想明白的问题：一个Java对象在创建出来的时候，就已经自带了一套记录锁状态的区域，JVM并没有为“加锁”这个动作额外分配一块独立的锁空间，而是通过复用对象头里那64个bit，在不同状态下赋予它们不同的含义。所以“锁是存在对象里的”这句话并不严谨，准确说是存在对象的Mark Word里。
1.1 Klass Pointer和对象头的容量问题
Klass Pointer在开启压缩指针的情况下占4个字节，用于指向方法区的类元信息。它跟锁没有直接关系，但搞清楚对象头的完整结构，对理解后面锁升级有帮助，所以这里顺便带一句。
还有一个细节值得注意：Mark Word里那64个bit是非常珍贵的存储资源。它既要存哈希码，又要存GC分代年龄，还要在加锁后存线程ID或Monitor指针。所以JVM在设计时就定了一条规矩——偏向锁一旦撤销，对象原始的哈希码如果还没计算过，后面再计算就会导致偏向锁失效。这是因为无锁状态下的哈希码占了31个bit，而偏向锁状态下这31个bit全部被线程ID和偏向标记占用了，没法同时保存两套数据。这也是为什么某些场景下调用System.identityHashCode()会导致偏向锁直接膨胀到轻量级锁的原因。
1.2 无锁状态下的Mark Word长什么样
拿默认开启偏向锁的HotSpot 8举例，一个新建对象如果没被任何线程加锁，它的Mark Word大致长这样：
- 偏向标记位（1 bit）：1，表示当前对象处于“可偏向”状态
- 偏向锁标记（2 bit）：01（这是锁标志位，和偏向标记位合起来看）
- 分代年龄（4 bit）：初始为0
- 哈希码（31 bit）：哈希码是lazy计算的，第一次调用
hashCode()后才会写入
这里有个非常容易搞混的概念：偏向标记位和锁标志位是两个不同层次的标记。锁标志位永远是最后两位，它的取值组合决定了锁的当前状态——01表示无锁或偏向锁（具体是哪种要看偏向标记位），00表示轻量级锁，10表示重量级锁，11表示GC标记。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 锁升级的完整链路：偏向锁、轻量级锁、重量级锁是怎么一层层膨胀的
synchronized从JDK 1.6开始做了大量优化，核心思路就是“能不加锁就不加锁，能加便宜的锁就不加贵的锁”。这里的便宜和贵，指的是线程挂起和恢复的成本。偏向锁就是最便宜的一档——它在无竞争场景下连CAS都不需要；轻量级锁用CAS加自旋；重量级锁则要借助操作系统的互斥量，线程会真正进入阻塞状态。
必须强调的是，锁升级的过程是单向且不可逆的：偏向锁→轻量级锁→重量级锁。不存在从重量级锁降级回偏向锁的路径。很多人会震惊于“即使锁已经被多个线程竞争过变成重量级，也不会再降级”，这是HotSpot的一个明确设计决策，原因是偏向锁的撤销本身就要STW（Stop The World），来回升降级的成本远高于直接维持重量级锁。
2.1 偏向锁的获取：一个连CAS都不需要的操作
偏向锁的设计初衷是解决“同一线程反复进入同步块”的场景，比如一个ArrayList只被单线程访问但其方法被synchronized修饰。当第一个线程A进入同步块时，JVM会在当前线程的栈帧中分配一个Lock Record，然后通过CAS尝试把Mark Word中的线程ID替换为线程A的ID。
如果替换成功，这个对象就进入了偏向模式。之后A再次进入同步块时，不需要任何原子操作，只需要检查Mark Word里的线程ID是不是自己，是就直接执行同步代码。这个检查不涉及锁竞争，所以开销极小。
但这里藏着一个很多文章不会细说的点：偏向锁的获取也不是完全无条件的。如果当前对象处于无锁但可偏向状态，JVM还要判断类的偏向锁功能是否关闭、对象是否已经偏向过其他线程。如果偏向过其他线程且那个线程还活着，就要尝试撤销偏向并重新偏向当前线程，这个操作需要等待全局安全点。
2.2 偏向锁的撤销：一场需要STW的拉锯战
偏向锁撤销是整个锁升级链路里代价最不可控的一环。当线程B尝试获取一个已被线程A偏向的对象锁时，JVM不会直接让A和B竞争，而是先撤销偏向锁。撤销过程需要等待所有线程进入安全点（Safe Point），暂停整个应用，然后判断持有偏向锁的线程A是否已经退出同步块。
如果A已经退出，就把对象头恢复成无锁状态，再让B重新走加锁流程；如果A还在同步块内，就将偏向锁升级为轻量级锁，A持有的锁记录变为轻量级锁的锁记录。无论哪种情况，这中间都包含一次全停顿。所以偏向锁其实是一把“对单线程友好、对多线程极端不友好”的锁——一旦发生竞争，撤销偏向上的开销可能比直接上轻量级锁还高。
一个实操上的建议是：如果明确知道某个被synchronized保护的锁对象会被多个线程竞争，可以在JVM启动参数里加-XX:-UseBiasedLocking关闭偏向锁，反而能减少撤销带来的停顿。JDK 15之后默认禁用了偏向锁，也是出于同样的考虑——在容器化部署和多核机器普及后，偏向锁带来的收益已不如它可能引发的STW代价。
2.3 轻量级锁：CAS加自旋
偏向锁撤销之后，锁就升级成了轻量级锁。轻量级锁的核心思路是：不立刻让线程陷入阻塞，而是在用户态通过CAS抢锁，抢不到就自旋等待一会儿，因为同步块的代码往往执行时间很短，自旋等待的成本远低于线程挂起和恢复的成本。
这里要注意一个认知误区：轻量级锁的“轻量”是相对重量级锁而言的，它本身并不保证一定能避免线程阻塞。在没有锁竞争或竞争不激烈时，它确实可以让线程在用户态完成加锁解锁；一旦竞争升级，比如自旋超过阈值（默认自适应自旋的线程数超过CPU核数的一半），就会膨胀成重量级锁。
从实现细节来看，线程在抢轻量级锁之前，会先在当前线程栈帧中创建Lock Record（Displaced Mark Word），包含了对象原来的Mark Word拷贝。加锁成功后，对象头的Mark Word被替换为指向该Lock Record的指针，锁标志位变成00。解锁时，线程用CAS把Lock Record里保存的原Mark Word换回去。如果替换成功，说明没有竞争发生，整个加解锁过程就结束在用户态；如果替换失败，说明有其他线程在竞争，锁已经膨胀为重量级锁，解锁时还需要唤醒阻塞的线程，并把锁状态改为无锁。
2.4 重量级锁：Monitor与ObjectMonitor
当锁膨胀为重量级锁，Mark Word里存的就不再是Lock Record的指针，而是堆中Monitor对象的指针。这个Monitor基于操作系统的互斥量实现，是synchronized保证互斥的最终依靠。
HotSpot里，这个Monitor对应ObjectMonitor对象，它内部维护了几个关键队列：
_owner：指向当前持有锁的线程_EntryList：等待获取锁的线程队列_WaitSet：调用了wait()后进入等待状态的线程队列
整个抢锁流程是这样的：多个线程竞争时，没抢到锁的线程会通过enter操作进入EntryList排队，状态为阻塞（BLOCKED）。持有锁的线程调用wait()时，会释放Monitor并将自己放入WaitSet，状态为等待（WAITING）。持有锁的线程执行完同步块后，通过exit操作唤醒EntryList中的队首线程来重新竞争锁。
这里有个值得记的面试细节：synchronized的wait/notify机制本质上就是ObjectMonitor管程模型。为什么wait()和notify()必须放在synchronized块里调用？因为这两个操作需要操作对象的Monitor，如果没持有Monitor就调用，会抛出IllegalMonitorStateException。理解了ObjectMonitor的存在，这个问题就不再需要死记硬背了。
3. JIT阶段的隐藏优化：锁消除和锁粗化，你可能一直用的synchronized根本不是你以为的那个
聊完对象头和锁升级，很多人会默认synchronized的优化就到这了。但实际上，从字节码到真正被CPU执行，中间还隔着一道JIT编译优化，这里还有两个针对synchronized的深度优化：锁消除和锁粗化。这两个优化发生在即时编译阶段，对开发者透明，但理解它们能帮你写出更“懂事”的并发代码。
3.1 锁消除：逃逸分析认定“没必要加锁”
锁消除完全依赖逃逸分析的结论。如果JIT通过逃逸分析发现一个锁对象只会被当前线程访问，不会被其他线程捕获（也就是变量不逃逸出方法或线程），那么加锁操作就是多余的，JIT会直接将锁消除。
最经典的触发场景就是StringBuffer。StringBuffer的所有append方法都是synchronized的，但如果在一个方法内部新建一个StringBuffer，只是做局部字符串拼接，这个StringBuffer没有逃逸出方法，JIT就会消除掉所有append的锁。
java复制public String concat(String a, String b) {
StringBuffer sb = new StringBuffer();
sb.append(a);
sb.append(b);
return sb.toString();
}
这段代码在开启逃逸分析时，JIT编译阶段生成的机器码里根本没有monitorenter指令。不过要注意，锁消除存在一个前提：这段代码必须被JIT编译成机器码后才会生效，解释执行阶段仍然会老老实实加锁。所以它更多是一种JIT层面的优化结果，而不是编码时可以依赖的特性。一个比较粗暴的判断标准是：如果锁对象在被保护的方法内部创建，且没有作为返回值或参数传递出去，锁消除大概率会命中。
3.2 锁粗化：把多次细粒度加锁合并成一次
跟锁消除相反，锁粗化针对的是“相邻的多个同步块操作同一个锁对象”的场景。这种情况下，反复加锁解锁反而会带来额外开销，JIT会把多个相邻的同步块合并成一个大的同步块，减少加解锁次数。
java复制public void demo() {
synchronized (lock) {
doA();
}
synchronized (lock) {
doB();
}
synchronized (lock) {
doC();
}
}
如果三个同步块之间没有其他不被锁保护的逻辑，JIT可能将其粗化为一次加锁，把整个方法体都纳入锁保护范围。这种优化对性能有正向帮助，但也带来一个副作用：如果doA和doB之间存在耗时的非临界区操作，锁持有时间会被拉长，反而增加锁竞争的概率。所以从编码习惯上，我们依然应该主动缩小同步块的范围，不能因为存在锁粗化就故意任意扩大同步区域。
3.3 逃逸分析关掉会怎样
逃逸分析是锁消除和偏向锁合并分析的基础。有些团队为了排查问题会加上-XX:-DoEscapeAnalysis关闭逃逸分析，这时候StringBuffer拼接场景的锁消除就会失效，局部对象所有方法调用都会保留加锁逻辑。实测下来，一个高频调用的局部字符串拼接方法，在关闭逃逸分析后吞吐量能明显下降几个百分点。这也从反面验证了JIT阶段这些优化的真实存在和实际价值。
4. 内存屏障：synchronized底层凭什么能保证可见性和有序性
对象头解释了synchronized怎么记录锁状态，Monitor解释了它怎么实现互斥，但这两个机制加在一起，还不能完整回答另一个面试高频问题：synchronized凭什么能保证线程间的可见性和有序性？
答案的钥匙在内存屏障（Memory Barrier）身上。这就要稍微跳出JVM，看一眼硬件层和内存模型了。
4.1 Java内存模型与CPU缓存之间的那层墙
现代CPU都有多级缓存，线程操作变量时不会直接读写内存，而是先把数据加载到自己的L1/L2 Cache里，操作完再写回主存。在多核场景下，这会产生缓存不一致问题。为了解决这个问题，CPU层面引入了缓存一致性协议（如MESI），但缓存一致性协议只保证单个缓存行的最终一致，并不直接保证程序执行顺序的可控性。
Java内存模型（JMM）规定了主内存和工作内存之间的交互规则，其中八种原子操作（lock、unlock、read、load、use、assign、store、write）描述了线程如何读写变量。而要真正禁止指令重排序、保证有序性，靠的就是在关键位置插入内存屏障指令来约束编译器和CPU的行为。
4.2 内存屏障的四种类型和synchronized的落点
内存屏障一共分四类：
- LoadLoad Barrier：保证屏障前的读操作先于屏障后的读操作完成
- StoreStore Barrier：保证屏障前的写操作先于屏障后的写操作完成
- LoadStore Barrier：保证屏障前的读操作先于屏障后的写操作完成
- StoreLoad Barrier：全能屏障，保证屏障前的写操作先于屏障后的读操作完成
synchronized的锁定和解锁，在底层会分别插入相应屏障。具体来说，synchronized块内的写操作，在退出同步块释放锁时，会插入StoreStore屏障，确保同步块内的修改在释放锁之前对其他线程可见；而进入同步块获取锁时，会插入LoadLoad屏障，确保能够读取到其他线程在释放锁时写入的最新值。
把这层逻辑翻译成人话就是：解锁时把本线程工作内存中修改的变量强制刷新到主内存，加锁时把本线程工作内存中涉及到的变量从主内存重新读取。这就是synchronized保证可见性的硬件基础。
4.3 为什么synchronized不能完全替代volatile
既然synchronized已经包含了内存屏障，那是不是所有volatile场景都能用synchronized替代？从可见性层面确实可以，但从使用成本、语义粒度和编码复杂度上差距很大。volatile本质上是给单个变量加读写屏障，开销远小于synchronized的Monitor操作。更关键的是，volatile本身只是禁止重排序和保证单变量可见性，它不保证复合操作的原子性；而synchronized是通过锁来保证整体互斥，语义上两者并不等价，所以也不存在谁替代谁的线性关系。
4.4 内存屏障和锁升级的配合：自旋时的缓存一致性
还有一个经常被忽略的交叉点：轻量级锁的自旋操作，其实是基于CPU的CAS指令完成的，而CAS指令在x86架构上往往通过Lock前缀加内存屏障实现。换句话说，每一轮CAS自旋都不是一次简单的内存读取，而是一次原子读改写操作，会触发缓存一致性协议对整个缓存行执行无效化操作。如果多个线程同时自旋抢同一个锁，会导致缓存行在多个CPU核心间反复跨越（缓存行抖动），性能损耗不可小觑。这是高并发场景下synchronized性能不如显式Lock的一个硬件层面的重要原因。
5. 顺带把面试常问的几个延伸问题一次理清
synchronized作为Java面试八股里的常客，除了本身机制，还经常连带被问到几个容易混淆的问题。这块也值得花点篇幅单独聊聊，因为它们往往是区分“背过八股”和“真正理解锁机制”的分水岭。
5.1 synchronized和ReentrantLock到底怎么选
这个问题看起来是被说滥了，但很多人只记住“ReentrantLock更灵活、支持超时/可中断/公平锁”，却说不清底层差异。
从锁的实现维度看，synchronized走的是对象头的锁升级路径，代码层面由JVM统一管理；ReentrantLock是基于AQS（AbstractQueuedSynchronizer）实现的，核心是一个volatile修饰的state变量加CLH变体队列，加锁实际是通过CAS修改state值实现的。
从性能角度看，在JDK 6之后两者在无竞争场景下差距已经很小，但synchronized在低竞争场景下得益于偏向锁和轻量级锁，往往更快；高竞争场景下两者的表现取决于具体实现和JIT优化。
我的实操建议很简单：能用synchronized就不碰ReentrantLock，除非你需要超时中断、尝试获取等synchronized本身不支持的语义。因为synchronized的语义由JVM统一管理，未来优化空间更大；而ReentrantLock一旦引入，所有加锁解锁都要手动保证finally释放，容易出生产事故。
5.2 synchronized是分布式锁吗
这里说得直白一点：synchronized只能管住单个JVM进程内部的线程。在单体应用里，一个JVM只有一个进程，多个线程竞争同一个对象锁，能保证互斥；但在分布式场景下，请求会落在多台机器上的多个JVM进程里，每个进程持有各自的对象实例，synchronized锁的是各自进程内的同一个类或同一个全局对象，根本无法跨进程互斥。
真正的分布式锁需要有中心化存储，比如Redis的SETNX、ZooKeeper的临时顺序节点、数据库唯一索引等。理解了synchronized的进程边界之后，再看网上那些“redis分布式锁面试题”就会豁然开朗——分布式锁解决的根本不是线程竞争问题，而是多个进程之间的资源竞争问题。
5.3 类锁和实例锁的区别
synchronized修饰静态方法和修饰实例方法，锁的粒度完全不同。修饰实例方法锁的是当前实例对象，不同实例之间互不干扰；修饰静态方法锁的是类的Class对象，所有实例共享一把锁。
一个容易被忽略的坑是：如果一个类既有静态synchronized方法，又有实例synchronized方法，那么一个线程调用静态方法、另一个线程调用实例方法时，它们锁的对象不同，不会互斥。如果业务上需要这两种方法之间也互斥，必须显式指定同一个锁对象，比如用Class对象统一做同步。这个细节在真实项目里踩过的人不少，值得特别提一句。
5.4 JVM参数相关的调优姿势
最后分享一个调优层面的工具技巧。如果线上出现了锁竞争导致的性能问题，可以先通过jstack导出线程dump，看大量线程是否阻塞在同一个Monitor地址，然后结合jstat -gcutil观察GC情况。定位到具体锁对象后，可以从这几个方向动手：
- 确认锁粒度是否过大，能否缩小临界区
- 确认是否可以降低锁竞争频率，比如用ThreadLocal替代共享变量
- 确认是否可以通过读写分离减少读多写少场景的互斥
- 如果确定偏向锁的撤销是主要矛盾，考虑
-XX:-UseBiasedLocking - 监控自旋消耗，必要时调整
-XX:PreBlockSpin（在自适应自旋开启前的老参数）
这些手段能覆盖绝大多数线上synchronized性能优化需求。
我个人做并发编程这些年，最大的体会是：锁这个东西，从抽象层面看就是一把锁，但落到不同层次，它的存在形式千差万别——在字节码层是monitorenter，在对象头里是一串bit位，在JIT编译后是消除或粗化的优化点，在处理器层面是一条条内存屏障指令。只有把这条链路完整串起来，才能真正看懂Java并发编程里关于synchronized的一切。以后再有人问你synchronized是怎么实现的，你就不只是回答“对象头里有Mark Word”这么简单了，而是能从对象内存布局讲到锁升级，再讲到Monitor阻塞队列，最后用内存屏障解释可见性和有序性的根基，一气呵成。