synchronized与ReentrantLock区别全解析

在Java并发编程中，`synchronized`和`ReentrantLock`都是实现线程同步的关键工具，用于确保临界区资源在同一时间仅被一个线程访问，避免数据不一致。`synchronized`作为Java内置的隐式锁，使用简便，由JVM自动管理锁的获取与释放，适用于简单的同步场景，并具备偏向锁、轻量级锁等性能优化。`ReentrantLock`则是一种显式锁，需手动调用`lock()`和`unlock()`方法，提供更灵活的控制能力，如公平锁、非阻塞尝试获取锁`tryLock()`、可中断锁获取`lockInterruptibly()`以及多条件变量`Condition`，适用于复杂的并发控制需求。虽然早期ReentrantLock在某些场景下性能更优，但随着JVM对`synchronized`的不断优化，二者在性能上的差距已不明显。因此，在选择时应优先考虑功能需求：若无需高级特性，`synchronized`更简洁安全；若需精细控制，则应选用`ReentrantLock`。

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

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 在很多场景下不再是性能瓶颈：

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

这些优化使得 synchronized 在低竞争和单线程重复获取锁的场景下，性能已经非常接近甚至优于 ReentrantLock。因为 ReentrantLock 毕竟是一个对象，它的 lock() 和 unlock() 方法调用本身会带来方法调用的开销，并且在内部也需要进行一些对象操作（如 Condition 对象的创建和管理），这些都是额外的成本。

所以，我现在的看法是，性能不再是选择 synchronized 或 ReentrantLock 的主要考量因素，除非你已经通过性能测试确定锁的类型是瓶颈。更多时候，我们应该根据功能需求和代码的简洁性来做选择。如果你的需求仅仅是简单的互斥访问，并且不需要 ReentrantLock 提供的那些高级特性，那么 synchronized 的简洁和自动管理机制，通常是更好的选择，它能让你写出更少出错、更容易理解的代码。而当你需要更精细的控制，比如可中断、非阻塞尝试、或者多条件变量时，ReentrantLock 才是不可替代的。

今天关于《synchronized与ReentrantLock区别全解析》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！