Java synchronized锁升级机制与性能优化详解

1. synchronized 底层实现与锁升级全解析

在 Java 并发编程中，synchronized 是最基础也是最常用的同步机制。很多开发者都知道它的用法，但对其底层实现原理和优化机制却知之甚少。本文将深入 HotSpot 虚拟机的实现细节，解析 synchronized 从对象头 MarkWord 到 Monitor 锁的完整工作流程，以及 JDK 6 引入的锁升级机制（偏向锁、轻量级锁、重量级锁）是如何提升性能的。

作为一个在 Java 并发领域踩过无数坑的老手，我见过太多因为不理解 synchronized 底层原理而导致的性能问题和死锁案例。通过本文，你将不仅知道怎么用 synchronized，更会明白为什么这样用，以及在不同场景下如何选择最优的同步策略。

2. synchronized 的基本原理

2.1 Java 对象的内存布局

要理解 synchronized 的底层实现，首先需要了解 Java 对象在内存中的布局。在 HotSpot 虚拟机中，每个对象在内存中存储的布局可以分为三部分：

1. 对象头（Header）：包含 MarkWord 和类型指针
2. 实例数据（Instance Data）：对象实际存储的有效信息
3. 对齐填充（Padding）：非必需部分，仅用于字节对齐

其中，MarkWord 是实现 synchronized 的关键所在。在 32 位 JVM 中，MarkWord 长度为 32 位；在 64 位 JVM 中，长度为 64 位。MarkWord 在不同锁状态下会存储不同的内容：

注意：在 64 位 JVM 中，MarkWord 的高位还会包含一些额外的信息，但基本结构类似。

2.2 Monitor 机制

synchronized 的底层实现依赖于 Monitor（监视器锁）的概念。每个 Java 对象都可以关联一个 Monitor 对象，Monitor 是线程同步的基本工具，它实现了互斥和协作的功能。

Monitor 主要由以下几部分组成：

1. Owner：记录持有该 Monitor 的线程
2. EntryList：存放等待获取锁的线程
3. WaitSet：存放调用了 wait() 方法的线程

当线程尝试获取对象的 Monitor 时，会经历以下过程：

1. 如果 Monitor 的 Owner 为空，当前线程成为 Owner
2. 如果 Owner 已经是当前线程，可重入（计数器+1）
3. 如果 Owner 是其他线程，当前线程进入 EntryList 阻塞等待

这种直接的 Monitor 实现就是所谓的"重量级锁"，因为它涉及到操作系统层面的线程阻塞和唤醒，性能开销较大。

3. 锁升级的全过程

JDK 6 对 synchronized 进行了重大优化，引入了锁升级机制，使得 synchronized 的性能得到了显著提升。锁升级是指根据竞争情况，锁的状态会从无锁→偏向锁→轻量级锁→重量级锁逐步升级的过程。

3.1 偏向锁（Biased Locking）

偏向锁是 JDK 6 引入的优化，它的核心思想是：如果一段同步代码一直被同一个线程访问，那么该线程会自动获取锁，降低获取锁的代价。

偏向锁的获取流程：

1. 检查 MarkWord 中的线程ID是否指向当前线程
   • 如果是，直接执行同步代码
   • 如果不是，进入步骤2
2. 通过 CAS 操作竞争锁
   • 成功：将 MarkWord 中的线程ID改为当前线程ID
   • 失败：表示有竞争，升级为轻量级锁

偏向锁的撤销需要等待全局安全点（即没有字节码正在执行），它会首先暂停拥有偏向锁的线程，然后检查线程是否存活：

• 不存活：直接撤销偏向锁
• 存活：遍历线程栈帧，检查是否还需要持有锁
  • 需要：升级为轻量级锁
  • 不需要：撤销偏向锁

实操心得：偏向锁适合单线程重复访问同步块的场景。但在多线程竞争激烈的环境下，偏向锁的撤销和升级反而会带来额外开销，此时可以通过 JVM 参数 -XX:-UseBiasedLocking 关闭偏向锁。

3.2 轻量级锁（Lightweight Locking）

