Java的ReentrantLock详解
原创Java的ReentrantLock详解
原创
ReentrantLock 是 Java 并发包（java.util.concurrent.locks）中的一个可重入锁实现，它提供了比 synchronized 关键字更灵活、功能更丰富的线程同步机制。ReentrantLock类内部总共存在Sync、NonfairSync、FairSync三个类，NonfairSync（非公平锁）与FairSync（公平锁）类继承自Sync类，Sync类继承自AbstractQueuedSynchronizer抽象类。
可重入性
，ReentrantLock 是一种可重入锁。这意味着持有锁的线程可以再次获取该锁，而不会发生死锁。每次成功获取锁都会增加锁的持有计数，相应的释放锁操作会减少计数。当计数降至零时，锁才会真正释放给其他等待的线程。这种特性使得在递归调用或嵌套同步块中使用同一线程多次获取同一锁成为可能。
公平性
ReentrantLock 默认实现的是非公平锁。同时，ReentrantLock 提供了公平锁和非公平锁两种模式。在构造时可以通过传递布尔参数指定：
- 公平锁（true）：按照线程请求锁的顺序进行排队，先请求的线程优先获得锁。公平锁倾向于减少线程饥饿现象，但可能降低系统的整体吞吐量。
- 非公平锁（默认，false）：不保证按照线程请求锁的顺序分配锁，允许后来的线程“插队”获取锁。非公平锁在某些场景下可能提供更高的性能，但可能增加线程饥饿的风险。
显式锁操作
与 synchronized 关键字不同，ReentrantLock 需要显式地调用方法来获取和释放锁：
- lock()：尝试获取锁。如果锁不可用，当前线程将被阻塞直到锁变得可用。
- tryLock()：尝试非阻塞地获取锁。如果锁可用，立即返回 true；否则返回 false。
- tryLock(long timeout, TimeUnit unit)：尝试在指定时间内获取锁。如果在超时时间内锁不可用，返回 false。
- unlock()：释放锁。必须确保在持有锁的线程中正确调用此方法，否则可能导致死锁或其他同步问题。
条件变量（Condition）
ReentrantLock 还支持条件变量，通过 newCondition() 方法创建 Condition 对象。条件变量允许线程在满足特定条件时等待，直到其他线程通知它们条件已发生变化。与 Object 类的 wait()、notify() 和 notifyAll() 方法相比，条件变量提供了更精细的线程同步控制：
- await()：当前线程进入等待状态，释放锁，并在其他线程调用对应 Condition 对象的 signal() 或 signalAll() 方法时唤醒。
- signal()：唤醒一个等待在该 Condition 上的线程，但不释放锁。
- signalAll()：唤醒所有等待在该 Condition 上的线程，但不释放锁。
ReentrantLock使用
public static void main(String[] args) throws InterruptedException {
List<Thread> threads = new ArrayList<>();
// 创建5个线程共享公平锁
for (int i = 0; i < 5; i++) {
Thread thread = new Thread(() -> testLock(fairLock, "FairLock"));
threads.add(thread);
thread.start();
}
// 创建5个线程共享非公平锁
for (int i = 0; i < 5; i++) {
Thread thread = new Thread(() -> testLock(nonFairLock, "NonFairLock"));
threads.add(thread);
thread.start();
}
// 等待所有线程执行完毕
for (Thread thread : threads) {
thread.join();
}
}testLock方法：
private static void testLock(Lock lock, String lockType) {
for (int i = 0; i < 10; i++) {
// 尝试获取锁
lock.lock();
try {
System.out.println(Thread.currentThread().getName() + " acquired " + lockType + ", iteration: " + i);
// 模拟耗时操作
Thread.sleep(50);
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
// 释放锁
lock.unlock();
}
}
}当运行这个程序时，您应该能看到公平锁和非公平锁在多线程竞争下的差异。公平锁倾向于按照线程请求锁的顺序给予锁，而非公平锁可能会让后来的线程“插队”获取锁：
FairSync公平锁代码分析
static final class FairSync extends Sync {
private static final long serialVersionUID = -3000897897090466540L;
/\*\*
\* Acquires only if reentrant or queue is empty.
\*/
final boolean initialTryLock() {
Thread current = Thread.currentThread();
//当state为0时，表示锁未被任何线程持有；若为正整数，表示锁被某个线程持有，数值表示该线程的重入次数。
int c = getState();
if (c == 0) {
//检查等待队列中是否有其他线程正在等待。
//如果!hasQueuedThreads()返回true，表示当前没有其他线程在等待队列中。
//调用compareAndSetState(0, 1)尝试原子性地将state从0改为1，这一步相当于尝试获取锁。如果该操作成功，说明当前线程成功获得了锁。
if (!hasQueuedThreads() && compareAndSetState(0, 1)) {
//设置独占线程
setExclusiveOwnerThread(current);
return true;
}
//如果state不为0（即锁已被持有），则检查当前持有锁的线程是否就是当前线程。
//如果是，说明当前线程正在尝试重入获取锁。
} else if (getExclusiveOwnerThread() == current) {
//发生溢出
if (++c < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(c);
return true;
}
return false;
}当资源空闲时，它总是会先判断sync队列(AbstractQueuedSynchronizer中的数据结构)是否有等待时间更长的线程，如果存在，则将该线程加入到等待队列的尾部，实现了公平获取原则。
NonfairSync 非公平锁代码分析
final boolean initialTryLock() {
Thread current = Thread.currentThread();
// 比较并设置状态成功，状态0表示锁没有被占用
if (compareAndSetState(0, 1)) { // first attempt is unguarded
//// 把当前线程设置独占了锁
setExclusiveOwnerThread(current);
return true;
} else if (getExclusiveOwnerThread() == current) {
int c = getState() + 1;
if (c < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(c);
return true;
} else
return false;
}从lock方法的源码可知，每一次都尝试获取锁，而并不会按照公平等待的原则进行等待，让等待时间最久的线程获得锁。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。