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
在很多场景下不再是性能瓶颈：
偏向锁（Biased Locking）：当一个线程多次获取同一个锁时，JVM 会“偏向”这个线程，在它再次获取锁时，几乎不需要任何同步开销。这对于大部分锁都是由同一个线程重复获取的场景（比如循环中的方法调用）非常有效。轻量级锁（Lightweight Locking）：当多个线程交替获取锁，但没有发生激烈竞争时，JVM 会使用 CAS（Compare-And-Swap）操作在栈帧中尝试获取锁，避免了重量级锁的开销。自旋锁（Spinning）：如果一个线程尝试获取锁但失败了，它不会立即阻塞，而是会短暂地“自旋”一段时间（空循环），看看锁是否很快被释放。如果锁很快被释放，那么这个线程就可以避免一次上下文切换的开销。锁消除（Lock Elimination）和锁粗化（Lock Coarsening）：这是 JIT 编译器在运行时进行的优化。如果编译器分析发现某个锁根本没有跨线程共享，它会直接消除这个锁操作；如果发现连续的多个锁操作是针对同一个对象，它可能会将这些锁操作合并成一个更大的锁区域，减少加锁/解锁的次数。
这些优化使得
synchronized
在低竞争和单线程重复获取锁的场景下，性能已经非常接近甚至优于
ReentrantLock
。因为
ReentrantLock
毕竟是一个对象，它的
lock()
和
unlock()
方法调用本身会带来方法调用的开销，并且在内部也需要进行一些对象操作（如
Condition
对象的创建和管理），这些都是额外的成本。
所以，我现在的看法是，性能不再是选择
synchronized
或
ReentrantLock
的主要考量因素，除非你已经通过性能测试确定锁的类型是瓶颈。更多时候，我们应该根据功能需求和代码的简洁性来做选择。如果你的需求仅仅是简单的互斥访问，并且不需要
ReentrantLock
提供的那些高级特性，那么
synchronized
的简洁和自动管理机制，通常是更好的选择，它能让你写出更少出错、更容易理解的代码。而当你需要更精细的控制，比如可中断、非阻塞尝试、或者多条件变量时，
ReentrantLock
才是不可替代的。
以上就是synchronized 和 ReentrantLock 的异同点是什么？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/89910.html
微信扫一扫 
支付宝扫一扫 