当偏向锁失效（出现多线程竞争）时，锁会升级为轻量级锁。轻量级锁的核心思想是：通过 CAS 操作避免线程阻塞，减少操作系统层面的互斥操作。

轻量级锁的加锁过程：

1. 在当前线程的栈帧中创建锁记录（Lock Record）空间
2. 将对象头中的 MarkWord 复制到锁记录中（Displaced MarkWord）
3. 尝试用 CAS 将对象头中的 MarkWord 替换为指向锁记录的指针
   • 成功：当前线程获得锁
   • 失败：检查对象头的 MarkWord 是否指向当前线程的栈帧
     • 是：直接执行（锁重入）
     • 否：表示有多线程竞争，升级为重量级锁

轻量级锁的解锁过程：

1. 使用 CAS 操作将 Displaced MarkWord 替换回对象头
   • 成功：解锁完成
   • 失败：表示锁已升级为重量级锁，进入重量级锁解锁流程

3.3 重量级锁（Heavyweight Locking）

当轻量级锁竞争失败时，锁会升级为重量级锁。此时，MarkWord 中存储的是指向重量级锁（Monitor）的指针，等待锁的线程会被阻塞，进入 EntryList 等待唤醒。

重量级锁的特点：

• 依赖于操作系统层面的互斥量（Mutex）实现
• 线程阻塞和唤醒需要从用户态切换到内核态，开销较大
• 适用于高并发竞争场景

注意事项：锁只能升级，不能降级。这是为了避免在降级过程中出现竞争条件，简化实现逻辑。

4. 锁升级的实战案例分析

4.1 单线程场景下的偏向锁

java复制public class BiasedLockExample {
    private static final Object lock = new Object();
    
    public static void main(String[] args) {
        synchronized (lock) {
            System.out.println("第一次获取锁");
        }
        
        synchronized (lock) {
            System.out.println("第二次获取锁");
        }
    }
}

在这个例子中：

1. 第一次获取锁时，锁对象处于无锁状态，JVM 会启用偏向锁，将线程ID记录到 MarkWord
2. 第二次获取锁时，JVM 发现 MarkWord 中的线程ID与当前线程一致，直接允许进入同步块

可以通过 JVM 参数 -XX:+PrintBiasedLockingStatistics 查看偏向锁的统计信息。

4.2 多线程轻度竞争下的轻量级锁

java复制public class LightweightLockExample {
    private static final Object lock = new Object();
    
    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(() -> {
            synchronized (lock) {
                System.out.println("线程1获取锁");
                try { Thread.sleep(100); } catch (InterruptedException e) {}
            }
        });
        
        Thread t2 = new Thread(() -> {
            synchronized (lock) {
                System.out.println("线程2获取锁");
            }
        });
        
        t1.start();
        Thread.sleep(10); // 确保t1先获取锁
        t2.start();
        
        t1.join();
        t2.join();
    }
}

在这个例子中：

1. t1 先获取锁，此时是偏向锁
2. t2 尝试获取锁时，发现偏向锁的线程ID不是自己，触发锁升级
3. 由于竞争不激烈，锁升级为轻量级锁，t2 通过自旋尝试获取锁

4.3 高并发竞争下的重量级锁

java复制public class HeavyweightLockExample {
    private static final Object lock = new Object();
    private static final int THREAD_COUNT = 10;
    
    public static void main(String[] args) {
        for (int i = 0; i < THREAD_COUNT; i++) {
            new Thread(() -> {
                synchronized (lock) {
                    System.out.println(Thread.currentThread().getName() + "获取锁");
                    try { Thread.sleep(1000); } catch (InterruptedException e) {}
                }
            }).start();
        }
    }
}

在这个例子中：

1. 多个线程同时竞争同一个锁
2. 轻量级锁的自旋会消耗大量CPU资源
3. JVM 会将锁升级为重量级锁，线程进入阻塞状态，减少CPU消耗

5. 性能优化与常见问题

5.1 锁优化的最佳实践

