synchronized锁升级与JMM：Java并发性能问题的因果探秘

先有鸡还是先有蛋？Java并发编程中的锁升级与内存模型

有朋友前两天在群里发了个线上问题：某个接口加了synchronized，布到生产上观察到大量线程阻塞，RT从15ms涨到500ms。他一开始怀疑是锁竞争太激烈，但压测数据又显示并发量并不高，于是跑来问我，是不是该换成ReentrantLock加超时，或者上ConcurrentHashMap分段锁？

我让他先别急着换锁，把线程dump拉出来看了看，然后问了一句：“你的临界区里做了什么？”他说就是读一个配置，然后做简单校验。我说那你这就是典型的锁升级没升上去，反而被打回原形了，和“鸡生蛋还是蛋生鸡”是一个道理——你以为是锁实现的问题，实际上是内存模型和锁状态之间互相牵制的结果。

这让我决定把这块东西彻底讲透。Java并发里，synchronized的锁升级路径、JMM的可见性保障、死锁检测与逃逸分析三者之间的因果链，是我见过最多人一知半解的部分。尤其到了JDK 8以后的版本，偏向锁、轻量级锁、重量级锁这条升级链路已经非常成熟，但很多人理解的还是教科书上“线程竞争就往上升级”的旧模型，边界条件一变，就直接翻车。

这篇文章不打算从“什么是锁”开始讲，那是入门书干的事。重点放在三件事：锁升级这条链路的实际触发边界、JMM在锁升级背后扮演的角色、以及你在生产环境里如何通过可观测量来判断锁到底处于哪个状态。最后给几个实战参数和排查命令，你照着做至少不用再靠猜来调并发问题。

1. 锁升级不是“一层一层往上爬”：先厘清三个状态的真实触发条件

很多人背过这个口诀：偏向锁 → 轻量级锁 → 重量级锁，有竞争就升级，没竞争就降级。这句话方向没错，但忽略了一个致命细节——锁的升级不是线性的“遇到竞争就立马往上跳”。

synchronized在JVM里的实现是围绕对象头Mark Word做的。Mark Word里存的东西会根据锁状态复用，64位JVM下对象头结构大致可以分成这么几种情况：

看到没有，锁标志位是不同的：无锁和偏向锁都是01，轻量级是00，重量级是10。真正决定状态切换的是标志位加Mark Word里的内容。

偏向锁的触发条件不是“只有一个线程访问”，而是“同一线程反复进入同步块”。它优化的是那种Vector、StringBuffer、Hashtable里单线程误用同步块的场景——锁实际上没被竞争，但每个方法都是synchronized的。

轻量级锁的触发条件是“第二个线程来抢同一个对象的锁”，但两个线程是错开执行的——也就是CAS自旋能成功。它不是被“抢”下来的，而是通过CAS把Mark Word替换成指向自己线程栈中Lock Record的指针。

重量级锁的触发条件才是真正“有人在同时抢”，CAS自旋失败后，向内核申请mutex，线程进入阻塞。

理解了这三个状态的触发条件，你再看前面那个朋友的案例：他那个同步块里就是读配置加校验，理论上完全可以在轻量级锁甚至偏向锁阶段完成，但为什么线上大量阻塞？答案往往出在两个地方：锁降级机制在批量重偏向被关闭后不再生效，或者他的临界区里出现了阻塞点（比如IO），导致持锁时间过长。

1.1 偏向锁的“黑历史”与批量重偏向的实际边界

这里必须提到偏向锁的一个转折——JDK 15里JEP 374把偏向锁默认禁用了，JDK 18彻底废弃。为什么？因为偏向锁带来的收益在大多数现代应用里已经不重要了，反而制造了大量复杂的撤销逻辑。

但如果你还在用JDK 8/11，偏向锁默认开启。它的核心机制里有几个边界条件值得注意：

