上周排查一个线上服务超时问题一帮人围着监控面板看了半天最后发现根源出在静态方法上的synchronized上。有个同学为了让一个静态计数器在多线程下不出错直接在静态方法上加了锁另一处代码为了访问同一批静态字段又用synchronized(类名.class)包了一层。两边看起来都锁了实际上都是在抢同一个类锁瞬间把原本能并行执行的请求全部串行化了。类似的问题我见过不止一次很多人对Java中synchronized实现类锁的两种方式理解得似是而非遇到性能瓶颈和诡异的阻塞就抓瞎。这篇就从头到尾把类锁的两种写法、底层原理和实战坑点梳理清楚适合已经写过一点并发代码、但对锁机制还停留在“能用就行”阶段的开发者。1. 类锁到底锁的是哪一个对象1.1 一个排查了很久的诡异场景先说个具体例子给你感受下。某个模拟项目X里有个支付统计服务里面定义了一个工具类专门记录订单处理次数public class OrderStat { private static long totalCount 0; public synchronized void addOrder() { totalCount; } public static long getTotalCount() { return totalCount; } }代码一上生产totalCount经常出现对不上的情况。乍一看addOrder()确实加了synchronized为什么还会丢更新原因很简单synchronized加在实例方法上锁的是当前实例对象。你每次处理订单都new OrderStat()每个线程拿着不同的实例进方法锁的根本不是同一个东西静态字段自然照抢不误。这类问题在代码评审里反复出现根子在于很多人没有意识到“synchronized锁的到底是哪个对象”。1.2 类锁的本体是Class对象类锁锁的不是某个具体的实例而是当前类的Class对象。JVM在类加载阶段会把字节码文件解析成一个Class对象这个对象存放在方法区或者元空间里表示整个类的类型信息。同一个类加载器加载同一个类全局只会有一份Class对象。所以你在静态同步方法上锁的、在synchronized(类名.class)里锁的都是这一个对象。类锁天然就是全局互斥的不管创建多少个实例只要类还是那个类所有线程就只能在同一个monitor前面排队。这跟对象锁有本质区别。对象锁锁的是堆里的人为创建的实例对象一个类可以new出无数个实例每一个都有自己独立的监视器monitor彼此井水不犯河水。比如说synchronized(this)锁的是当前对象两个线程只要用的是两个不同的实例就完全不会互相阻塞。类锁则不然它的锁对象是一个类的元信息载体具有唯一性。1.3 把类锁和对象锁想象成两套门禁系统用一个生活化的类比帮你理清关系。假设有一个商场商场本身有一扇总大门每个店铺还有自己的店门。类锁相当于是商场总大门的钥匙任何员工想进入商场区域都得先过总大门而对象锁相当于各店铺的独立店门你开A店的店门不会影响B店营业。多个店铺之间完全可以同时营业因为店门各不相同但总大门只有一扇一次只能让一个人通过。放在代码里就是你把synchronized加到静态方法上等于所有调用这个方法的人都必须拿同一把总大门钥匙你给不同实例的实例方法加锁等于每个店铺各自配了一把钥匙店铺之间没有任何竞争。很多人误以为“我加了synchronized就安全了”却没意识到加锁的对象选错了安全边界根本没有建立起来。理解这一点后面两种类锁的实现方式看起来就顺理成章了。2. 两种加锁姿势静态方法同步与Class代码块同步2.1 方式一在静态方法上用synchronized修饰这是最直接的写法直接在静态方法声明上加上synchronized关键字public class CounterService { private static int count 0; public static synchronized void increment() { count; } }当某个线程调用CounterService.increment()时JVM会检查方法上的ACC_SYNCHRONIZED标志如果设置了当前线程必须先成功获取CounterService.class这个Class对象对应的monitor才能进入方法体执行。方法执行完无论正常返回还是抛出异常monitor都会自动释放。这个过程对调用方是透明的你不需要手动写锁释放逻辑所以这种方式写起来最省心。它的特点简单粗暴整个方法体都是临界区粒度比较大。如果方法里只有一行代码更新静态变量那没问题但如果方法里还包含一些耗时的IO操作、远程调用或者复杂的计算逻辑所有调用线程都会被堵在方法入口并发能力直线下降。我曾经见过有人在一个静态同步方法里做读写数据库的批量操作结果线上服务吞吐量掉了一个数量级原因就是锁的粒度太大把大量不该互斥的操作也串行化了。2.2 方式二在同步代码块中锁住Class对象第二种方式更灵活可以在方法内部指定锁对象public class CounterService { private static int count 0; public static void increment() { synchronized (CounterService.class) { count; } } public void batchProcess(ListOrder orders) { // 这里不需要锁每个实例自己处理自己的逻辑 synchronized (CounterService.class) { // 只有修改共享静态资源时才需要加锁 } } }这段代码里线程进入synchronized(CounterService.class)块之前必须先取得CounterService.class这个Class对象对应的monitor离开代码块时释放。跟静态方法加锁相比代码块的方式把锁的控制范围精确到了某几行代码上临界区可以缩得很小。实际项目中我更推荐这种写法。你可以在一个方法里只对真正操作共享资源的那一小段代码加锁剩下的部分保持并行。比如一个方法前半段在做参数校验中间要更新静态配置后半段还要记录日志那只需要把“更新静态配置”这一小段包在类锁里。把锁范围缩小是成本最低的并发优化手段。2.3 两种方式的行为等价性与细微差别从锁的语义上讲两种方式完全等价它们锁的都是同一个Class对象会在同一个monitor上竞争。也就是说一个线程如果先执行CounterService.increment()静态方法加锁另一个线程想进入synchronized(CounterService.class)代码块一样会被阻塞因为两边用的是同一把锁。我在实际项目中做过一个对比实验同一个计数器分别用这两种方式改写压测结果没有本质区别。之所以说“细微差别”主要是可读性和可维护性上的差异对比项静态方法加锁Class代码块加锁锁对象隐藏的由JVM隐式判断显式的类名.class一看就懂临界区范围整个方法体可以精确控制到代码块灵活性低方法内无法部分并行高可以只锁必要片段字节码实现依赖方法级标志依赖monitorenter/monitorexit指令如果你只是为了给一个简单的静态方法加锁两种方式都可以选但如果方法体比较长建议优先考虑代码块方式。不要因为“静态方法加锁写起来省事”就把整个方法体都锁住这会让性能问题在流量上来之后突然爆发。3. 底层原理解析从字节码标志到对象头里的锁状态3.1 字节码视角下的两种实现差异把上面的两种代码分别编译用javap反编译能直观看到它们的底层差异。先看静态方法加锁的版本javap -v CounterService.class反编译后能看到关键标志public static synchronized void increment(); descriptor: ()V flags: (0x0029) ACC_PUBLIC, ACC_STATIC, ACC_SYNCHRONIZED Code: stack2, locals0, args_size0 0: getstatic #2 // Field count:I 3: iconst_1 4: iadd 5: putstatic #2 // Field count:I 8: return注意它的flags里多了一个ACC_SYNCHRONIZED而方法体内部没有任何加锁指令。JVM在方法调用阶段看到这个标志就会隐式地执行monitor的获取与释放操作。再看代码块加锁的版本public static void increment(); descriptor: ()V flags: (0x0009) ACC_PUBLIC, ACC_STATIC Code: stack2, locals2, args_size0 0: ldc #3 // class CounterService 2: dup 3: astore_0 4: monitorenter 5: getstatic #2 // Field count:I 8: iconst_1 9: iadd 10: putstatic #2 // Field count:I 13: aload_0 14: monitorexit 15: goto 23 18: astore_1 19: aload_0 20: monitorexit 21: aload_1 22: athrow 23: return Exception table: from to target type 5 13 18 any这段字节码里出现了monitorenter和monitorexit两个指令分别对应获取锁和释放锁。细心的读者会发现monitorexit出现了两次这不是冗余一次是正常执行完代码块后释放锁另一次是代码块执行过程中抛出了任何异常由异常处理表引导到这里释放锁然后再把异常抛出去。这个设计保证了即使代码块里出现异常monitor也不会泄漏。3.2 锁状态存放在对象头里锁信息到底存放在哪答案是Java对象头Object Header中的Mark Word字段。64位JVM下一个普通的Java对象内存布局大致是这样区域大小说明Mark Word8字节存放hashCode、锁状态标志、GC年龄等Klass Pointer4字节/8字节指向当前对象的Class对象类指针实例数据不定用户定义的字段Mark Word里有两位专门用于记录锁状态不同的锁状态会复用Mark Word里的其他位锁状态标志位Mark Word内容无锁01hashCode、分代年龄、偏向标志位偏向锁01偏向位1线程ID、epoch、分代年龄轻量级锁00指向栈中锁记录的指针重量级锁10指向ObjectMonitor对象的指针GC标记11GC相关标志如果你在本地想实际看一个对象头的变化可以用开源社区常用的JOL工具Java Object Layout。加一个依赖import org.openjdk.jol.info.ClassLayout; import org.openjdk.jol.info.GraphLayout; public class JolDemo { public static void main(String[] args) { Object obj new Object(); System.out.println(ClassLayout.parseInstance(obj).toPrintable()); synchronized (obj) { System.out.println(ClassLayout.parseInstance(obj).toPrintable()); } } }输出里对象头第一行的最后两位会随着是否持有锁而变化。这个工具非常适合用来验证“锁到底有没有生效”这类问题排查代码时很有帮助。3.3 锁升级的完整路径无锁、偏向锁、轻量级锁、重量级锁synchronized不是一开始就上重量级锁的它有一个从低开销到高开销逐步升级的路径目的是尽可能减少锁竞争带来的线程阻塞开销。无锁状态就是普通对象任何线程都可以直接修改共享数据不做同步控制。JVM早期JDK6之前每次竞争失败都会直接让线程进入阻塞状态代价很高。后来引入了偏向锁如果只有一个线程反复进入同步块JVM会在Mark Word里记录这个线程的ID之后它再次进入时几乎不需要任何同步操作只需要判断记录是否还是自己。这个设计针对的是“锁基本没有被竞争”的典型场景。一旦有第二个线程来竞争偏向锁就会被撤销升级为轻量级锁。轻量级锁用CAS操作把Mark Word替换成指向当前线程栈帧中锁记录的指针如果成功就认为获得了锁如果失败说明有竞争JVM会先让线程做一段自旋等待反复尝试获取锁。自旋的目的是等待持有锁的线程快速释放避免立刻陷入内核态阻塞。JDK6之后的JVM采用了适应性自旋会根据历史竞争情况自动调整自旋次数避免过度浪费CPU。如果竞争进一步加剧或者锁持有的时间太长自旋没能等到锁释放轻量级锁就会膨胀为重量级锁。重量级锁的Mark Word指向一个ObjectMonitor对象真正依赖操作系统底层的互斥量来实现阻塞和唤醒。一旦进入重量级锁没有抢到锁的线程会被挂起由用户态切换到内核态这个切换成本相当高。所以synchronized的性能不是一成不变的。低竞争下它可能只是几条CAS指令和标志位判断高竞争下它就是实打实的线程挂起和唤醒。3.4 JDK版本差异与JIT优化JDK版本对锁行为的影响不能忽视。偏向锁在JDK15开始默认被关闭JDK18直接标记为废弃。原因也很现实现代服务大多使用线程池线程数量多且反复迁移偏向锁的收益不如早期单线程独占场景明显反而引入了偏向撤销和安全点协作的复杂性。所以现在你在最新版本JDK上测试默认的升级路径基本是无锁到轻量级锁再到重量级锁不需要再考虑偏向锁这一层。另外JIT编译器对锁还有两个重要优化。一个是锁消除如果JVM通过逃逸分析发现一个锁对象只在当前线程内部使用根本不会被其他线程看到就会把这个锁直接去掉。比如方法内部new了一个局部变量把synchronized加在这个局部变量上JIT可能直接忽略这个同步块。另一个是锁粗化当多个连续的同步块使用同一个锁对象时JIT会把它们合并成一个更大的同步块减少反复获取释放锁的开销。这两个优化说明了一个道理JVM层面的锁成本比我们预想的更复杂不要只凭代码表面猜测性能高低。4. 类锁实战避坑意外互斥、死锁与性能评估4.1 最常见的坑拿对象锁去保护静态字段这是我在代码评审中看到最多的问题。很多人写了一堆实例方法方法里操作的是静态字段加锁时却习惯性写成synchronized(this)或者直接在实例方法上写synchronized。前面已经说过对象锁是per-instance级别的静态字段是class级别的两者根本不在一个安全边界上。结果是你加锁了但加错了地方静态字段照样被并发修改。正确的做法要么把涉及静态字段的方法改成静态同步方法要么在方法内部明确写明synchronized(类名.class)。一个判断标准特别简单你访问的资源是static的锁就必须锁在Class对象上和实例无关。如果你在处理订单时创建了100个服务实例却希望这100个实例里所有线程对某个共享配置的访问互斥那你必须用类锁不能用实例锁。4.2 锁错对象的代价字符串与包装类缓存选锁对象时字符串和包装类是个隐蔽的坑虽然不是类锁本身的问题但和锁对象选择密切相关。比如有人图省事在多个方法里写synchronized(configLock)表面上看起来锁的是一个字符串常量实际上JVM的字符串常量池中相同内容的字符串字面量指向同一个对象这几个方法之间会意外产生互斥。更危险的是其他地方如果也用了同一个字符串字面量作为锁对象也会被牵连进来。包装类也有类似问题。Integer在 -128到127 之间有缓存synchronized(Integer.valueOf(1))会锁到一个全局共享的Integer对象所有用到这个值的同步代码全部串在一起。这就像你在小区楼下大喊一声“一楼的都来开个会”结果全楼的人都出来了。相比之下类名.class是一个元信息对象语义清晰不会被JVM缓存机制影响用来做类锁比字符串和包装类安全得多。4.3 不同类加载器下的类锁隔离一个高级坑点类锁的“唯一性”有个前提同一个类加载器。在大多数单体应用里这个前提成立但在一些应用服务器中不同应用由不同的类加载器加载同一个全限定类名可能对应两个完全不同的Class对象。这时候应用A对某个类的类锁和应用B对同名类的类锁互不干扰两条线程可以同时进入各自版本的静态同步方法。如果你开发的代码会被部署到类加载器体系比较复杂的容器里一定要记住这个特性。它本身不是缺陷但如果你误以为类锁是全局唯一的就可能设计出存在并发漏洞的代码。排查方式也简单观察两个线程的栈如果都阻塞在同一个Class对象上那就是类锁竞争如果阻塞在不同Class对象上说明它们拿的根