当前位置：首页 > 文章列表 > 文章 > java教程 > 手把手教你搞定Java中的可重入锁ReentrantLock

手把手教你搞定Java中的可重入锁ReentrantLock

2025-06-18 14:06:14 0浏览收藏

“纵有疾风来，人生不言弃”，这句话送给正在学习文章的朋友们，也希望在阅读本文《Java中可重入锁怎么用？手把手教你搞懂ReentrantLock原理》后，能够真的帮助到大家。我也会在后续的文章中，陆续更新文章相关的技术文章，有好的建议欢迎大家在评论留言，非常感谢！

可重入锁允许一个线程多次获取同一把锁，避免线程自身被锁死。1.ReentrantLock基于AQS实现，通过CAS操作和FIFO队列管理锁的获取与释放；2.可重入性通过判断当前线程是否为锁持有者实现，state值记录重入次数；3.释放锁时减1，state为0才唤醒等待线程；4.可重入性在一定程度上避免死锁，但无法完全解决；5.公平锁按请求顺序分配，非公平锁允许插队，性能更高但可能导致饥饿；6.选择ReentrantLock可获得更灵活控制、公平锁、中断响应等功能，而synchronized则适合简单场景、自动释放锁且可能优化性能。

Java中可重入锁的作用解析ReentrantLock的实现原理

可重入锁，简单来说，就是允许一个线程多次获取同一把锁。这在Java中非常重要，尤其是在复杂的并发场景下，它避免了自己把自己锁死的情况，让代码更灵活。

ReentrantLock的实现原理

ReentrantLock的核心是AQS（AbstractQueuedSynchronizer）。AQS维护了一个同步状态（state）和一个FIFO的等待队列。

获取锁： 当一个线程尝试获取锁时，首先会尝试使用CAS（Compare and Swap）原子操作将state从0变为1。如果成功，则该线程获取锁，并将锁的持有者设置为当前线程。如果state不为0，则检查当前线程是否为锁的持有者。如果是，则将state加1，表示重入次数加1。如果CAS失败，并且当前线程不是锁的持有者，则该线程会被放入AQS的等待队列中，等待被唤醒。
释放锁： 当线程释放锁时，首先检查当前线程是否为锁的持有者。如果不是，则抛出异常。如果是，则将state减1。如果state变为0，则表示锁完全释放，会唤醒等待队列中的一个线程，让其尝试获取锁。
可重入性： ReentrantLock之所以可重入，是因为它在获取锁的时候，会检查当前线程是否为锁的持有者。如果是，则允许重入，并将state加1。这样，同一个线程就可以多次获取同一个锁，而不会被阻塞。

ReentrantLock如何避免死锁？

死锁往往是因为多个线程互相持有对方需要的资源，导致大家都无法继续执行。ReentrantLock的可重入性，在一定程度上避免了死锁的发生。例如，一个线程在已经持有锁的情况下，如果需要再次获取该锁，由于ReentrantLock的可重入性，它可以直接获取，而不会被阻塞。

然而，仅仅依靠ReentrantLock的可重入性并不能完全避免死锁。仍然需要注意锁的获取顺序，以及避免循环依赖等问题。

公平锁与非公平锁的区别？

ReentrantLock可以配置为公平锁或非公平锁。

公平锁： 按照线程请求锁的顺序来分配锁。也就是说，等待队列中最先进入的线程会优先获取锁。公平锁保证了所有线程都有机会获取锁，避免了某些线程长时间饥饿的情况。但公平锁的性能相对较低，因为需要维护等待队列的顺序。
非公平锁： 允许线程“插队”。也就是说，当锁被释放时，如果有线程正在尝试获取锁，它可以直接获取锁，而不需要等待进入等待队列。非公平锁的性能相对较高，因为减少了线程切换的开销。但非公平锁可能导致某些线程长时间饥饿。

选择公平锁还是非公平锁，取决于具体的应用场景。如果对公平性要求较高，可以选择公平锁。如果对性能要求较高，可以选择非公平锁。大多数情况下，非公平锁是更好的选择。

如何选择ReentrantLock而不是synchronized？

synchronized是Java内置的同步机制，而ReentrantLock是一个类，提供了更灵活的锁控制。

选择ReentrantLock的情况：

需要更细粒度的控制： ReentrantLock提供了诸如tryLock()（尝试获取锁）、lockInterruptibly()（可中断的获取锁）等方法，可以更灵活地控制锁的获取和释放。
需要公平锁： synchronized是非公平锁，而ReentrantLock可以配置为公平锁。
需要中断锁的等待： 使用lockInterruptibly()可以在等待锁的过程中响应中断。
需要知道是否获取到了锁： 使用tryLock()可以尝试获取锁，并立即返回是否获取成功，而不会一直阻塞。