synchronized 和 ReentrantLock 的异同点是什么？-java教程-PHP中文网

synchronized是Java内置的隐式锁，使用简单且由JVM自动管理锁的获取与释放，适合大多数简单的同步场景，具备良好的性能优化（如偏向锁、轻量级锁）；而ReentrantLock是显式锁，需手动调用lock()和unlock()，提供了更灵活的控制能力，如公平锁、非阻塞尝试获取锁（tryLock）、可中断锁获取（lockInterruptibly）以及多条件变量（Condition），适用于复杂并发控制需求。随着JVM对synchronized的持续优化，二者在性能上的差距已不明显，选择时应优先考虑功能需求：若无需高级特性，synchronized更简洁安全；若需精细控制，则应选用ReentrantLock。

synchronized 和 reentrantlock 的异同点是什么？

synchronized

登录后复制

和

ReentrantLock

登录后复制

在 Java 并发编程中都是实现线程同步的基石，它们的核心目标都是确保在给定时间只有一个线程能访问临界区，从而避免数据不一致。不过，它们在用法、灵活性和底层实现上有着显著的区别。简单来说，

synchronized

登录后复制

是 Java 语言层面提供的内置锁，更偏向于隐式和便捷；而

ReentrantLock

登录后复制

则是

java.util.concurrent.locks

登录后复制

包下的一个类，提供了更丰富、更显式的锁操作。

解决方案

在我看来，理解

synchronized

登录后复制

和

ReentrantLock

登录后复制

的异同，就像是在选择一把日常用的钥匙和一套高级的安防系统。

synchronized

登录后复制

就像是那把我们从小用到大的普通钥匙，简单、直接、可靠。你用它开门，门自动就锁上了；你出门，门自动就关好了，不用你操心。它的锁机制是内置在 JVM 中的，可以作用于方法或者代码块。当一个线程进入

synchronized

登录后复制

修饰的代码块或方法时，它会自动获取对象的监视器锁（monitor lock），离开时则自动释放。这种自动管理机制，大大降低了死锁和忘记释放锁的风险，对于我们日常开发中大多数简单的同步需求来说，简直是福音。

然而，这把“普通钥匙”也有它的局限性。比如说，你不能选择这把钥匙是“公平”地分配给等待最久的那个线程，还是“不公平”地让刚到的线程也可能插队。它也不支持尝试获取锁（

tryLock

登录后复制

），你只能傻傻地等着，直到锁被释放。更关键的是，如果一个线程在等待锁的过程中被中断了，

synchronized

登录后复制

是不会响应的，它会继续等待下去，这在某些需要快速响应和取消操作的场景下就显得有些力不从心了。

这时候，

ReentrantLock

登录后复制

就登场了，它更像是一个可编程的、功能强大的安防系统。它提供了更精细的控制能力，你需要显式地调用

lock()

登录后复制

方法来获取锁，并在

finally

登录后复制

块中调用

unlock()

登录后复制

来释放锁。这种显式控制虽然增加了编码的复杂度，但却带来了巨大的灵活性。

ReentrantLock

登录后复制

最大的特点就是它的“可重入性”，这一点和

synchronized

登录后复制

是相同的，即持有锁的线程可以再次获取该锁而不会死锁。但

ReentrantLock

登录后复制

提供了更多高级特性：