1. 减少锁的持有时间：只在必要的时候加锁，尽快释放

   java复制// 不好的写法
   synchronized(this) {
       // 大量不需要同步的代码
       doSomethingNeedSync();
       // 更多不需要同步的代码
   }
   
   // 好的写法
   doSomethingNotNeedSync();
   synchronized(this) {
       doSomethingNeedSync();
   }
   doSomethingNotNeedSync();
   

2. 减小锁的粒度：使用多个细粒度锁代替一个大锁

   java复制// 不好的写法 - 整个方法加锁
   public synchronized void updateAll() {
       updateA();
       updateB();
       updateC();
   }
   
   // 好的写法 - 细粒度锁
   public void updateAll() {
       updateA(); // 内部有自己的锁
       updateB(); // 内部有自己的锁
       updateC(); // 内部有自己的锁
   }
   

3. 避免锁的嵌套：容易导致死锁

   java复制// 危险的写法
   synchronized(lockA) {
       synchronized(lockB) {
           // ...
       }
   }
   

4. 使用读写锁：当读多写少时，使用 ReentrantReadWriteLock

   java复制private final ReentrantReadWriteLock rwLock = new ReentrantReadWriteLock();
   
   public void read() {
       rwLock.readLock().lock();
       try {
           // 读操作
       } finally {
           rwLock.readLock().unlock();
       }
   }
   
   public void write() {
       rwLock.writeLock().lock();
       try {
           // 写操作
       } finally {
           rwLock.writeLock().unlock();
       }
   }
   

5.2 常见问题排查

1. 死锁问题：

   • 使用 jstack 命令可以检测死锁
   • 示例死锁代码：

     java复制Object lock1 = new Object();
     Object lock2 = new Object();
     
     new Thread(() -> {
         synchronized (lock1) {
             try { Thread.sleep(100); } catch (InterruptedException e) {}
             synchronized (lock2) {
                 System.out.println("Thread1 got both locks");
             }
         }
     }).start();
     
     new Thread(() -> {
         synchronized (lock2) {
             try { Thread.sleep(100); } catch (InterruptedException e) {}
             synchronized (lock1) {
                 System.out.println("Thread2 got both locks");
             }
         }
     }).start();
     

2. 锁竞争激烈：

   • 使用 JVisualVM 或 JMC 查看线程阻塞情况
   • 解决方案：减小锁粒度、使用并发容器、采用无锁编程等

3. 偏向锁延迟问题：

   • JVM 默认在启动后 4 秒才启用偏向锁（可通过 -XX:BiasedLockingStartupDelay=0 调整）
   • 对于短期运行的应用，可能无法享受偏向锁的优势

6. JVM 参数调优

以下是与 synchronized 和锁升级相关的重要 JVM 参数：

调优建议：在明确知道同步特性的应用场景下，可以调整这些参数。例如，对于明确不会有锁竞争的单线程应用，可以设置 -XX:BiasedLockingStartupDelay=0 让偏向锁立即生效；对于高并发竞争的应用，可以关闭偏向锁 -XX:-UseBiasedLocking 避免不必要的锁升级开销。

7. 与其他同步机制的对比

虽然 synchronized 经过了大量优化，但在某些场景下，其他同步机制可能更合适：

选择建议：

• 大多数常规场景：优先使用 synchronized（简洁、自动优化）
• 需要高级功能（可中断、超时、公平锁等）：使用 ReentrantLock
• 读多写少场景：考虑 ReentrantReadWriteLock 或 StampedLock
• 极高性能需求：考虑 CAS 或 VarHandle

8. 从字节码看 synchronized 实现

通过 javap 查看包含 synchronized 的代码的字节码，可以更直观地理解其实现：

java复制public class SyncBytecode {
    public synchronized void syncMethod() {
        System.out.println("sync method");
    }
    
    public void syncBlock() {
        synchronized(this) {
            System.out.println("sync block");
        }
    }
}

编译后查看字节码：

code复制public synchronized void syncMethod();
  descriptor: ()V
  flags: ACC_PUBLIC, ACC_SYNCHRONIZED
  Code:
    stack=2, locals=1, args_size=1
      0: getstatic     #2  // Field java/lang/System.out:Ljava/io/PrintStream;
      3: ldc           #3  // String sync method
      5: invokevirtual #4  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
      8: return