• 偏向锁延迟：JVM启动后默认4秒内偏向锁不生效（BiasedLockingStartupDelay，默认4000ms），因为启动阶段大量对象会被多个线程访问，这时候偏向反而拖慢速度。
• 批量重偏向（bulk rebias）：当一个类的对象被多个线程轮流访问时，单个线程不再独占，JVM会统计撤销次数，达到阈值（默认20，-XX:BiasedLockingBulkRebiasThreshold）后触发批量重偏向，让新线程抢到偏向锁。
• 批量撤销（bulk revoke）：如果撤销次数继续增加（默认40，-XX:BiasedLockingBulkRevokeThreshold），JVM会认为这个类的偏向锁弊大于利，直接撤销整个类的偏向锁设置，之后该类的所有对象都走轻量级锁。

我见过不少人写多线程代码时，测试环境一切正常，上生产就出问题。一个可能的原因就是：测试环境的流量模式恰好满足偏向锁条件，生产环境流量大且随机，批量重偏向疯狂触发，每次撤销偏向锁都伴随一次STW（安全点），吞吐量直接掉一半。

重要提示：如果线上使用JDK 8/11且出现大量偏向锁撤销，建议考虑显式关闭偏向锁（-XX:-UseBiasedLocking）或者直接升级到JDK 15+。尤其是高并发、多线程竞争明显的应用，偏向锁优化已经没有意义，反而增加撤销开销。

1.2 锁降级的真实存在：重量级锁怎么变回轻量级

先澄清一个概念：偏向锁是可以被撤销的，但偏向锁不存在“降级”回无锁的说法——它本身就是一种无竞争状态下的优化。所谓锁降级通常发生在重量级锁释放后，Monitor中的等待队列清空，JVM可能在后续竞争中直接以轻量级锁重新加锁，而不是继续使用Monitor。

但严格说，HotSpot并没有在运行中主动把重量级Monitor降级成轻量级锁的机制。重量级锁一旦被使用，该对象头里的Monitor指针就会被保留，直到对象被GC回收。所以准确的说法是：同一对象在后续被不同线程竞争时，可能重新走一遍轻量级锁加锁流程，但前提是锁已释放，且没有线程在Monitor中阻塞。

这里就引出那个“先有鸡还是先有蛋”的核心命题了——你无法脱离内存模型来理解锁的状态切换。锁升级的所有CAS操作，本质都是在利用JMM的原子性保证和内存屏障来实现可见性。

2. JMM内存屏障是锁升级的“地基”：CAS和Monitorenter背后的屏障指令

谈JMM，很多人只知道volatile和happens-before规则，觉得synchronized就是“进去加锁，出来解锁”，不需要关心底层。但锁升级恰恰是依赖内存屏障来保证正确性的。

Java内存模型定义了8种操作（lock、unlock、read、load、use、assign、store、write），但在HotSpot的实现层，这套操作最终都要落到CPU指令的内存屏障上。锁升级里的每一次CAS操作，在现代CPU上对应的是lock前缀指令——它在x86上自带全屏障（full barrier）语义。

x86是一个强内存模型（TSO，Total Store Order），它只允许写缓冲区的存在。所以x86上JMM需要的4种内存屏障（LoadLoad、LoadStore、StoreStore、StoreLoad）里，只有StoreLoad需要单独的mfence或lock前缀指令来实现，其他三个都被CPU硬件天然满足了。这也就是为什么在x86上跑Java并发程序，很多可见性问题不容易暴露。

但如果你是搞底层工具的，比如写JNI、用Unsafe、或者研究ARM架构下的JVM，那这套就不一样了——ARM是弱内存模型，volatile得显式发dmb指令，锁升级的CAS也要额外配内存屏障。也就是说，同一个锁升级流程，在x86上可能只是CAS加个lock前缀，在ARM上要加两层屏障。

2.1 从happens-before看锁的“鸡生蛋”问题

JMM的happens-before规则里有一条锁规则：解锁操作happens-before后续对同一把锁的加锁操作。这句话翻译成人话就是：线程A解锁后，线程B获取到同一把锁，那么A在锁内写入的所有共享变量，B加锁后一定能看到。

但这里有个反直觉的细节——同一个线程重复加同一把锁（也就是可重入）时，JMM怎么保证？偏向锁、轻量级锁的实现里，可重入靠的是计数器加Lock Record重入标记，不涉及锁竞争。这种情况下happens-before规则“不适用”，因为读取和写入发生在同一线程内，天然有序。

