1. Java中的synchronized实现机制解析在Java并发编程中synchronized关键字是最基础的线程同步工具。它的核心实现依赖于JVM层面的Monitor机制和对象头数据结构。当我们在方法或代码块上使用synchronized时编译器会在字节码层面生成对应的monitorenter和monitorexit指令。1.1 Monitor的工作原理每个Java对象都与一个Monitor相关联这个Monitor由三部分组成Owner记录当前持有锁的线程EntryList存放等待获取锁的线程WaitSet存放调用了wait()方法的线程当线程执行到synchronized代码块时通过CAS操作尝试获取对象的Monitor成功获取后会将Owner设置为当前线程获取失败则进入EntryList等待注意Monitor的获取是排他的同一时刻只有一个线程能成为Owner1.2 对象头与锁标记在HotSpot虚拟机中对象头包含两部分重要信息Mark Word32/64位存储对象的hashCode、GC分代年龄和锁状态标志Klass Pointer指向类元数据的指针锁状态在Mark Word中的表示| 锁状态 | 存储内容 | 标志位 | |----------|-----------------------------------|--------| | 无锁 | hashCode分代年龄 | 01 | | 偏向锁 | 线程IDEpoch分代年龄 | 01 | | 轻量级锁 | 指向栈中锁记录的指针 | 00 | | 重量级锁 | 指向互斥量Monitor的指针 | 10 | | GC标记 | 空 | 11 |2. synchronized的锁升级过程JDK1.6后对synchronized进行了优化引入了锁升级机制2.1 偏向锁阶段适用场景没有实际竞争且将来只有第一个申请锁的线程会使用锁实现原理当线程第一次访问同步块时通过CAS将线程ID写入Mark Word后续该线程进入只需检查线程ID是否匹配如果匹配则直接执行不需要额外同步操作实测数据偏向锁的获取和释放比轻量级锁快约20%2.2 轻量级锁阶段触发条件当有第二个线程尝试获取锁时偏向锁升级为轻量级锁加锁过程在当前线程栈帧中创建锁记录Lock Record将对象头的Mark Word复制到锁记录中Displaced Mark Word通过CAS将对象头Mark Word替换为指向锁记录的指针解锁过程使用CAS将Displaced Mark Word替换回对象头如果成功则解锁完成如果失败表示存在竞争升级为重量级锁2.3 重量级锁阶段触发条件轻量级锁自旋超过阈值默认10次或有第三个线程竞争特点通过操作系统的mutex实现未获取锁的线程会被挂起涉及用户态到内核态的切换开销较大锁升级流程图[无锁] → [偏向锁] → [轻量级锁] → [重量级锁]3. 不同使用方式的底层差异3.1 同步代码块字节码表现public void syncBlock() { synchronized(this) { // code } }对应字节码monitorenter // 代码逻辑 monitorexit3.2 同步方法实例方法public synchronized void syncMethod() { // code }在方法flags中设置ACC_SYNCHRONIZED标志静态方法public static synchronized void staticSyncMethod() { // code }锁对象是类的Class对象4. 性能优化实践4.1 锁消除JVM通过逃逸分析发现同步代码不可能存在共享数据竞争时会消除锁。例如public String concat(String s1, String s2) { StringBuffer sb new StringBuffer(); sb.append(s1); sb.append(s2); return sb.toString(); }StringBuffer是线程安全的但在此方法中不可能被其他线程访问JVM会去掉同步操作。4.2 锁粗化当检测到一连串操作都对同一个对象加锁时JVM会将锁的范围扩大到整个操作序列。例如for(int i0; i100; i) { synchronized(this) { // 操作 } }可能被优化为synchronized(this) { for(int i0; i100; i) { // 操作 } }4.3 自旋优化在轻量级锁阶段线程会进行自旋等待忙等待。JVM采用适应性自旋策略根据前一次自旋是否成功动态调整自旋时间自旋次数上限由-XX:PreBlockSpin参数控制默认105. 常见问题排查5.1 死锁场景典型死锁代码// 线程1 synchronized(objA) { synchronized(objB) { // ... } } // 线程2 synchronized(objB) { synchronized(objA) { // ... } }排查方法jstack查看线程dump查找deadlock关键词分析互相等待的锁资源5.2 锁竞争严重表现症状大量线程处于BLOCKED状态系统吞吐量下降CPU使用率不高但响应变慢解决方案减小锁粒度拆分为多个锁使用读写锁ReentrantReadWriteLock考虑无锁数据结构如ConcurrentHashMap5.3 错误使用静态锁错误示例private static final Object lock new Object(); public void process() { synchronized(lock) { // 处理实例数据 } }问题所有实例共用同一个锁导致不必要的串行化正确做法private final Object lock new Object(); public void process() { synchronized(lock) { // 处理实例数据 } }6. 与ReentrantLock的对比6.1 实现机制差异特性synchronizedReentrantLock实现层面JVM原生实现JDK代码实现基于AQS锁获取方式自动获取和释放需要手动lock/unlock中断响应不支持支持lockInterruptibly()公平性非公平可配置公平/非公平条件变量只能有一个wait队列可创建多个Condition6.2 适用场景选择推荐使用synchronized的情况简单的同步需求需要自动释放锁的场景对性能要求不苛刻的临界区推荐使用ReentrantLock的情况需要可中断的锁获取需要尝试获取锁tryLock需要公平锁策略需要多个条件变量在实际项目中我发现对于80%的同步需求synchronized已经完全够用。只有在需要更灵活的锁控制时才会考虑使用ReentrantLock。 
长河君 · 2026/10/31 17:58:21 · 阅读 1.2k Java synchronized机制与锁升级全解析
1. Java中的synchronized实现机制解析在Java并发编程中synchronized关键字是最基础的线程同步工具。它的核心实现依赖于JVM层面的Monitor机制和对象头数据结构。当我们在方法或代码块上使用synchronized时编译器会在字节码层面生成对应的monitorenter和monitorexit指令。1.1 Monitor的工作原理每个Java对象都与一个Monitor相关联这个Monitor由三部分组成Owner记录当前持有锁的线程EntryList存放等待获取锁的线程WaitSet存放调用了wait()方法的线程当线程执行到synchronized代码块时通过CAS操作尝试获取对象的Monitor成功获取后会将Owner设置为当前线程获取失败则进入EntryList等待注意Monitor的获取是排他的同一时刻只有一个线程能成为Owner1.2 对象头与锁标记在HotSpot虚拟机中对象头包含两部分重要信息Mark Word32/64位存储对象的hashCode、GC分代年龄和锁状态标志Klass Pointer指向类元数据的指针锁状态在Mark Word中的表示| 锁状态 | 存储内容 | 标志位 | |----------|-----------------------------------|--------| | 无锁 | hashCode分代年龄 | 01 | | 偏向锁 | 线程IDEpoch分代年龄 | 01 | | 轻量级锁 | 指向栈中锁记录的指针 | 00 | | 重量级锁 | 指向互斥量Monitor的指针 | 10 | | GC标记 | 空 | 11 |2. synchronized的锁升级过程JDK1.6后对synchronized进行了优化引入了锁升级机制2.1 偏向锁阶段适用场景没有实际竞争且将来只有第一个申请锁的线程会使用锁实现原理当线程第一次访问同步块时通过CAS将线程ID写入Mark Word后续该线程进入只需检查线程ID是否匹配如果匹配则直接执行不需要额外同步操作实测数据偏向锁的获取和释放比轻量级锁快约20%2.2 轻量级锁阶段触发条件当有第二个线程尝试获取锁时偏向锁升级为轻量级锁加锁过程在当前线程栈帧中创建锁记录Lock Record将对象头的Mark Word复制到锁记录中Displaced Mark Word通过CAS将对象头Mark Word替换为指向锁记录的指针解锁过程使用CAS将Displaced Mark Word替换回对象头如果成功则解锁完成如果失败表示存在竞争升级为重量级锁2.3 重量级锁阶段触发条件轻量级锁自旋超过阈值默认10次或有第三个线程竞争特点通过操作系统的mutex实现未获取锁的线程会被挂起涉及用户态到内核态的切换开销较大锁升级流程图[无锁] → [偏向锁] → [轻量级锁] → [重量级锁]3. 不同使用方式的底层差异3.1 同步代码块字节码表现public void syncBlock() { synchronized(this) { // code } }对应字节码monitorenter // 代码逻辑 monitorexit3.2 同步方法实例方法public synchronized void syncMethod() { // code }在方法flags中设置ACC_SYNCHRONIZED标志静态方法public static synchronized void staticSyncMethod() { // code }锁对象是类的Class对象4. 性能优化实践4.1 锁消除JVM通过逃逸分析发现同步代码不可能存在共享数据竞争时会消除锁。例如public String concat(String s1, String s2) { StringBuffer sb new StringBuffer(); sb.append(s1); sb.append(s2); return sb.toString(); }StringBuffer是线程安全的但在此方法中不可能被其他线程访问JVM会去掉同步操作。4.2 锁粗化当检测到一连串操作都对同一个对象加锁时JVM会将锁的范围扩大到整个操作序列。例如for(int i0; i100; i) { synchronized(this) { // 操作 } }可能被优化为synchronized(this) { for(int i0; i100; i) { // 操作 } }4.3 自旋优化在轻量级锁阶段线程会进行自旋等待忙等待。JVM采用适应性自旋策略根据前一次自旋是否成功动态调整自旋时间自旋次数上限由-XX:PreBlockSpin参数控制默认105. 常见问题排查5.1 死锁场景典型死锁代码// 线程1 synchronized(objA) { synchronized(objB) { // ... } } // 线程2 synchronized(objB) { synchronized(objA) { // ... } }排查方法jstack查看线程dump查找deadlock关键词分析互相等待的锁资源5.2 锁竞争严重表现症状大量线程处于BLOCKED状态系统吞吐量下降CPU使用率不高但响应变慢解决方案减小锁粒度拆分为多个锁使用读写锁ReentrantReadWriteLock考虑无锁数据结构如ConcurrentHashMap5.3 错误使用静态锁错误示例private static final Object lock new Object(); public void process() { synchronized(lock) { // 处理实例数据 } }问题所有实例共用同一个锁导致不必要的串行化正确做法private final Object lock new Object(); public void process() { synchronized(lock) { // 处理实例数据 } }6. 与ReentrantLock的对比6.1 实现机制差异特性synchronizedReentrantLock实现层面JVM原生实现JDK代码实现基于AQS锁获取方式自动获取和释放需要手动lock/unlock中断响应不支持支持lockInterruptibly()公平性非公平可配置公平/非公平条件变量只能有一个wait队列可创建多个Condition6.2 适用场景选择推荐使用synchronized的情况简单的同步需求需要自动释放锁的场景对性能要求不苛刻的临界区推荐使用ReentrantLock的情况需要可中断的锁获取需要尝试获取锁tryLock需要公平锁策略需要多个条件变量在实际项目中我发现对于80%的同步需求synchronized已经完全够用。只有在需要更灵活的锁控制时才会考虑使用ReentrantLock。