为什么用synchronized代替ReentrantLock

diannao/2025/10/1 18:39:57/文章来源:href="https://blog.51cto.com/u_16717381/14108834" target="_blank"

ReentrantLock 和 synchronized 都是 Java 中用于实现线程同步的机制，它们的功能相似，都是用来保证多线程并发访问共享资源时的线程安全性。但是，尽管它们在功能上类似，synchronized 和 ReentrantLock 之间有一些差异，选择哪一个取决于具体的使用场景。

1. `synchronized` 和 `ReentrantLock` 的对比

1.1 语法上的简洁性

synchronized 是 Java 提供的语言级别的同步机制，语法非常简洁且易于使用。它可以通过修饰方法或者代码块来实现同步。使用时，JVM 会自动处理锁的获取和释放。
示例：

public synchronized void method() {// 临界区代码
}

或者：

public void method() {synchronized (lock) {// 临界区代码}
}

ReentrantLock 是 Java 提供的显式锁，是通过 Lock 接口实现的，需要手动进行锁的获取和释放。
示例：

Lock lock = new ReentrantLock();
lock.lock();
try {// 临界区代码
} finally {lock.unlock();
}

1.2 可重入性

synchronized 和 ReentrantLock 都是可重入的，也就是说，当前线程如果已经持有该锁，那么它可以再次进入同步代码块而不被阻塞。
例如：

public synchronized void methodA() {methodB();  // 调用另一个同步方法
}public synchronized void methodB() {// 临界区代码
}

ReentrantLock 也具有类似的特性，当前线程可以多次调用 lock() 而不会死锁。

1.3 锁的获取与释放

synchronized 是一种隐式锁机制，当代码块执行结束（包括异常抛出时），JVM 会自动释放锁。这就意味着你无需显式地释放锁。
ReentrantLock 是显式锁，需要手动调用 lock() 获取锁，调用 unlock() 释放锁。通常在 finally 代码块中释放锁，以保证无论是否发生异常，锁都能被释放。

1.4 锁的可中断性

synchronized 无法响应中断。也就是说，如果一个线程正在等待获取某个锁，它不能被中断（即使线程被中断，等待锁的线程依然会继续等待）。
ReentrantLock 提供了 lockInterruptibly() 方法，该方法可以在等待锁的过程中响应中断，使得线程可以在等待锁的时候被中断。这在某些场景下非常有用，例如避免死锁或长时间的阻塞。
示例：

try {lock.lockInterruptibly();// 临界区代码
} catch (InterruptedException e) {// 处理中断
}

1.5 尝试锁

synchronized 不支持超时机制。线程如果无法获取锁，会一直阻塞，直到获取到锁。
ReentrantLock 提供了 tryLock() 方法，允许线程尝试获取锁，并在一定时间内等待。如果没有获取到锁，它可以选择继续执行或者做其他处理。
示例：

if (lock.tryLock()) {try {// 临界区代码} finally {lock.unlock();}
} else {// 没有获取到锁，进行其他处理
}

1.6 公平锁与非公平锁

synchronized 是非公平的锁。即，无法保证先请求锁的线程一定先获得锁。
ReentrantLock 支持公平锁。在创建 ReentrantLock 时，可以选择是否设置为公平锁。公平锁的特点是，线程会按照请求锁的顺序获取锁。
示例：

Lock lock = new ReentrantLock(true);  // 公平锁

2. 为什么选择 `synchronized` 替代 `ReentrantLock`？

尽管 ReentrantLock 提供了更多的控制选项（如可中断锁、超时尝试锁、是否公平等），synchronized 仍然是更常用的选择，原因如下：

2.1 简洁性与易用性

synchronized 是语言级别的同步机制，语法非常简单，不需要显式地调用 lock() 和 unlock()。对于大多数基本的同步需求，synchronized 语法非常直观和简洁，避免了 ReentrantLock 中手动管理锁的问题。

2.2 性能优势

对于简单的同步需求，synchronized 具有 较低的开销。Java 在不断优化 synchronized，特别是锁的轻量化和自旋锁等机制使得 synchronized 在低并发场景下非常高效。
ReentrantLock 虽然提供了更多功能，但其创建和管理锁的机制比 synchronized 更加复杂，并且在简单场景下可能引入额外的性能开销。

2.3 自动释放锁

synchronized 通过 JVM 自动释放锁，不需要手动管理，减少了开发者出错的概率。在使用 ReentrantLock 时，开发者必须显式调用 unlock()，并且通常要在 finally 代码块中释放锁。如果开发者忘记释放锁，会导致死锁或其他线程问题。

2.4 适用于大部分同步场景

对于大多数的 简单同步 场景，synchronized 已经足够使用。它是 Java 提供的最基础的同步工具，能很好地处理很多常见的同步问题。

3. 什么时候使用 `ReentrantLock` 而非 `synchronized`?

尽管 synchronized 在大多数简单场景下已经足够使用，但 ReentrantLock 提供了更丰富的功能，在一些高级场景下，它的优势是显而易见的：

3.1 需要中断响应

如果需要在等待锁的过程中响应中断（避免死锁或长时间阻塞），ReentrantLock 的 lockInterruptibly() 方法是不可或缺的。

3.2 尝试获取锁

如果在某些情况下你希望在不等待的情况下尝试获取锁，tryLock() 是非常有用的。它能让线程在无法立即获取锁时继续做其他工作，而不会无休止地阻塞。

3.3 公平性需求

如果你希望确保线程按照请求锁的顺序来获取锁，可以使用 ReentrantLock 的公平锁模式（通过 new ReentrantLock(true) 来指定）。

3.4 复杂锁定机制

当涉及到复杂的加锁和解锁场景时，ReentrantLock 提供了更细粒度的控制，比如可以在不同的代码块中反复加锁和释放锁，或者锁定多个资源时更容易处理。

4. 总结

synchronized 简单易用，适用于大多数同步场景，且由 JVM 自动管理锁的释放，因此对开发者更加友好。
ReentrantLock 提供了更多控制选项（如中断、尝试锁、可重入、锁的公平性等），适用于更复杂的并发控制需求，但需要开发者手动管理锁，且在简单场景下性能可能不如 synchronized。

总的来说，选择 synchronized 还是 ReentrantLock 取决于具体的场景：