公平性选择（Fairness）：你可以选择构造一个公平锁（
```
new ReentrantLock(true)
```
登录后复制
），让等待时间最长的线程优先获取锁，这在某些需要严格按序处理的场景下很有用。当然，非公平锁（默认）通常性能会更好一些，因为它减少了线程切换的开销。
尝试获取锁（
tryLock()
登录后复制
）：这个功能我个人觉得非常实用。你可以尝试获取锁，如果成功了就执行临界区代码；如果失败了，你可以选择做其他事情，而不是无限期地等待。这避免了线程的阻塞，提高了程序的响应性。
可中断的锁获取（
lockInterruptibly()
登录后复制
）：这是
```
synchronized
```
登录后复制
无法比拟的。如果一个线程在等待
```
ReentrantLock
```
登录后复制
的过程中收到了中断信号，它可以立即停止等待并处理中断，这对于构建更健壮、响应更快的并发应用至关重要。
条件变量（
Condition
登录后复制
）：
```
ReentrantLock
```
登录后复制
可以配合
```
Condition
```
登录后复制
对象实现更复杂的线程间协作，比如生产者-消费者模型。一个
```
ReentrantLock
```
登录后复制
可以创建多个
```
Condition
```
登录后复制
对象，每个
```
Condition
```
登录后复制
都可以有自己的等待队列，这比
```
Object
```
登录后复制
的
```
wait()/notify()
```
登录后复制
机制要灵活得多，因为
```
Object
```
登录后复制
只有一个等待队列。

从性能角度看，早期

ReentrantLock

登录后复制

曾因其基于 AQS（AbstractQueuedSynchronizer）的实现，在某些场景下表现出比

synchronized

登录后复制

更好的性能。但随着 JVM 对

synchronized

登录后复制

进行了大量的优化，比如引入了偏向锁（Biased Locking）、轻量级锁（Lightweight Locking）和自旋锁（Spinning），两者的性能差距在大多数常见场景下已经不那么明显了，甚至在某些情况下

synchronized

登录后复制

的性能会更好，因为它减少了用户态和内核态的切换开销。我个人在做性能优化时，如果不是对

ReentrantLock

登录后复制

的高级特性有硬性需求，通常会先考虑

synchronized

登录后复制

的简洁性。

在什么场景下，我们应该优先选择

synchronized

登录后复制

而不是

ReentrantLock

登录后复制

？

在我日常的开发中，如果同步需求比较简单，我通常会毫不犹豫地选择

synchronized

登录后复制

。它最大的优势就是简洁性和自动化管理。当你的临界区代码块或方法执行完毕，或者抛出异常时，JVM 会自动帮你释放锁，你完全不用担心忘记

unlock()

登录后复制

导致死锁的问题。这种隐式锁的机制，大大降低了编码的复杂度和出错的概率。

比如，你只是想保护一个计数器，或者一个简单的共享变量的读写操作，用

synchronized

登录后复制

修饰一个方法或者一个代码块，就能非常优雅地解决问题。它的代码可读性也很好，一眼就能看出哪里是受保护的区域。而且，JVM 对

synchronized

登录后复制

做了大量的底层优化，包括偏向锁、轻量级锁等，使得它在竞争不激烈或者单线程重复获取锁的场景下，性能表现非常出色，甚至可能优于

ReentrantLock

登录后复制

。对于那些不需要

ReentrantLock

登录后复制

提供的额外高级特性（如公平锁、条件变量、可中断锁等）的场景，

synchronized

登录后复制

往往是更简单、更可靠、更高效的选择。简单来说，如果你不需要那些“花里胡哨”的功能，只是想安全地访问共享资源，

synchronized

登录后复制

就是你的首选。

什么时候

ReentrantLock

登录后复制

的高级特性变得不可或缺？

在我看来，

ReentrantLock

登录后复制

的高级特性在处理复杂并发场景时，简直是救命稻草。当你发现

synchronized

登录后复制

的局限性让你捉襟见肘时，就是

ReentrantLock

登录后复制

大显身手的时候了。

最典型的例子就是需要非阻塞地尝试获取锁。想象一下，你有一个任务，它需要访问某个资源，但如果这个资源被锁住了，你不想让它一直等下去，而是希望它能立即去做别的事情，或者过一会儿再尝试。这时候

ReentrantLock

登录后复制

的

tryLock()

登录后复制

方法就派上用场了。你可以这样写：

造点AI

夸克 · 造点AI

325

查看详情