那如果是一个对象先被线程A访问（偏向锁），然后被线程B访问（需要撤销偏向）呢？这时候JMM靠的就不是锁规则了，而是CAS本身的volatile语义。Mark Word的读取和修改本身就是volatile读/写，所以撤销偏向锁并重新CAS设置新线程ID的过程，天然具备volatile的可见性保证。

这张表能帮你快速定位：当你怀疑“是不是锁没生效导致可见性问题”时，先判断你的并发访问模式匹配哪一行，再决定看锁状态还是看内存屏障。

2.2 内存模型如何决定锁升级的路径选择

锁升级的每个状态切换都必须保证内存的可见性。举个例子：

• 偏向锁加锁：通过CAS把线程ID写入Mark Word。这个CAS必须保证之前的字段写入对后续获取锁的线程可见吗？不需要——如果后续是同一线程，自热可见；如果是另一个线程，偏向锁会被撤销，走轻量级流程，那轻量级锁的CAS会带着lock前缀去发布。
• 轻量级锁加锁：在栈上创建Lock Record，然后CAS试图把对象头的Mark Word复制到Lock Record中，再把Mark Word指向Lock Record。这个操作需要全屏障，因为Lock Record里保存了原Mark Word和其他线程可能需要读取的数据。
• 重量级锁加锁：进入Monitor前，线程要做一次原子操作把对象头替换为Monitor指针，之后进入管程队列等待。管程协议里，锁释放会隐含发布所有在锁内写入的共享变量。

所以锁升级的“升级”路径从来不是随意选的——它必须保证每一次升级后，后续观察者看到的对象状态（Mark Word内容）和临界区内共享变量的状态是一致的。从这个意义上说，是内存模型决定了锁升级的边界条件，而不是锁状态本身。

这就是“先有鸡还是先有蛋”的答案：你看着是锁在起作用，但锁每一次状态切换都依赖JMM的屏障指令；反过来，JMM的happens-before规则很多地方又借由锁来落地。两者互为前提，缺一不可。

3. 锁升级边界上的常见坑：重入、对象头hashCode与逃逸分析

如果你已经理解了锁升级和内存模型的底层关系，再去看工具书里的“锁升级条件”，你会发现很多边界条件其实隐藏在对象的生命周期里。下面几个坑是我在实际项目中踩过，也经常在答疑时看到的。

3.1 对象头hashCode：算一次，偏向锁就废了

这可能是最隐蔽的坑。一旦对象调用了Object.hashCode()并且结果被写入对象头（identity hash code），该对象就无法进入偏向锁状态。

原因是对象头里存身份hashCode的位置（31位）和偏向锁存线程ID的位置冲突了。偏向锁把整块空间拿来放线程ID，就没地方放hashCode。所以JVM规定：如果对象在被偏向锁定之前已经计算过identity hashCode，偏向锁直接不可用——加锁时直接偏向锁给该对象禁用，走轻量级锁。

为什么说这个坑很多人踩？因为大量框架底层会调用System.identityHashCode或Object.hashCode，比如：

• ConcurrentHashMap的ThreadLocalRandom种子，或者对象作为key塞进HashMap时，第一次hash()后hashCode被缓存；
• IdentityHashMap、WeakHashMap的桶定位，直接依赖identity hash；
• ArrayList、StringBuilder的迭代器Itr里也包含对象的hash调用。

一旦这些对象后来又被synchronized锁定，比如代码里写list.stream().forEach(...)，而集合对象算过hashCode且是局部变量被多个线程共享——好嘛，偏向锁直接失效，每次都走CAS轻量级锁。如果恰好两个线程同时跑，CAS失败就立刻升级成重量级锁。

注意：重写hashCode()方法不影响这条规则。这里说的是默认的Object.hashCode()，由JVM生成的身份哈希，它不会调用你的业务逻辑。你在这个对象上加synchronized时，JVM检查身份哈希是否已经算过。

3.2 逃逸分析彻底消灭同步：锁可能根本没生成

你以为代码里写了synchronized就一定有锁？别急，如果JVM通过逃逸分析确定锁对象不会逃逸出当前线程，它直接把整个同步块消除了——这就是锁消除（Lock Elision）。

