ReentrantLock学习
一.公平锁与分公平锁
ReentrantLock 支持两种锁：公平锁和非公平锁。何谓公平性，是针对获取锁而言的，如果一个锁是公平的，那么锁的获取顺序就应该符合请求上的绝对时间顺序，满足 FIFO。
1.1公平锁的处理流程：
- 场景： 假设线程 A、B、C 按顺序请求获取锁。
- 操作：
- 线程 A 获取到锁，执行完毕后释放。
- 锁被释放时，线程 B 是队列中等待时间最久的线程，因此它被唤醒并获取到锁。
- 线程 B 执行完毕后，唤醒队列中等待时间最久的线程 C。
特点： 锁的获取严格按照请求顺序（FIFO），确保所有线程公平排队。
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
公平锁在加锁的时候会有hasQueuedPredecessors来判断等待队列,从而实现公平锁
1.2非公平锁的处理流程：
- 场景： 假设线程 A 正在持有锁，线程 B、C 已经进入等待队列，线程 D 此时突然请求锁。
- 操作：
- 线程 A 释放锁后，线程 D 直接尝试抢占锁，而不考虑队列中等待时间更长的线程 B 和 C。
- 如果线程 D 成功抢占锁，队列中的线程 B 和 C 需要继续等待。
- 线程 D 执行完毕后，锁再次释放，队列中的线程才有机会尝试获取锁。
特点： 非公平锁允许后来的线程“插队”，可能导致等待队列中的线程长期得不到执行（饥饿问题）。
ReentrantLock 的构造方法无参时是构造非公平锁，源码为：
public ReentrantLock() {
sync = new NonfairSync();
}
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
二.加锁流程(以非公平锁为例来分析)
假设目前没有线程来进行锁竞争,当我们执行lock方法时
public void lock() {
sync.lock();
}
会执行sync的lock方法,如下(这里是NoFairSync的实现):
final void lock() {
//cas进行加锁
if (compareAndSetState(0, 1))
//加锁成功,设置锁的拥有者为当前线程
setExclusiveOwnerThread(Thread.currentThread());
else
//加锁失败
acquire(1);
}
当然由于没有线程和他竞争,第一次会加锁成功.
假设第一个线程没有释放掉锁,有另一个线程来竞争锁,根据上文的lock方法,会走acquire方法
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
首先会走tryAcquire方法再次尝试获取锁,成功为true,失败为false
inal boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
//c=0的时候说明可以获取锁
if (c == 0) {
//cas获取锁
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
//成功返回
return true;
}
}
//获取锁的是当前线程,则可重入
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
//成功放回
return true;
}
//以上条件都不成立,返回失败
return false;
}
然后会执行addWaiter(Node.EXCLUSIVE) 锁未获取成功，将当前线程封装成一个独占模式的节点（Node.EXCLUSIVE）并加入等待队列。返回值是队列中的新节点，用于后续操作。
private Node addWaiter(Node mode) {
// 创建一个新的 Node 节点，表示当前线程并指定模式（独占或共享）
Node node = new Node(Thread.currentThread(), mode);
// 快速路径尝试直接将新节点添加到队列尾部
Node pred = tail; // 获取当前队列尾节点
if (pred != null) {
node.prev = pred; // 设置新节点的前驱为当前尾节点
// CAS 操作尝试将新节点设置为队列的尾节点
if (compareAndSetTail(pred, node)) {
pred.next = node; // 成功后，更新前驱节点的 next 指针指向新节点
return node; // 返回新节点，快速路径完成
}
}
// 快速路径失败时，进入完整的入队操作
enq(node);
return node; // 返回添加到队列中的节点
}
然后他会将保证为node 结点的线程交给acquireQueued方法处理.当前线程在等待队列中等待锁的释放。当锁可用时，通过自旋的方式不断检查条件，并尝试获取锁。返回值： 如果线程在等待过程中被中断，返回 true；否则返回 false。
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true; // 标记是否获取锁失败，用于异常情况的清理
try {
boolean interrupted = false; // 标记线程在等待过程中是否被中断
for (;;) { // 自旋等待，直到获取到锁或被取消
// 获取当前节点的前驱节点
final Node p = node.predecessor();
// 如果前驱节点是头节点，尝试获取锁
if (p == head && tryAcquire(arg)) {
// 获取成功，将当前节点设置为头节点
setHead(node);
p.next = null; // 断开原头节点的 next 引用，帮助 GC 回收
failed = false; // 锁获取成功
return interrupted; // 返回等待过程中是否被中断的标志
}
// 如果无法获取锁，检查是否需要将当前线程挂起
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt()) // 挂起线程并检查中断状态
interrupted = true; // 如果线程被中断，标记为 true
}
} finally {
// 如果获取锁失败，清理节点（如从队列中移除）
if (failed)
cancelAcquire(node);
}
}
那么进入死循环时,由于条件不符合,他会执行shouldParkAfterFailedAcquire方法 判断当前线程是否需要被挂起
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus;
if (ws == Node.SIGNAL)
return true; // 前驱节点已设置为 SIGNAL 状态，可以安全挂起当前线程
if (ws > 0) {
// 前驱节点已被取消，将前驱节点从队列中跳过
do {
pred = pred.prev;
node.prev = pred;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
// 将前驱节点设置为 SIGNAL，表示需要通知后继节点
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false; // 当前线程暂时不能挂起，需继续自旋
}
第一次进入的时候,由于前驱节点不是SIGNAL他会将前驱节点设置成SIGNAL 然后返回false,第二次进入的的时候,才会返回true
那么第一次我们返回的是false,还需要走一遍acquireQueued中是循环,并再次尝试使用cas获取锁,如果还没有获取到所,会被挂起
来数一数,Thread-1线程竞争锁到被挂起,最多会尝试几次获取锁
1.在``acquire方法中执行tryAcquire`方法
2.在acquire方法中执行到acquireQueued方法进入第一次循环的时候
3.在acquire方法中执行到acquireQueued方法进入第二次循环的时候,shouldParkAfterFailedAcquire方法返回true的时候才会被挂起
那么假设Tread-0线程还没有解锁,后续线程继续加锁,会变成如下图所示
三.解锁流程
解锁对应的方法是unlock方法
public void unlock() {
sync.release(1);
}
release方法如下
public final boolean release(int arg) {
// 尝试释放锁，具体释放逻辑由子类实现
if (tryRelease(arg)) {
Node h = head; // 获取等待队列的头节点
// 如果头节点存在且状态不为初始状态（可能有线程在等待）
if (h != null && h.waitStatus != 0)
unparkSuccessor(h); // 唤醒头节点的后继节点
return true; // 释放成功
}
return false; // 释放失败
}
`
首先会执行tryrelease方法尝试释放锁
protected final boolean tryRelease(int releases) {
// 获取当前锁的状态值（当前重入计数）并减去释放的次数
int c = getState() - releases;
// 检查当前线程是否是独占锁的持有者
if (Thread.currentThread() != getExclusiveOwnerThread())
// 如果当前线程不是持有锁的线程，抛出异常
throw new IllegalMonitorStateException();
boolean free = false;
// 如果释放后的锁的计数为0，表示锁完全释放
if (c == 0) {
free = true; // 锁已完全释放
setExclusiveOwnerThread(null); // 清除持有锁的线程
}
// 更新锁的状态（新的计数值）
setState(c);
// 返回锁是否完全释放
return free;
}
那么我们假设释放锁成功,依照这幅图,他会执行unparkSuccessor 方法用于唤醒后继结点
private void unparkSuccessor(Node node) {
/*
* 如果当前节点的等待状态是负值（即，可能需要信号），尝试将等待状态清零，
* 为信号准备。即使失败或等待线程修改了状态，也没有问题。
*/
int ws = node.waitStatus;
if (ws < 0)
// 尝试将当前节点的等待状态设置为0
compareAndSetWaitStatus(node, ws, 0);
/*
* 获取下一个节点（通常是下一个节点），如果该节点被取消或状态无效，
* 就需要反向遍历等待队列，从尾节点开始查找一个非取消的有效节点作为后继。
*/
Node s = node.next;
if (s == null || s.waitStatus > 0) {
// 如果没有下一个节点或下一个节点已经被取消，则反向遍历队列
s = null;
for (Node t = tail; t != null && t != node; t = t.prev)
// 查找一个非取消状态的节点
if (t.waitStatus <= 0)
s = t;
}
// 如果找到了有效的后继节点，就唤醒它
if (s != null)
LockSupport.unpark(s.thread);
}
那么他就需要唤醒Thread-1了,Thread-唤醒后会继续执行acquireQueued方法,直到获取到锁,由于是非公平锁,有可能被其他插队的线程获取到锁
如果不巧又被 Thread-4 占了先 Thread-4 被设置为 exclusiveOwnerThread，state = 1 Thread-1 再次进入 acquireQueued 流程，获取锁失败，重新进入 park 阻塞
如果加锁成功（没有竞争），会设置 exclusiveOwnerThread 为 Thread-1，state = 1 head 指向刚刚 Thread-1 所在的 Node，该 Node 清空 Thread 原本的 head 因为从链表断开，而可被垃圾回收
扫一扫
170万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