ReentrantLock lock = new ReentrantLock();
// ...
if (lock.tryLock()) {
    try {
        // 访问临界区资源
        System.out.println(Thread.currentThread().getName() + " 成功获取锁并执行任务。");
    } finally {
        lock.unlock();
    }
} else {
    // 锁被其他线程持有，执行备用方案或稍后重试
    System.out.println(Thread.currentThread().getName() + " 未能获取锁，执行其他操作。");
}

登录后复制

这比

synchronized

登录后复制

只能傻等要灵活得多。

另一个不可或缺的场景是可中断的锁获取。设想一个长时间运行的任务，它需要获取一个锁。如果用户突然取消了这个任务，你肯定希望它能尽快停止，而不是继续等待一个遥遥无期的锁。

ReentrantLock

登录后复制

的

lockInterruptibly()

登录后复制

方法就能做到这一点。当等待锁的线程被中断时，它会抛出

InterruptedException

登录后复制

，允许你优雅地处理中断逻辑。

此外，多条件变量的需求也是

ReentrantLock

登录后复制

独有的。在复杂的生产者-消费者模型中，可能存在多种等待条件。例如，一个缓冲区可能既有“满了”的条件（生产者等待），也有“空了”的条件（消费者等待）。

ReentrantLock

登录后复制

可以通过

newCondition()

登录后复制

方法创建多个

Condition

登录后复制

对象，每个

Condition

登录后复制

都可以管理自己独立的等待队列，从而实现更精细的线程间通信和协作，这比

Object

登录后复制

单一的

wait()/notifyAll()

登录后复制

机制要强大得多。

最后，如果你对锁的公平性有严格要求，比如你希望等待时间最长的线程能够优先获取锁，那么

ReentrantLock

登录后复制

的公平锁构造函数 (

new ReentrantLock(true)

登录后复制

) 也是

synchronized

登录后复制

无法提供的。虽然公平锁通常会带来性能上的开销，但在某些业务场景下，公平性是至关重要的。

从性能和JVM优化的角度看，二者有何演变和考量？

在我刚接触 Java 并发编程的那些年，

ReentrantLock

登录后复制

经常被宣传为比

synchronized

登录后复制

性能更好的选择，尤其是在高并发竞争的场景下。这主要是因为

ReentrantLock

登录后复制

是在用户态实现的，基于 AQS（AbstractQueuedSynchronizer）框架，它避免了每次锁竞争都陷入操作系统内核态的开销，这在当时确实是一个显著的优势。

然而，随着 Java 虚拟机（JVM）的不断演进，尤其是从 JDK 6 开始，

synchronized

登录后复制

的性能得到了革命性的提升。JVM 引入了多种优化策略，让

synchronized

登录后复制

在很多场景下不再是性能瓶颈：

偏向锁（Biased Locking）：当一个线程多次获取同一个锁时，JVM 会“偏向”这个线程，在它再次获取锁时，几乎不需要任何同步开销。这对于大部分锁都是由同一个线程重复获取的场景（比如循环中的方法调用）非常有效。
轻量级锁（Lightweight Locking）：当多个线程交替获取锁，但没有发生激烈竞争时，JVM 会使用 CAS（Compare-And-Swap）操作在栈帧中尝试获取锁，避免了重量级锁的开销。
自旋锁（Spinning）：如果一个线程尝试获取锁但失败了，它不会立即阻塞，而是会短暂地“自旋”一段时间（空循环），看看锁是否很快被释放。如果锁很快被释放，那么这个线程就可以避免一次上下文切换的开销。
锁消除（Lock Elimination）和锁粗化（Lock Coarsening）：这是 JIT 编译器在运行时进行的优化。如果编译器分析发现某个锁根本没有跨线程共享，它会直接消除这个锁操作；如果发现连续的多个锁操作是针对同一个对象，它可能会将这些锁操作合并成一个更大的锁区域，减少加锁/解锁的次数。

这些优化使得