锁消除底层依赖逃逸分析。逃逸分析会在JIT编译阶段分析对象的作用域：如果一个对象只在一个线程内被访问，没有被其他线程引用，那么monitorenter/monitorexit就变成了“自己锁自己”，完全没必要。JIT会直接移除锁的字节码指令。

这种场景最常见的就是字符串拼接，Java编译器对StringBuilder的优化：比如String s = a + b + c，编译后是new StringBuilder().append(a).append(b).append(c).toString()。StringBuilder内部方法大多是synchronized的，但中间的StringBuilder对象根本不会逃逸出这个方法，JIT判定后把锁全剃掉了。

回到应用的深层价值：如果你手动加锁的临界区对象只在单线程中被访问，写再多synchronized也是白搭，因为JIT可能只留下代码逻辑，锁的指令根本没进入机器码。反过来，如果你担心锁性能影响，又依赖锁来保证可见性，就要谨慎依赖锁消除——编译器可能把你的锁给优化没了。如果发生这种情况，且你原本是靠锁的happens-before来传递变量可见性，那并发bug就来了，而且极其难查。

一种容易踩的锁消除误用是计数器场景：

java复制public class MessageProcessor {
    private int doneCount = 0;
    
    public synchronized void onMessage() {
        // 处理消息
        doneCount++;
    }
    
    public int getDoneCount() { return doneCount; }
}

多个线程在onMessage()里调用，但getDoneCount()没加锁，可见性得不到保证。你以为synchronized避免了所有问题，其实只保住了写入路径。更好的做法是用AtomicInteger或者把读取也加上synchronized，否则就是“半个锁”方案。

3.3 竞争模式与自旋策略的适配

锁升级过程中，自旋是一个跨在所有升级路径上的重要行为。轻量级锁加锁失败后，不会立刻膨胀成重量级锁，而是先自旋一段短暂的时间（默认自适应自旋）。自旋解决的问题是：第二个线程稍等一下，第一个线程可能很快就释放锁了。

自旋策略不是每次固定转10次那样简单，HotSpot的自适应自旋会根据历次在同一对象锁上自旋的成功率动态调整自旋次数。它在竞争中成功了，下次就多自旋一会儿；连续失败，下次就少自旋甚至不自旋。

关键边界在于：自旋是基于“锁持有时间短”这个假定的。如果临界区很长，被阻塞的线程自旋就浪费CPU；如果临界区极短（几十条指令），自旋是划算的。你在代码里能做的调整：

• 保持临界区短小，避免在锁内执行IO、网络、加解密等耗时操作；
• 同步块内的代码尽量只做核心共享数据修改，把非共享操作移出锁外；
• 如果临界区必须有耗时操作，直接用ReentrantLock.lockInterruptibly()或者乐观锁方案，减少无谓的自旋阻塞等待。

对“鸡生蛋”的问题，多数并发问题的处理思路应该是全局看待锁和它保护的数据之间的互动关系，而不是只盯着某一把锁的加锁时间。

4. 生产环境锁状态观测与调优：从字节码到JFR的全链路排查看法

认知层面的边界条件讲清楚了，接下来是怎么在真实环境里看到锁的状态。很多并发问题排查不是靠猜，而是靠观测。这里提供几条经过实践检验的排查链路。

4.1 查看字节码和JIT编译产物，确认锁是否被消除

第一步：确认代码层面的synchronized是否真的会被JVM当锁执行。一个标准手段是用javap看字节码，另一个进阶手段是看JIT编译后的汇编指令。

bash复制# 查看字节码中的monitorenter/monitorexit
javap -c -l YourClass.class

# 查看JIT编译后的汇编（x86）
java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:+PrintCompilation 你的主类

如果JIT判定锁消除，你会看到PrintAssembly输出里没有lock cmpxchg相关指令，也不需要申请Monitor。但如果你的代码里应写锁的地方没有加锁，就会暴露无锁并发问题。

条件允许的话（生产环境建议只在灰度机开），锁对象的-XX:+PrintAssembly在同一对象多次竞争情况下，可以观察是否生成了monitorenter对应的lock cmpxchg指令（轻量级），或者call到ObjectMonitor::enter（重量级）的调用。

