ReentrantLock 与 synchronized 性能对比：基于 JIT 编译优化与底层实现的差异
大家好，今天我们来深入探讨 Java 并发编程中两个至关重要的同步机制：ReentrantLock 和 synchronized。 它们都用于实现互斥访问，确保多线程环境下共享资源的安全。 然而，它们的实现方式、性能特征以及适用场景存在显著差异。 这次讲座将从 JIT 编译优化和底层实现的角度，详细对比这两种锁的性能，并分析其背后的原因。
1. synchronized 关键字：隐式锁机制
synchronized 关键字是 Java 语言内置的同步机制，它可以修饰方法或代码块。当线程进入 synchronized 修饰的方法或代码块时，它会自动获取锁，并在退出时自动释放锁。
1.1 synchronized 的使用方式
-
修饰实例方法： 锁定的是当前实例对象。
public class SynchronizedExample { public synchronized void method1() { // 临界区代码 } } -
修饰静态方法： 锁定的是当前类的 Class 对象。
public class SynchronizedExample { public static synchronized void method2() { // 临界区代码 } } -
修饰代码块： 锁定的是
synchronized括号中指定的对象。public class SynchronizedExample { private Object lock = new Object(); public void method3() { synchronized (lock) { // 临界区代码 } } }
1.2 synchronized 的底层实现
synchronized 的底层实现依赖于 JVM。在 Java 6 之前，synchronized 被认为是一个重量级锁，因为它依赖于操作系统的互斥量（Mutex）。每次获取或释放锁都需要进行用户态和内核态之间的切换，开销较大。
从 Java 6 开始，JVM 对 synchronized 进行了大量的优化，引入了锁升级的概念：
- 偏向锁（Biased Locking）： 当一个线程访问一个同步块并获取锁时，会在对象头中记录该线程的 ID。后续该线程再次进入这个同步块时，无需进行任何同步操作，直接获得锁。 偏向锁适用于只有一个线程访问同步块的场景。
- 轻量级锁（Lightweight Locking）： 当多个线程竞争同一个锁时，偏向锁会升级为轻量级锁。线程会将对象头中的 Mark Word 复制到自己的线程栈帧中，然后使用 CAS（Compare and Swap）操作尝试将对象头中的 Mark Word 替换为指向自己线程栈帧的指针。如果 CAS 操作成功，则该线程获得锁；如果 CAS 操作失败，则表示存在竞争，轻量级锁会膨胀为重量级锁。
- 重量级锁（Heavyweight Locking）： 当多个线程竞争同一个锁，并且 CAS 操作多次失败时，轻量级锁会膨胀为重量级锁。重量级锁依赖于操作系统的互斥量（Mutex），线程需要进入阻塞状态，等待操作系统唤醒。
锁升级的过程是不可逆的，只能从偏向锁升级为轻量级锁，再升级为重量级锁。 这种锁升级机制可以有效降低 synchronized 的开销，提高并发性能。
1.3 锁消除和锁粗化
除了锁升级之外，JVM 还会进行锁消除（Lock Elision）和锁粗化（Lock Coarsening）等优化。
- 锁消除： 如果 JVM 能够确定一个同步块只会被一个线程访问，那么 JVM 就会消除这个同步块上的锁。
- 锁粗化： 如果 JVM 发现多个相邻的同步块使用了同一个锁，那么 JVM 会将这些同步块合并成一个更大的同步块，从而减少锁的获取和释放次数。
这些优化都是由 JIT（Just-In-Time）编译器在运行时进行的，可以进一步提高 synchronized 的性能。
2. ReentrantLock 类：显式锁机制
ReentrantLock 是 java.util.concurrent.locks 包中提供的一个显式锁类。与 synchronized 相比，ReentrantLock 提供了更多的功能，例如：
- 可重入性： 允许同一个线程多次获取同一个锁。
- 公平性： 可以指定锁的获取顺序，例如公平锁，按照线程请求锁的顺序来分配锁。
- 可中断性： 允许线程在等待锁的过程中被中断。
- 定时锁： 允许线程在指定的时间内尝试获取锁，如果超时则放弃。
- 条件变量： 可以与 Condition 对象一起使用，实现更复杂的线程同步。
2.1 ReentrantLock 的使用方式
import java.util.concurrent.locks.ReentrantLock;
public class ReentrantLockExample {
private ReentrantLock lock = new ReentrantLock();
public void method4() {
lock.lock(); // 获取锁
try {
// 临界区代码
} finally {
lock.unlock(); // 释放锁
}
}
}使用 ReentrantLock 时，必须手动获取和释放锁。 必须将释放锁的操作放在 finally 块中，以确保即使在发生异常的情况下，锁也能够被正确释放，避免死锁。
2.2 ReentrantLock 的底层实现
ReentrantLock 的底层实现基于 AQS（AbstractQueuedSynchronizer）框架。 AQS 是一个用于构建锁和同步器的框架，它使用一个 volatile 的 int 类型的 state 变量来表示同步状态。ReentrantLock 的实现依赖于 AQS 的 state 变量来表示锁的持有状态。
- 获取锁：
ReentrantLock使用 CAS 操作来尝试将 state 变量从 0 更新为 1，表示该线程获取了锁。如果 CAS 操作失败，则表示存在竞争，线程会被放入 AQS 的等待队列中，等待被唤醒。 - 释放锁：
ReentrantLock将 state 变量从 1 更新为 0，表示该线程释放了锁。如果 state 变量变为 0，则会唤醒 AQS 等待队列中的一个线程，让其尝试获取锁。
AQS 使用双向链表来实现等待队列，可以保证线程按照先进先出的顺序获取锁。
2.3 公平锁与非公平锁
ReentrantLock 提供了公平锁和非公平锁两种模式。
- 公平锁： 线程按照请求锁的顺序来获取锁。 当一个线程尝试获取公平锁时，它会首先检查 AQS 等待队列中是否存在等待时间更长的线程。如果存在，则该线程会进入等待队列，等待被唤醒。
- 非公平锁： 线程可以立即尝试获取锁，即使 AQS 等待队列中存在等待时间更长的线程。 非公平锁可以提高并发性能，但可能会导致某些线程长时间无法获取锁，产生饥饿现象。
ReentrantLock 默认使用非公平锁。可以通过构造函数指定使用公平锁：
ReentrantLock fairLock = new ReentrantLock(true); // 创建公平锁3. 性能对比：synchronized vs. ReentrantLock
synchronized 和 ReentrantLock 的性能对比是一个复杂的问题，受到多种因素的影响，例如：
- 竞争激烈程度： 在低竞争环境下，
synchronized经过 JIT 编译优化后，性能可能优于ReentrantLock。在高竞争环境下，ReentrantLock的性能通常优于synchronized。 - 锁的持有时间： 如果锁的持有时间较短，
synchronized的锁升级机制可以有效降低开销。 如果锁的持有时间较长，ReentrantLock的可中断性和定时锁等特性可能更有优势。 - JVM 版本： 不同版本的 JVM 对
synchronized的优化程度不同，性能也会有所差异。
为了更直观地对比它们的性能，我们设计一个简单的基准测试。
3.1 基准测试代码
import java.util.concurrent.locks.ReentrantLock;
public class LockPerformanceTest {
private static final int ITERATIONS = 10000000;
private static final int THREADS = 4;
private static int counter = 0;
private static ReentrantLock lock = new ReentrantLock();
public static void main(String[] args) throws InterruptedException {
System.out.println("Starting performance test...");
// Test synchronized
long startTime = System.currentTimeMillis();
testSynchronized();
long endTime = System.currentTimeMillis();
System.out.println("Synchronized took: " + (endTime - startTime) + " ms");
// Reset counter
counter = 0;
// Test ReentrantLock
startTime = System.currentTimeMillis();
testReentrantLock();
endTime = System.currentTimeMillis();
System.out.println("ReentrantLock took: " + (endTime - startTime) + " ms");
System.out.println("Finished performance test.");
}
private static void testSynchronized() throws InterruptedException {
Thread[] threads = new Thread[THREADS];
for (int i = 0; i < THREADS; i++) {
threads[i] = new Thread(() -> {
for (int j = 0; j < ITERATIONS / THREADS; j++) {
synchronized (LockPerformanceTest.class) {
counter++;
}
}
});
threads[i].start();
}
for (int i = 0; i < THREADS; i++) {
threads[i].join();
}
System.out.println("Synchronized Counter: " + counter);
}
private static void testReentrantLock() throws InterruptedException {
Thread[] threads = new Thread[THREADS];
for (int i = 0; i < THREADS; i++) {
threads[i] = new Thread(() -> {
for (int j = 0; j < ITERATIONS / THREADS; j++) {
lock.lock();
try {
counter++;
} finally {
lock.unlock();
}
}
});
threads[i].start();
}
for (int i = 0; i < THREADS; i++) {
threads[i].join();
}
System.out.println("ReentrantLock Counter: " + counter);
}
}3.2 测试结果分析
在低竞争环境下（例如单线程环境），synchronized 的性能可能略优于 ReentrantLock，因为 synchronized 经过 JIT 编译优化后，可以消除锁的开销。
在高竞争环境下，ReentrantLock 的性能通常优于 synchronized。 这是因为 ReentrantLock 提供了更细粒度的锁控制，可以避免不必要的锁竞争。 此外，ReentrantLock 的可中断性和定时锁等特性在高并发场景下也更有优势。
以下表格总结了 synchronized 和 ReentrantLock 的主要性能特征：
| 特性 | synchronized | ReentrantLock |
|---|---|---|
| 性能 | 低竞争环境下可能优于 ReentrantLock，高竞争环境下通常较差 | 高竞争环境下通常优于 synchronized |
| 锁的持有时间 | 短时间持有锁时性能较好 | 长时间持有锁时性能较好 |
| 灵活性 | 较低 | 较高 |
| 可中断性 | 不可中断 | 可中断 |
| 公平性 | 非公平 | 可选公平或非公平 |
| 底层实现 | JVM 内置，依赖锁升级和 JIT 优化 | AQS 框架 |
| 使用方式 | 隐式 | 显式 |
3.3 结论
选择 synchronized 还是 ReentrantLock，取决于具体的应用场景。
- 如果竞争不激烈，或者锁的持有时间较短，可以使用
synchronized，因为它使用简单，并且经过 JVM 的优化，性能可能不错。 - 如果竞争激烈，或者需要更细粒度的锁控制，或者需要可中断性和定时锁等特性，可以使用
ReentrantLock。
4. JIT 编译优化对 synchronized 的影响
JIT 编译器是 JVM 的核心组件之一，它负责将 Java 字节码转换为机器码，从而提高程序的执行效率。 JIT 编译器对 synchronized 关键字进行了大量的优化，例如锁消除、锁粗化和锁升级等。
4.1 锁消除
如果 JIT 编译器能够确定一个同步块只会被一个线程访问，那么 JIT 编译器就会消除这个同步块上的锁。 锁消除可以有效降低 synchronized 的开销，提高程序的性能。
public class LockEliminationExample {
public void method5() {
Object lock = new Object();
synchronized (lock) {
// 临界区代码
}
}
}在这个例子中，lock 对象只在 method5 方法中使用，并且只会被一个线程访问。 因此，JIT 编译器可以消除 synchronized (lock) 语句上的锁。
4.2 锁粗化
如果 JIT 编译器发现多个相邻的同步块使用了同一个锁，那么 JIT 编译器会将这些同步块合并成一个更大的同步块，从而减少锁的获取和释放次数。 锁粗化可以有效提高程序的性能。
public class LockCoarseningExample {
private Object lock = new Object();
public void method6() {
synchronized (lock) {
// 临界区代码 1
}
synchronized (lock) {
// 临界区代码 2
}
synchronized (lock) {
// 临界区代码 3
}
}
}在这个例子中，method6 方法中有三个相邻的同步块，它们都使用了同一个锁 lock。 因此，JIT 编译器可以将这三个同步块合并成一个更大的同步块：
public class LockCoarseningExample {
private Object lock = new Object();
public void method6() {
synchronized (lock) {
// 临界区代码 1
// 临界区代码 2
// 临界区代码 3
}
}
}4.3 锁升级
前面已经介绍了锁升级的概念，这里不再赘述。 锁升级是 JVM 对 synchronized 进行的重要优化之一，可以有效降低锁的开销，提高程序的并发性能。
5. 底层实现的差异：Mutex vs. AQS
synchronized 和 ReentrantLock 的底层实现存在显著差异。
synchronized的底层实现依赖于操作系统的互斥量（Mutex），或者 JVM 的锁升级机制，本质上还是对 Mutex 的封装。 Mutex 是一种重量级锁，每次获取或释放锁都需要进行用户态和内核态之间的切换，开销较大。ReentrantLock的底层实现基于 AQS 框架。 AQS 使用 CAS 操作和等待队列来实现锁的获取和释放。 CAS 操作是一种轻量级操作，可以在用户态完成，避免了用户态和内核态之间的切换。
因此，在竞争激烈的情况下，ReentrantLock 的性能通常优于 synchronized。
| 实现方式 | synchronized | ReentrantLock |
|---|---|---|
| 底层机制 | Mutex (操作系统互斥量) 或 JVM 锁升级机制 | AQS (AbstractQueuedSynchronizer) 框架 |
| 性能开销 | 用户态/内核态切换，开销较大 | CAS 操作，用户态完成，开销较小 |
| 适用场景 | 竞争不激烈，锁持有时间短 | 竞争激烈，需要更细粒度的控制，定制锁需求 |
6. 总结：选择合适的锁机制
synchronized 和 ReentrantLock 都是 Java 并发编程中重要的同步机制。 它们各有优缺点，适用于不同的应用场景。 理解它们的底层实现和性能特征，可以帮助我们选择合适的锁机制，提高程序的并发性能。 在选择锁的时候，需要根据实际情况进行权衡，选择最适合的锁机制。