1. 从一次线上事故说起为什么我们需要重新审视Synchronized那天下午系统监控突然报警核心交易接口的响应时间从平均50毫秒飙升至5秒以上紧接着就是一连串的“调用超时”错误。我们紧急排查发现罪魁祸首是一个看似简单的库存扣减方法它被Transactional注解包裹内部又用synchronized方法进行了“双重保险”。在低并发下相安无事一旦流量起来这个“保险”就成了性能瓶颈大量线程在等待同一个锁数据库连接池也被迅速耗尽。我们移除了synchronized改用数据库行锁配合重试机制问题才得以解决。这次事故让我意识到尽管synchronized是Java开发者最早接触、最“顺手”的锁但很多人对它的理解仍停留在“加上就线程安全了”的层面。它背后的锁升级过程、与JVM内存模型的交互、以及在现代高并发架构中的适用边界远比我们想象的要复杂。今天我就结合自己踩过的坑和源码层面的理解把synchronized这把“老锁”掰开揉碎了讲清楚这可能是你能看到的关于它最细致的一篇解读。2. Synchronized的“三重面孔”语法、语义与底层实现很多人觉得synchronized用法简单无非是修饰方法或代码块。但它的每一种用法都对应着JVM完全不同的处理逻辑和锁对象理解这点是避免误用的第一步。2.1 三种使用方式及其锁对象1. 实例方法同步这是最常见的形式。当你用synchronized修饰一个非静态方法时锁住的是当前调用该方法的对象实例this。public class Counter { private int count 0; public synchronized void increment() { count; // 锁对象是 this } }这意味着如果两个线程试图在同一个Counter对象上调用increment()它们会互斥。但如果它们操作的是两个不同的Counter对象则不会发生锁竞争因为锁对象不同。我见过有团队在Spring管理的单例Service类上滥用实例方法同步导致整个应用的所有相关请求串行化性能惨不忍睹。2. 静态方法同步当synchronized修饰静态方法时锁住的是当前类的Class对象。public class StaticCounter { private static int count 0; public static synchronized void increment() { count; // 锁对象是 StaticCounter.class } }这个锁的粒度非常大因为一个JVM中一个类的Class对象是唯一的。无论你创建多少个StaticCounter实例或者从哪个线程调用所有对静态increment()方法的访问都是互斥的。它通常用于保护静态变量但必须慎用否则极易成为全局性能瓶颈。3. 同步代码块这是最灵活也最能体现你对锁范围控制能力的方式。你需要显式指定一个对象作为锁monitor。public class FineGrainedCounter { private final Object lock new Object(); // 专门的锁对象 private int countA 0; private int countB 0; public void incA() { // 只锁与countA相关的操作 synchronized (lock) { countA; } // 其他不需要同步的操作可以放在外面 doSomethingElse(); } public void incB() { // 如果countB和countA完全独立甚至可以用另一个锁对象 // 比如 private final Object lockB new Object(); synchronized (lock) { countB; } } }使用代码块的关键在于锁对象的选择。锁对象通常应该是private final的防止外部代码意外获得你的锁导致死锁或性能问题。绝对不要使用可能会被修改的对象如String字面量有常量池问题或基础类型的包装类作为锁。2.2 锁的本质对象头与Monitorsynchronized的锁信息存储在哪里答案是Java对象的对象头Object Header里。一个普通的Java对象在堆内存中的布局可以分为三部分对象头、实例数据和对齐填充。其中对象头又包含Mark Word存储对象的哈希码、GC分代年龄、锁状态标志等。这是实现synchronized的关键。Klass Pointer指向对象元数据的指针。如果是数组数组长度。在32位JVM上Mark Word是32位64位JVM上是64位。为了在有限的空间里存储大量信息Mark Word的设计是“动态”的它的位模式会根据对象的状态是否被锁定、是否被偏向等而改变。当线程进入synchronized块时JVM需要关联一个Monitor管程对象来管理锁的竞争与等待。每个Java对象天生都关联着一个潜在的Monitor。你可以把Monitor想象成一个房间临界区它有一个所有者持有锁的线程一个入口队列Entry Set竞争锁的线程在此排队和一个等待队列Wait Set调用wait()的线程在此等待。synchronized的加锁过程本质上就是线程通过CAS操作去竞争对象Mark Word中指向的Monitor的所有权。成功则获取锁失败则进入阻塞队列。3. 锁的升级与优化从偏向锁到重量级锁早期的synchronized是纯粹的“重量级锁”依赖操作系统底层的互斥量Mutex Lock实现涉及用户态到内核态的切换开销巨大。为了提升在无竞争或低竞争场景下的性能HotSpot虚拟机从Java 6开始实现了锁升级Lock Coarsening机制。锁的状态不再是固定的而是根据竞争情况动态变化主要经历四个阶段无锁 - 偏向锁 - 轻量级锁 - 重量级锁。这个升级过程是不可逆的偏向锁可以被撤销回到无锁理解这个过程对于性能调优至关重要。3.1 偏向锁单线程的“特权”设计初衷在大多数情况下锁不仅不存在多线程竞争而且总是由同一线程多次获得。为了让线程获得锁的代价更低引入了偏向锁。工作原理加锁当一个线程第一次访问同步块时JVM会使用CAS操作将线程ID记录到对象头的Mark Word中并将锁标志位设置为“01”偏向模式。之后这个线程再进入和退出同步块时不需要进行任何同步操作如CAS只需简单检查Mark Word里是否存储着自己的线程ID。撤销一旦有另一个线程来尝试竞争这个锁偏向模式就宣告结束。持有偏向锁的线程必须将锁撤销Revoke Bias。撤销过程需要等待全局安全点即所有线程都暂停执行然后检查原持有线程是否还活着或已退出同步块。如果已退出则将对象头恢复为无锁状态允许新线程竞争如果还在同步块内则升级为轻量级锁。适用场景与坑点 偏向锁适用于明确知道只有一个线程会频繁访问的同步场景。但在高并发、锁竞争激烈的环境下偏向锁的撤销操作尤其是需要STW的撤销会带来额外的性能损耗。因此在JDK 15之后偏向锁被默认禁用-XX:-UseBiasedLocking并且在后续版本中被标记为废弃。对于新的应用尤其是微服务架构我通常建议在JVM参数中显式关闭偏向锁。3.2 轻量级锁线程间交替执行的“礼貌竞争”当偏向锁被撤销或者一开始就关闭了偏向锁线程会尝试使用轻量级锁。工作原理加锁在代码即将进入同步块时如果锁对象处于无锁状态JVM会在当前线程的栈帧中创建一个名为锁记录Lock Record的空间用于存储锁对象当前的Mark Word拷贝称为Displaced Mark Word。然后JVM使用CAS操作尝试将对象头的Mark Word更新为指向该锁记录的指针。如果成功当前线程获得锁并将锁标志位设置为“00”轻量级锁状态。如果失败说明至少存在两条线程在竞争同一个锁会先进行自旋。自旋竞争失败的线程不会立即阻塞而是进行一个循环自旋不断地检查锁是否被释放。自旋的目的是为了避免线程切换用户态到内核态的开销。解锁解锁时同样使用CAS操作将Displaced Mark Word替换回对象头。如果成功则表示没有竞争发生如果失败说明在持有锁期间锁已经升级为重量级锁此时需要唤醒被阻塞的线程。适用场景与坑点 轻量级锁适用于线程交替执行同步块即锁竞争是“短暂”且“稀疏”的场景。它的性能开销在于CAS操作和自旋消耗的CPU周期。注意自旋并非无限进行。JVM采用了适应性自旋Adaptive Spinning策略会根据之前自旋的成功历史动态调整自旋次数。如果自旋始终无法获得锁或者自旋线程数过多超过CPU核心数的一半为了避免CPU空转锁会膨胀为重量级锁。3.3 重量级锁真正的“排他”与阻塞当轻量级锁竞争失败自旋失败锁就会膨胀为重量级锁。工作原理 此时对象头的Mark Word中存储的是指向重量级锁Monitor对象的指针。其余所有试图获取锁的线程都会进入阻塞BLOCKED状态。锁的获取和释放完全依赖操作系统底层的互斥量Mutex和条件变量Condition Variable涉及用户态到内核态的切换、线程的挂起和唤醒开销最大。适用场景 这是synchronized的“保底”机制适用于高并发、长时间持有锁、竞争激烈的场景。虽然开销大但它能保证在极端情况下的正确性和公平性操作系统调度器会管理阻塞队列。3.4 锁升级流程图与实战意义我们可以用一个简单的流程图来概括这个动态过程线程尝试进入同步块 | v 检查对象Mark Word锁标志位 | v [无锁/可偏向] --(偏向锁开启且未偏向)-- [尝试CAS偏向当前线程] -- 成功 -- [偏向锁] | | | 失败/发生竞争 v v [偏向锁] --(其他线程竞争)-- [撤销偏向升级为轻量级锁] | v [轻量级锁] --(CAS获取锁)-- 成功 -- [持有轻量级锁] | | | 失败自旋失败/多线程竞争 v v [重量级锁] ------------------实战意义不要为了“性能”而盲目使用synchronized在极低竞争或无竞争场景它确实经过优化。但在你无法预知竞争程度的共享资源上它可能退化为性能杀手。锁对象的作用域至关重要锁住一个成员变量和锁住整个this对象竞争范围天差地别。尽量减小同步块的范围。理解“锁粗化”和“锁消除”这是JIT编译器的另外两项优化。锁粗化如果虚拟机探测到有一串零碎的操作都对同一个对象加锁解锁会把锁同步的范围扩展粗化到整个操作序列的外部减少加锁解锁次数。锁消除如果JIT编译器通过逃逸分析发现某个锁对象不可能被其他线程访问到即不会发生共享那么就会将这个锁消除。例如在方法内部创建的、仅用于同步的局部对象。4. Synchronized与Java内存模型可见性与有序性的保证synchronized不仅仅是互斥锁它还是Java内存模型JMM中一个重要的内存屏障Memory Barrier。它能解决并发编程中的三大问题原子性、可见性、有序性。原子性由锁的互斥性自然保证同步块内的操作作为一个不可分割的整体执行。可见性根据JMM规范对一个锁的解锁unlock操作happens-before于后续对这个锁的加锁lock操作。这意味着线程A在synchronized块内修改了共享变量在解锁后线程B在进入同一个锁保护的synchronized块时一定能看到线程A修改后的最新值。这是因为解锁时JVM会将线程本地内存工作内存中的变量刷新到主内存加锁时会清空本地内存从主内存重新加载变量。有序性synchronized块内的代码虽然可能被编译器或处理器重排序但由于“as-if-serial”语义和内存屏障从其他线程的视角来看其执行结果与程序顺序执行的结果一致。同时它禁止了块内指令与块外指令的某些重排序保证了临界区操作的顺序性。一个常见的误解有人认为volatile能替代synchronized实现同步。volatile只保证了可见性和禁止指令重排序部分有序性但不保证复合操作的原子性。例如count这样的“读-改-写”操作即使count是volatile的在多线程下仍然会出错因为它不是原子操作。而synchronized可以保证整个count操作的原子性。5. 深入对比Synchronized vs LockReentrantLock“既然有java.util.concurrent.locks.Lock接口和功能强大的ReentrantLock为什么还要用synchronized”这是面试常考题也是技术选型的关键。特性synchronizedReentrantLock实现层面JVM原生支持关键字JDK API层面实现类锁的获取隐式获取和释放进入块自动获取退出正常或异常自动释放显式调用lock()和unlock()必须在finally块中释放灵活性较差锁的释放由JVM控制很强可尝试非阻塞获取(tryLock)、可中断获取(lockInterruptibly)、超时获取公平性非公平锁但内部实现有适应性的优化可选公平锁或非公平锁构造参数指定条件变量通过Object.wait(),notify(),notifyAll()一个锁对应一个等待队列通过Condition接口一个锁可以绑定多个Condition实现更精细的线程等待/唤醒性能Java 6后大幅优化在低至中等竞争下与Lock相差无几甚至更好在高竞争场景下由于其更复杂的逻辑和API开销可能略逊一筹但功能优势明显调试获取锁的堆栈信息在JDK工具中可能不直观可以通过getHoldCount(),getQueueLength()等方法获取锁状态信息便于调试选型建议个人经验优先使用synchronized除非你需要ReentrantLock提供的高级功能如可中断、超时、公平锁、多个条件队列。synchronized的简洁性和不易出错自动释放是巨大优势。大多数业务场景它的性能已经足够好。考虑使用ReentrantLock需要可定时的、可轮询的锁获取tryLock(long time, TimeUnit unit)比如在死锁恢复场景。需要可中断的锁获取lockInterruptibly()让等待锁的线程能响应中断。需要公平锁虽然通常性能较差。需要绑定多个条件变量Condition实现复杂的线程协作如生产者-消费者模型中的多个等待队列。性能不是首要考虑因素在绝大多数应用里锁竞争本身才是瓶颈而不是synchronized和ReentrantLock之间的细微性能差异。首先应该优化的是锁的粒度和持有锁的时间。6. 实战避坑指南与性能优化理论懂了还得在实战中不踩坑。下面是我总结的几个关键点和优化技巧。6.1 锁对象选择不当引发的“神秘”问题案例使用字符串常量作为锁。private static final String LOCK “LOCK”; public void method() { synchronized(LOCK) { // 危险 // ... } }问题字符串常量具有驻留intern特性。“LOCK”在JVM字符串常量池中是唯一的。这意味着如果你的代码其他模块甚至是引用的第三方库也鬼使神差地用“LOCK”这个字符串作为锁就会导致意料之外的锁竞争引发死锁或性能问题且极难排查。正确做法使用专门创建的、不可变的对象作为锁。private final Object lock new Object(); // 实例锁 private static final Object STATIC_LOCK new Object(); // 类锁6.2 死锁的经典场景与排查synchronized嵌套使用不当是死锁的温床。// 线程1 synchronized (lockA) { Thread.sleep(100); // 模拟业务操作增加死锁概率 synchronized (lockB) { // ... } } // 线程2 synchronized (lockB) { Thread.sleep(100); synchronized (lockA) { // 死锁发生 // ... } }排查与预防避免嵌套锁尽量设计成只获取一把锁。如果必须嵌套确保所有线程以相同的全局顺序获取锁例如都按lockA-lockB的顺序。使用带超时的锁如果使用ReentrantLock可以用tryLock(timeout)。使用JDK工具jstack pid可以打印线程堆栈能清晰看到哪些线程在等待哪些锁是定位死锁的首选工具。6.3 锁粒度控制细粒度锁与锁分段对于保护一个组合对象如HashMap锁住整个对象synchronized(map)粒度太粗。可以采用更细粒度的策略。示例简易锁分段public class StripedMap { private final int N_LOCKS 16; private final Node[] buckets; private final Object[] locks; public StripedMap(int capacity) { buckets new Node[capacity]; locks new Object[N_LOCKS]; for (int i 0; i N_LOCKS; i) { locks[i] new Object(); } } private final int hash(Object key) { return Math.abs(key.hashCode() % buckets.length); } public Object get(Object key) { int hash hash(key); // 只锁住这个桶对应的锁而不是整个map synchronized (locks[hash % N_LOCKS]) { for (Node m buckets[hash]; m ! null; m m.next) { if (m.key.equals(key)) { return m.value; } } } return null; } // ... put方法类似 static class Node { Object key, value; Node next; } }ConcurrentHashMap在JDK 7及之前就采用了分段锁Segment正是这种思想的体现。在JDK 8中它改为使用synchronized锁住单个桶链表头或红黑树根节点 CAS实现了更细粒度的并发控制。6.4 性能监控与诊断如何知道你的synchronized成了瓶颈JVisualVM / JMC监控线程状态如果大量线程长时间处于BLOCKED状态很可能存在锁竞争。Arthas使用thread -b命令可以一键找出当前阻塞其他线程最多的“罪魁祸首”线程。自定义监控对于关键锁可以简单包装一下记录持有时间、等待时间等。public class MonitoredSync { private final Object lock new Object(); private long totalWaitTime 0; private long holdCount 0; public void doSomething() throws InterruptedException { long startWait System.nanoTime(); synchronized (lock) { long waitTime System.nanoTime() - startWait; totalWaitTime waitTime; holdCount; // 实际业务逻辑 Thread.sleep(10); // 模拟工作 } // 可以定期打印或上报平均等待时间 totalWaitTime / holdCount } }7. 在现代架构中的定位何时用何时弃在分布式、高并发的今天synchronized的战场主要收缩到了单JVM进程内的线程同步。适用场景单机多线程资源保护如内存中的计数器、缓存、连接池状态等。Spring单例Bean的方法同步需谨慎评估范围。实现简单的线程安全工具类如懒加载的单例模式双重检查锁定中实例变量需用volatile修饰。作为更复杂并发组件如ConcurrentHashMap在JDK8中的实现的基础构建块。不适用/需要替代的场景分布式环境下的共享资源如分布式库存、分布式ID生成。这里需要分布式锁如基于RedisRedisson、ZooKeeper或数据库的实现。需要更复杂协调机制的场景如多个条件队列、可中断锁等使用ReentrantLock和Condition。超高并发且临界区极短的场景可以考虑使用java.util.concurrent.atomic包下的原子变量它们基于CAS实现在无竞争或低竞争时性能通常优于锁。读写比例极高的场景使用ReadWriteLock或StampedLock实现读写分离允许多个读线程同时访问。最后一点体会synchronized就像一把瑞士军刀中的主刀简单、可靠、在大多数日常场景下够用。但作为一名专业的开发者你必须清楚知道它何时会变钝性能瓶颈何时根本不适用分布式场景以及工具箱里还有哪些更专业的工具Lock、原子类、并发容器可供选择。深入理解其原理是为了更精准、更自信地使用它而不是盲目地回避或滥用。在微服务架构下我越来越少在业务代码中直接使用synchronized更多的并发控制被转移到了数据库的事务隔离级别、Redis的分布式锁或无锁的数据结构上但它在框架底层和基础组件中依然扮演着不可或缺的角色。