4.2 用jstack、jcmd和JFR衡量锁持有与阻塞时间

第二步：观察锁竞争是否严重、阻塞时间长短。老派做法是jstack打线程dump，看大量java.lang.Thread.State: BLOCKED (on object monitor)或WAITING (parking)。

现代JVM更推荐用Java Flight Recorder（JFR）的事件来定位锁竞争来源。两个核心事件：

• jdk.JavaMonitorEnter：记录线程等待进入管程的时长；
• jdk.JavaMonitorWait：记录在Monitor上wait时长。

开启方法是在启动命令里加-XX:StartFlightRecording=filename=lock.jfr,settings=profile，然后跑业务，最后用jfr print或者JDK Mission Control分析。

我在实测中遇到过一个问题：线上服务锁竞争严重，但jstack看不到Blocked线程，反而看到大量Runnable状态。查了一圈后发现是线程在循环里自旋抢锁失败，导致CPU飙高，但线程还没进入Blocked状态。这就是走了偏向锁撤销和轻量级锁自旋路径。JFR的jdk.ThreadPark事件记录的是LockSupport.park的调用，能反映这类自旋竞争。

4.3 判断偏向锁行为是否影响你的应用

如果你用的是JDK 8/11，想确认偏向锁是否在制造额外成本，可以看GC日志里的STW频率，或者用-XX:+PrintFlagsFinal确认当前阈值：

bash复制java -XX:+PrintFlagsFinal -version | grep -iE "Biased|Spin|Threshold"

如果发现偏向锁相关撤销频繁，可考虑加-XX:-UseBiasedLocking并重新压测；如果升级到JDK 15+，偏向锁默认关闭，那就不用管了。

JDK各版本锁行为对比可以帮你快速定位自己选型的位置：

很多人还在纠结“要不要关偏向锁”。我的观点是：**如果你确定应用存在明显的线程共享但竞争不激烈的场景（比如工作线程池的某些统计对象），在JDK 8/11上可以保留偏向锁；否则建议直接关掉偏向锁，省得在STW撤销上吃亏。**在JDK 15+上，就不需要操这个心了。

5. 关于“同步原语与并发模型”的一点个人心得与实际建议

说了这么多底层机制和锁状态，最后聊点更贴近开发日常的体会。锁升级和JMM这种偏底层的知识，看起来离业务代码很远，但很多线上怪问题都藏着这两层的影子。

前几天那哥们又来问，说按我说的加了-XX:-UseBiasedLocking后，RT降了，但从监控看仍有小幅波动。后来发现更核心的原因是：那个配置读取虽然只是读一次，但每次都要从远端配置中心拉取，网络抖动时会把持锁时间拉到几秒级，导致后续线程全部Block住。最后我们把配置缓存成了本地快照并用volatile发布，锁里只做内存读取，才真正解决问题。

这个教训可以扩展成三条很朴素但极其有效的经验：

第一，锁保护的临界区应当小到“只做必要的共享变量操作”。需要IO、RPC、远程配置的操作坚决不要放锁内。锁一旦跨了IO，它就不再是锁，而是一个排队阻塞的瓶颈。

第二，理解锁升级的边界，不是为了写炫技代码，而是为了在出问题时能明确往哪查。比如你能一眼判断出：这个问题是偏向锁撤销频繁导致的STW，还是自旋失败导致重量级膨胀，还是锁消除把一个本来需要同步的代码给“优化”没了。定位方向和排查手段完全不同。

第三，不要把锁和内存模型人为割裂看待。锁是JMM中可见性的一种实现方式，锁升级只是实现方式在竞争程度变化时的一种性能自适应。理解这层因果关系，就不会写出“反正加锁了，数据肯定一致”的天真代码。

如果你想系统验证今天的内容，我建议你找个小Demo，开多个线程反复加synchronized，同时开启JFR采集JavaMonitorEnter事件，去观察不同竞争强度下锁停留在哪个状态的时长分布。实践得出的感知远比看十篇文章都深刻。锁升级和JMM是一体两面，理解了边界条件之后，剩下的就是多压测、多观察，慢慢积累自己的经验直觉。