一、AbstractQueuedSynchronizer
属性
| 属性 | 类型 | 作用 |
|---|---|---|
| state | int | 表示是否被线程持有，0表示没有，n表示线程重入次数 |
| head | Node | 线程阻塞队列的头节点，head表示正在持有锁的线程 |
| tail | Node | 线程阻塞队列的尾节点，未竞争到锁的Node将添加至队列尾部 |
| unsafe | Unsafe | 含有CAS原子操作的类，调用本地方法实现 |
| exclusiveOwnerThread | Thread | 继承AbstractOwnableSynchronizer类的字段，表示当前持有锁的线程 |
Node 属性
| 属性 | 类型 | 作用 |
|---|---|---|
| thread | Thread | 线程对象 |
| prev | Node | 指向队列中前一个节点 |
| next | Node | 指向队列中后一个节点 |
| waitStatus | int | 等待状态，1表示线程取消等待，-1表示后一个节点该被唤醒，-2，-3暂时不用 |
锁实现的思路：
1 CAS操作更新state，比如将0更新为1，成功表示竞争到了锁，操作失败则竞争失败，需要加入阻塞队列
2 将线程对象封装为Node，加入队列尾部，可能同时有多个线程操作，所以这一步也是CAS操作
3 解锁操作将state更新为0，唤醒队列中下一个线程Node，解锁的线程Node从队列中移除
二、ReentrantLock
ReentrantLock 中有个 Sync 属性，Sync 抽象类继承自 AQS，在 ReentrantLock 内部有非公平（NonfairSync）和公平（FairSync）两种实现，先学习 FairSync。
结合场景理解代码：
线程 t1 首次申请
假设只有线程t1获取锁，执行lock方法：
FairSync#lock
final void lock() {
acquire(1);
}
AbstractQueuedSynchronizer#acquire
public final void acquire(int arg) {
// 尝试获取锁
// 获取失败表示竞争且失败,加入队列中（具体逻辑后面分析）
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
FairSync#tryAcquire
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
// state=0表示可竞争状态
if (c == 0) {
// 如果队列中没有等待线程（公平锁，如果队列有等待的线程，当前线程就没有资格获取锁了）
// 再CAS操作更新state，失败说明同一时间其他线程获取到了锁
// 成功设置独占标记为当前线程
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;
}
// 返回fasle表示锁已经被持有或者竞争失败
return false;
}
如果只有一个线程t1获取锁，则在tryAcquire方法CAS这一步成功获取到锁。
线程 t2 获取已被占有的锁
如果在 t1持有锁 的状态下，t2线程获取锁，执行tryAcquire一定是失败的，这时会执行acquireQueued(addWaiter(Node.EXCLUSIVE), arg)这一句。
AbstractQueuedSynchronizer#addWaiter
private Node addWaiter(Node mode) {
// 将当前线程封装在Node中，构造方法第二参数表示是独占还是共享
Node node = new Node(Thread.currentThread(), mode);
// Try the fast path of enq; backup to full enq on failure
Node pred = tail;
// 如果队尾不为空,CAS更新tail，成功则将调整队列指向至正确，返回当前node
if (pred != null) {
node.prev = pred;
if (compareAndSetTail(pred, node)) {
pred.next = node;
return node;
}
}
// 如果tail指向是空或者CAS更新失败执行enq
enq(node);
return node;
}
AbstractQueuedSynchronizer#enq
private Node enq(final Node node) {
// 循环
for (;;) {
Node t = tail;
// 如果tail为null说明队列为空，初始化队列，这里也会存在竞争所以依然CAS操作
if (t == null) { // Must initialize
if (compareAndSetHead(new Node()))
tail = head;
} else {
// CAS更新队尾Node直到成功,返回队尾当前线程node
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}
这时队列为空，需要初始化队列，然后t2线程node加入队列：
AbstractQueuedSynchronizer#acquireQueued
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
// 获取前一个node
final Node p = node.predecessor();
// 前一个node是头，尝试获取锁，如果成功当前node成为头，解放原head
// 尝试获取失败说明还有线程在持有
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return interrupted;
}
// 不是head或者获取锁失败，设置前个node中waitState标记为-1即等待状态
if (shouldParkAfterFailedAcquire(p, node) &&
// 已经是-1时，停止当前线程
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
// 执行到这里说明出现异常，取消获取，后面再分析
cancelAcquire(node);
}
}
AbstractQueuedSynchronizer#shouldParkAfterFailedAcquire
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus;
// 如果-1表示下个节点需要唤醒
if (ws == Node.SIGNAL)
return true;
// 如果1表示线程取消锁竞争，将其这些移除，直到找到一个不是取消状态的指向自己
if (ws > 0) {
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
// 0 -2 -3 则将设置为-1
} else {
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
AbstractQueuedSynchronizer#parkAndCheckInterrupt
private final boolean parkAndCheckInterrupt() {
// 停止当前线程，底层用了unsafe.park
LockSupport.park(this);
// 返回线程中断状态，先不管
return Thread.interrupted();
}
在 线程t1 还在持有锁的情况下，上面代码的目的是将当前线程node的前驱node状态（waitState）设置为-1，表示下一个node的线程需要被唤醒。同时将当前线程停止：
假设在 线程t1 在持有锁状态下，又来一个线程：
线程 t1 解锁
解锁调用unlock方法，同一时间只会有一个线程解锁
AbstractQueuedSynchronizer#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;
}
Sync#tryRelease
protected final boolean tryRelease(int releases) {
int c = getState() - releases;
// 如果解锁的线程不是占有锁的线程，抛出非法异常
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
// state为0表示没有线程占有锁，设置exclusiveOwnerThread为null表示没有线程占有
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
// 更新state
setState(c);
return free;
}
AbstractQueuedSynchronizer#unparkSuccessor
private void unparkSuccessor(Node node) {
// 这里node是head，如果waitState<0，更新状态为0
int ws = node.waitStatus;
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);
// 可能队列中有取消的节点，从后往前找到可以需要唤醒的node，忽略已取消的node，为什么从后向前？
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;
}
// 如果head的后一个节点不是null，说明队列有等待的线程，将其唤醒
if (s != null)
LockSupport.unpark(s.thread);
}
队列中的线程在 AbstractQueuedSynchronizer#acquireQueued 方法的 parkAndCheckInterrupt 方法中阻塞，就是那个for循环，被唤醒后会继续循环。被唤醒的线程获取到锁并成为head。
for (;;) {
// 前驱node为head并且获取到锁，当前线程竞升为head
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return interrupted;
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
AbstractQueuedSynchronizer#setHead
private void setHead(Node node) {
head = node;
node.thread = null;
node.prev = null;
}
线程t1 解锁，唤醒 线程t2 后：
为什么从后向前遍历找需要唤醒的线程？
1 首先满足 (s == null || s.waitStatus > 0) 才会进入遍历，如果head的next节点不是null且waitState<=0就会直接唤醒next的线程。
2 head.next（即s）什么时候会是null？
node.prev = t;
if (compareAndSetTail(t, node)) { // 1
t.next = node; // 2
return t;
}
在enq方法和addWaiter方法中都有上面代码片段，t表示tail的node。先将当前node指向tail，CAS更新队尾node，成功后将tail的next指向当前node。整个操作不是原子的，有可能出现下面两种情况：
如果类似图中第二种情况，那么head.next为null，但是其实队列中有等待线程，所以需要从队尾在遍历到当前node看看有没有需要唤醒的node。
如何公平
在 FairSync#tryAcquire 方法中尝试加锁时，需要先判断队列中是否有线程排队，如果没有才进行CAS更新state。先到队列的线程线程先获得锁。
if (c == 0) {
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
AbstractQueuedSynchronizer#hasQueuedPredecessors
public final boolean hasQueuedPredecessors() {
// The correctness of this depends on head being initialized
// before tail and on head.next being accurate if the current
// thread is first in queue.
Node t = tail; // Read fields in reverse initialization order
Node h = head;
Node s;
return h != t &&
((s = h.next) == null || s.thread != Thread.currentThread());
}
head == tail 情况有以下两种情况，一是队列没有初始化过都是null，二是队列中保留一个thread为null，waitState为0的node，这两种情况都表示队列中已经没有排队线程。
还有一种情况就是head.next的线程和当前线程是同一个，返回也是false，因为满足可重入的条件。
取消获取锁
在acquireQueued方法try-finally的finally代码块中有取消获取锁的操作，正常情况不会执行，当有异常时执行。**可能发生的异常就是超过了最大锁计数 和 队列中当前线程的前驱为null。**个人认为两种都不可能出现（可能太笨了看不懂）。那就看看怎么取消的吧。
AbstractQueuedSynchronizer#cancelAcquire
private void cancelAcquire(Node node) {
// Ignore if node doesn't exist
if (node == null)
return;
node.thread = null;
// 找到前面不是取消状态的node
Node pred = node.prev;
while (pred.waitStatus > 0)
node.prev = pred = pred.prev;
Node predNext = pred.next;
// 设置当前node的状态为1
node.waitStatus = Node.CANCELLED;
// 如果当前node是tail则移除，同时移除了其他取消状态的node
if (node == tail && compareAndSetTail(node, pred)) {
compareAndSetNext(pred, predNext, null);
} else {
// 这段有点复杂，没太看懂，我理解的是从队列中移除，如果前驱是head则唤醒后续node的线程
// If successor needs signal, try to set pred's next-link
// so it will get one. Otherwise wake it up to propagate.
int ws;
if (pred != head &&
((ws = pred.waitStatus) == Node.SIGNAL ||
(ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) &&
pred.thread != null) {
Node next = node.next;
if (next != null && next.waitStatus <= 0)
compareAndSetNext(pred, predNext, next);
} else {
unparkSuccessor(node);
}
node.next = node; // help GC
}
}
如何非公平
ReentrantLock默认是非公平实现的，Sync的实现类为NonfairSync，相较与FairSync其实也只有lock时一点不同：
1 lock方法首先CAS操作尝试获取锁，如果失败在调用acquire方法
2 tryAcquire中调用nonfairTryAcquire方法，获取锁时不考虑队列中是否有等待线程，直接参与竞争
NonfairSync#lock
final void lock() {
// 直接尝试获取锁
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
Sync#nonfairTryAcquire
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
// 不需要考虑队列中是否有等待的线程
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;
}
如果tryAcquire失败也需要进入队列，与公平锁一样。可能出现队列中线程一直获取不到锁，造成锁饥饿现象。
（20190905）
扫一扫
2116
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