public void syncBlock();
  descriptor: ()V
  flags: ACC_PUBLIC
  Code:
    stack=2, locals=3, args_size=1
      0: aload_0
      1: dup
      2: astore_1
      3: monitorenter
      4: getstatic     #2  // Field java/lang/System.out:Ljava/io/PrintStream;
      7: ldc           #5  // String sync block
      9: invokevirtual #4  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
      12: aload_1
      13: monitorexit
      14: goto          22
      17: astore_2
      18: aload_1
      19: monitorexit
      20: aload_2
      21: athrow
      22: return

关键区别：

• 同步方法：通过方法的 ACC_SYNCHRONIZED 标志实现
• 同步块：通过 monitorenter/monitorexit 指令实现

9. 锁升级的性能影响实测

为了直观展示锁升级对性能的影响，我设计了一个简单的基准测试：

java复制@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Thread)
public class LockBenchmark {
    private Object lock = new Object();
    private int counter;
    
    @Benchmark
    public void baseline() {
        counter++;
    }
    
    @Benchmark
    public void synchronizedNoContention() {
        synchronized(lock) {
            counter++;
        }
    }
    
    @Benchmark
    @Threads(2)
    public void synchronizedWithContention() {
        synchronized(lock) {
            counter++;
        }
    }
    
    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(LockBenchmark.class.getSimpleName())
                .forks(1)
                .warmupIterations(5)
                .measurementIterations(5)
                .build();
        new Runner(opt).run();
    }
}

测试结果（仅供参考，实际结果因环境而异）：

从测试可以看出：

1. 无竞争时，synchronized 的开销很小（偏向锁）
2. 有竞争时，性能下降明显（升级为重量级锁）
3. 在实际应用中，应该尽量避免锁竞争

10. 常见误区与正确实践

10.1 误区一：synchronized 比 ReentrantLock 慢

早期版本的 synchronized 确实性能较差，但经过多次优化后，在无竞争或低竞争场景下，synchronized 的性能已经与 ReentrantLock 相当甚至更好。只有在需要 ReentrantLock 的高级功能时，才应该选择它。

10.2 误区二：锁的对象不重要

锁的对象选择非常重要，不当的选择会导致意外同步或没有同步：

java复制// 不好的写法 - 锁的对象可能被改变
private String lock = "lock";
public void method() {
    synchronized(lock) {
        lock = "new lock"; // 改变了锁对象
        // ...
    }
}

// 好的写法 - 使用final对象作为锁
private final Object lock = new Object();
public void method() {
    synchronized(lock) {
        // ...
    }
}

10.3 误区三：锁的范围越大越好

过度同步会降低性能，应该只在必要的时候加锁：

java复制// 不好的写法 - 同步范围过大
public synchronized void process() {
    readData(); // 不需要同步的操作
    compute();  // 需要同步的操作
    saveData(); // 不需要同步的操作
}

// 好的写法 - 精确同步
public void process() {
    readData();
    synchronized(this) {
        compute();
    }
    saveData();
}

10.4 正确实践：选择合适的锁策略

根据应用场景选择合适的同步策略：

1. 单线程重复访问：偏向锁最优
2. 多线程轻度竞争：轻量级锁表现良好
3. 高并发激烈竞争：考虑减小锁粒度或使用其他并发工具
4. 读多写少：使用读写锁
5. 极高性能需求：考虑无锁编程（CAS）

在实际项目中，我通常会遵循以下步骤选择同步方案：

1. 首先尝试用 synchronized，因为它最简单且自动优化
2. 如果遇到性能问题，分析竞争情况
3. 根据竞争特点选择优化方向：
   • 减少锁竞争：减小锁粒度、缩短持有时间
   • 改变锁类型：读写锁、乐观锁等
4. 最后考虑更复杂的并发工具

记住：不要过早优化，先用最简单的方案，再根据实际性能数据做针对性优化。