阻塞队列的阻塞原理

在正文之前先说一下lockInterruptibly方法

与lock.lock不同，lockInterruptibly是可以被中断的，而lock.lock无法被中断，看个栗子

在thread刚开始的时候就中断thread，会不会中断呢？

没有被中断，仍然等待获取锁

那么换成lockInterruptibly呢？

就会在加锁状态下被中断，为什么？

为什么不用再多说了吧？

那么开始正文，阻塞队列如何阻塞线程的呢？

首先在put方法里放入可以中断的锁然后将线程挂起释放锁，然后挂起插入的锁在enqueue里解开取出锁

在取出take操作里，将取出线程阻塞

再将插入线程释放出

await阻塞的原理是什么？

// 等待

public final void await() throws InterruptedException {

// 判断线程是否被中断，

// 因为该方法会清除标志位，

// 如果该线程未执行中断，则会返回false

// 如果中断过第一次执行该方法则会返回true，再次执行也是会返回false

if (Thread.interrupted())

throw new InterruptedException();

// 将当前页面添加到等待队列中，如果队列不存在则创建一个，

// 并返回该节点（包含当前线程和waitStatus=CONDITION)

Node node = addConditionWaiter();

// 释放当前节点的重入锁，并返回重入次数

int savedState = fullyRelease(node);

int interruptMode = 0;

// 判断该节点是否存在同步队列中，

// 如果不存在同步队列中，则 park 当前线程

while (!isOnSyncQueue(node)) {

LockSupport.park(this);

// 当代码执行了 await()方法时，当前线程将阻塞在这里

// 到此为止主要做了几步：

// 1. 线程拿到锁 ，从同步队列中取出了

// 2. 线程释放锁，并将该线程封装到等待队列中

// 3. 线程阻塞在这里，等待从等待队列中再次取出该线程进行后续操作

// todo 下面的等执行完 signal 后在分析

if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)

break;

}

if (acquireQueued(node, savedState) && interruptMode != THROW_IE)

interruptMode = REINTERRUPT;

if (node.nextWaiter != null) // clean up if cancelled

unlinkCancelledWaiters();

if (interruptMode != 0)

reportInterruptAfterWait(interruptMode);

}

// 添加当前线程到等待队列中

// 将当前线程添加到等待队列最后一个节点中

private Node addConditionWaiter() {

Node t = lastWaiter;

// If lastWaiter is cancelled, clean out.

// 如果 最后一个等待节点不为空且不为CONDITION 说明为取消状态，则删除该节点

if (t != null && t.waitStatus != Node.CONDITION) {

// 删除处于取消状态的节点，

// 并再次获得最后一个等待节点（该节点不再是取消状态了,因为已经删除了所有出于取消状态的节点）

unlinkCancelledWaiters();

t = lastWaiter;

}

// 等待队列的节点：当前线程，CONDITION（-2）

Node node = new Node(Thread.currentThread(), Node.CONDITION);

if (t == null)

firstWaiter = node;

else

t.nextWaiter = node;

lastWaiter = node;

return node;

}

// 删除处于取消状态的节点

// 从等待队列中的第一个节点开始进行遍历判断是否是取消状态，如果是取消状态则删除该节点，

// 将该节点的下一个节点的引用取消，并将该节点的下一个节点作为该等待队列的第一个节点

private void unlinkCancelledWaiters() {

Node t = firstWaiter;

// 用来做中间值 ，来删除已经取消的节点

Node trail = null;

while (t != null) {

Node next = t.nextWaiter;

// 如果 firstWaiter 节点的 waitStatus ！= CONDITION ，说明是取消状态的节点

if (t.waitStatus != Node.CONDITION) {

// 设置 firstWaiter 下一个节点的引用为空，

t.nextWaiter = null;

if (trail == null)

// 在等待队列中，如果第一个节点为取消状态则将第原本处于第二的节点设置为第一个节点

firstWaiter = next;

else

trail.nextWaiter = next;

if (next == null)

// 如果没有下一个节点了，则将该节点设置为最后一个节点

lastWaiter = trail;

}

else

trail = t;

t = next;

}

}

// 释放当前等待节点的所有锁，返回当前锁重入的次数

final int fullyRelease(Node node) {

boolean failed = true;

try {

// 锁标记，大于0 表示有锁，大于1表示冲入的次数

int savedState = getState();

// 释放重入锁

if (release(savedState)) {

failed = false;

return savedState;

} else {

throw new IllegalMonitorStateException();

}

} finally {

if (failed)

// 失败则设置为取消状态

node.waitStatus = Node.CANCELLED;

}

}

// 判断当前节点是否在同步队列中

final boolean isOnSyncQueue(Node node) {

// 如果该节点的状态是 -2 ，则不在同步队列中

// 如果该节点的prev为空，有两种可能，

// 一种是 在等待队列中，因为该队列中的节点没有prev属性，所以为空

// 另一个是head 节点， 即获得锁的节点，也不存在同步队列中

if (node.waitStatus == Node.CONDITION || node.prev == null)

return false;

// 因为同步队列中存在next ，而等待队列中存在 nextWaiter ,

// 所以 node.next 不为空说明就是同步队列

if (node.next != null) // If has successor, it must be on queue

return true;

/*

* node.prev can be non-null, but not yet on queue because

* the CAS to place it on queue can fail. So we have to

* traverse from tail to make sure it actually made it. It

* will always be near the tail in calls to this method, and

* unless the CAS failed (which is unlikely), it will be

* there, so we hardly ever traverse much.

*/

// 从tail 节点倒着查看该节点是否存在同步队列中

// node.prev可以是非null，但尚未在队列中，

// 因为将其置于队列中的CAS可能会失败。

// 所以我们必须从尾部穿过以确保它实际上成功。

return findNodeFromTail(node);

}

// 从tail倒着遍历，如果存在 节点等于 node ，

// 则说明在同步队列中存在该节点

// 为什么这样做呢？

// 因为在 enq 中是先设置prev 的关系，在通过CAS 替换tail ，

// 如果此时prev 不为空，但是 next 却没有，便可以通过这种方式找到

private boolean findNodeFromTail(Node node) {

Node t = tail;

for (;;) {

if (t == node)

return true;

if (t == null)

return false;

t = t.prev;

}

}