在Java并发编程中synchronized关键字无疑是最基础、最常用的同步工具。很多新手对它的认知可能还停留在“重量级锁”“性能一般”的层面但实际上JDK1.6之后synchronized进行了重大优化引入了偏向锁、轻量级锁、重量级锁三种状态并且会根据线程竞争的激烈程度自动实现锁的升级也叫锁的膨胀。锁升级的核心目的是在不同的并发场景下实现性能最优——没有竞争时用开销最小的锁竞争加剧时逐步升级到更稳健的锁避免“杀鸡用牛刀”也防止“小锁扛不住大并发”。今天就带大家一步步拆解这三种锁的本质、实现原理、适用场景以及它们之间的升级逻辑看完这篇你对synchronized的理解会更上一个台阶。前置认知为什么需要锁升级在JDK1.6之前synchronized的实现依赖于操作系统的互斥量Mutex Lock这种锁属于重量级锁。重量级锁的问题很明显每次获取和释放锁都需要切换用户态和内核态而这种切换的开销非常大哪怕是在没有线程竞争的场景下也会造成不必要的性能损耗。开发者发现在实际开发中大多数场景下锁的竞争其实是“温和”的要么只有一个线程反复获取锁无竞争要么只有少量线程交替获取锁轻度竞争真正需要大量线程同时争抢锁重度竞争的场景并不多。基于这个发现JDK1.6引入了锁升级机制从开销最小的偏向锁开始根据竞争情况逐步升级到轻量级锁、重量级锁让锁的性能适配不同的并发场景实现“按需分配”这也是synchronized性能大幅提升的关键。补充一个核心前提锁升级是不可逆的一旦从偏向锁升级到轻量级锁就不能再回退到偏向锁一旦升级到重量级锁就只能一直保持重量级锁状态这一点一定要记牢。一、偏向锁无竞争场景的“最优解”1. 核心场景当只有一个线程反复获取、释放同一把锁没有任何其他线程参与竞争时就会使用偏向锁。比如单线程执行同步代码块、单线程操作线程安全集合等场景偏向锁能最大限度减少锁的开销。2. 核心原理偏向锁的核心思想是“偏心”——既然只有一个线程在使用锁那就把这把锁“绑定”给这个线程后续这个线程再获取锁时不需要做任何同步操作不用CAS、不用切换内核态直接就能获取锁开销几乎可以忽略不计。具体实现上JVM会在对象头Mark Word中记录当前持有锁的线程ID当线程再次进入同步代码块时只需要检查对象头中的线程ID是否和当前线程ID一致如果一致直接进入同步代码块无需任何额外操作如果不一致再尝试升级为轻量级锁。3. 优势与不足优势开销极小几乎可以忽略不计适合无竞争的单线程场景是JDK1.6之后synchronized的默认锁状态默认开启偏向锁可通过JVM参数关闭。不足一旦有其他线程参与锁竞争就需要撤销偏向锁触发锁升级这个撤销过程会有一定的开销所以偏向锁不适合多线程竞争的场景。二、轻量级锁轻度竞争场景的“过渡方案”1. 核心场景当有少量线程交替获取锁没有同时争抢即“自旋竞争”此时偏向锁已无法满足需求会升级为轻量级锁。比如两个线程交替执行同步代码块没有同时进入临界区的情况。这里要注意轻量级锁的“轻量”是相对于重量级锁而言的——它不需要切换内核态而是通过CAS操作来实现锁的获取和释放开销远小于重量级锁。2. 核心原理当有新线程尝试获取锁发现锁已经是偏向锁被其他线程持有就会触发偏向锁撤销然后升级为轻量级锁。具体过程如下线程在进入同步代码块前会在自己的栈帧中创建一个“锁记录”Lock Record记录锁对象的Mark Word副本线程通过CAS操作将锁对象的Mark Word更新为自己的锁记录地址如果CAS操作成功说明线程获取到了轻量级锁进入同步代码块如果CAS操作失败说明有其他线程正在持有锁轻度竞争当前线程会进入“自旋”状态不断循环尝试CAS获取锁而不是直接阻塞。这里的“自旋”是轻量级锁的关键因为线程阻塞/唤醒的开销很大而轻度竞争时线程持有锁的时间通常很短自旋几次就能获取到锁比阻塞更高效。3. 优势与不足优势无需切换内核态通过CAS和自旋实现锁竞争开销远小于重量级锁适合轻度竞争场景。不足自旋会消耗CPU资源如果锁被持有时间过长自旋就会变成“无效消耗”此时会触发锁升级为重量级锁另外轻量级锁只适合少量线程竞争多线程同时争抢时自旋会导致CPU利用率飙升。三、重量级锁重度竞争场景的“终极保障”1. 核心场景当有大量线程同时争抢同一把锁重度竞争或者锁被持有时间很长自旋已经无法高效获取锁时轻量级锁会升级为重量级锁。比如多线程同时读写同一个共享资源频繁争抢锁的场景。重量级锁就是我们JDK1.6之前的synchronized实现依赖于操作系统的互斥量Mutex Lock属于内核态锁。2. 核心原理重量级锁的核心思想是“阻塞等待”——当线程获取锁失败时不再自旋而是直接放弃CPU执行权进入操作系统的阻塞队列等待队列直到持有锁的线程释放锁操作系统才会唤醒队列中的线程重新竞争锁。具体来说当轻量级锁的自旋次数达到阈值JVM默认是10次可通过参数调整或者自旋过程中又有新线程加入竞争就会升级为重量级锁锁对象的Mark Word会被设置为“重量级锁标记”指向操作系统的互斥量获取锁失败的线程会被操作系统阻塞放入阻塞队列持有锁的线程释放锁时会通知操作系统唤醒阻塞队列中的一个线程让其重新尝试获取锁。3. 优势与不足优势稳定性高能应对大量线程的重度竞争不会出现自旋导致的CPU浪费是并发场景下的“终极保障”。不足开销最大每次获取、释放锁都需要切换用户态和内核态线程阻塞/唤醒的开销也很大适合重度竞争场景不适合轻度竞争或无竞争场景。四、锁升级的完整流程不可逆结合上面的内容我们用一张清晰的流程总结锁升级的完整逻辑建议收藏初始状态锁对象刚创建时处于“无锁状态”Mark Word中没有记录任何线程信息升级为偏向锁当第一个线程获取锁时无竞争锁升级为偏向锁Mark Word记录该线程ID升级为轻量级锁当有第二个线程尝试获取锁偏向锁被撤销锁升级为轻量级锁线程通过CAS自旋竞争锁升级为重量级锁当线程竞争加剧自旋阈值达到、多线程同时争抢轻量级锁升级为重量级锁线程阻塞等待锁释放。核心记住无锁 → 偏向锁 → 轻量级锁 → 重量级锁一旦升级无法回退。五、实战总结如何利用锁升级优化并发代码理解了锁升级的逻辑我们在实际开发中就可以根据场景优化代码让锁的性能达到最优尽量减少锁的竞争比如缩小同步代码块范围只锁需要同步的代码不锁无关代码避免大量线程同时争抢同一把锁适配无竞争/轻度竞争场景如果是单线程或少量线程交替执行的场景无需额外操作JVM会自动使用偏向锁/轻量级锁无需手动优化避免轻量级锁自旋浪费如果锁持有时间较长比如同步代码块中有IO操作、循环耗时操作建议直接使用重量级锁可通过JVM参数关闭偏向锁/轻量级锁避免自旋消耗CPU避免过度同步如果不需要同步的代码不要加synchronized避免不必要的锁开销。最后常见误区澄清误区1synchronized就是重量级锁错JDK1.6之后synchronized有三种锁状态会自动升级大部分场景下性能并不差误区2偏向锁一定比轻量级锁好错偏向锁适合无竞争场景有竞争时偏向锁的撤销开销反而比轻量级锁大误区3自旋次数越多越好错自旋次数过多会消耗CPUJVM默认的10次自旋是平衡了性能和开销的最优值一般不建议手动修改。总结Java锁升级的本质是JVM对并发场景的自适应优化——根据线程竞争的激烈程度动态调整锁的状态在“性能”和“稳定性”之间找到最优平衡点。偏向锁适配无竞争轻量级锁适配轻度竞争重量级锁适配重度竞争三者的升级流程不可逆共同构成了synchronized的高效实现。理解了锁升级的逻辑不仅能帮我们写出更高效的并发代码还能在排查并发性能问题时快速定位锁相关的瓶颈。希望这篇博客能帮你彻底搞懂Java锁升级下次再用synchronized时就知道它背后的“进化”逻辑啦