ArrayBlockingQueue源码解读

说明：

i).put/take操作，必须先获取lock，若获取失败，则添加到同步队列中，线程被挂起。

i).当queue满/空时，put/take操作线程会被添加到notFull/notEmpty条件队列中，线程被挂起。

i).当queue不处于满/空状态时，put/take操作成功后，会调用notFull/notEmpty的signal方法，从相应的条件队列中移除一个节点，并将其移动到同步队列中。

i).只有在同步队列中的节点，被唤醒后才可继续争抢lock，执行put/take操作。

i).条件队列中的节点，被唤醒后，会检查当前线程的中断状态，若有中断，则会将节点移动到同步队列中。若无中断，则继续挂起。

 

最后，聊聊interruptMode。先看源码

/** Mode meaning to reinterrupt on exit from wait */
private static final int REINTERRUPT =  1;
/** Mode meaning to throw InterruptedException on exit from wait */
private static final int THROW_IE    = -1;

interruptMode的值有三种可能，-1,1,0。默认为0，，现在分析下源码。

第一步：

java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#await()

从这代码块分析出，如果没有发生中断，继续走while循环,直到该节点移动到同步队列中才会退出while循环；如果发生了中断，则退出循环，走后续逻辑。分析下LockSupport.park方法java.util.concurrent.locks.LockSupport#park(java.lang.Object)

方法注释说明，当调用unpark，或interrupt时，线程会被唤醒。

现在分析下checkInterruptWhileWaiting方法。

第二步：

java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#checkInterruptWhileWaiting

方法注释大致意思为：

检查中断,如果在收到信号之前被中断，返回THROW_IE，如果收到信号后中断，返回REINTERRUPT，如果没有中断，则为0。

该方法判断当前线程是否被中断，若发生中断，则调用transferAfterCancelledWait，并清除中断标记。接着往下分析transferAfterCancelledWait方法。

第三步：

java.util.concurrent.locks.AbstractQueuedSynchronizer#transferAfterCancelledWait

高并发场景下，存在多个线程交替执行，某一时刻，可能存在如下3个线程交替执行。

如上图，Thread1调用put/take方法时，被阻塞(park)在条件队列中，当有其他线程(Thread2)调用signer()方法时，Thread3调用interrupt方法，中断Thread1。

因此，完成有可能存在Thread3已经将Thread1中断，但Thread2还未来变更节点状态，Thread1就调用了transferAfterCancelledWait方法。

1.Thread2调用signer方法，还未更改node状态时，Thread3线程中断了Thread1，Thread1被interrupt后，会从park处继续执行，就调用了transferAfterCancelledWait，此时node仍为CONDITION状态，step1代码块的cas操作必定能执行成功，将节点移动到同步队列中并返回true。因此，interruptMode=THROW_IE。

2.Thread3已将Thread1线程已中断，且Thread2已变更了节点状态后，Thread1才调用transferAfterCancelledWait，此时node节点不再处于CONDITION状态，step1代码块的cas操作就必定会执行失败，走step2逻辑，返回false。因此，interruptMode=REINTERRUPT。

现在再回到await()方法。

第四步：

java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#await()

根据第三步分析已经得出，发生中断时，会将条件队列的节点移到同步队列中，while循环条件不再成立。因此会退出循环，继续往下运行。第二步分析得出，Thread.interrupted()会将清除此前的中断标识。

acquireQueued方法分析：

1.调用acquireQueued方法获取锁时，线程可能因为竞争锁失败而再次被挂起。

2.线程在被挂起后的这段时间里，很可能再次发生中断。

3.当线程再次被唤醒，并获取锁成功时，返回值就是这个过程中是否被中断。如果发生中断，则返回true，未发生中断，则返回false。

得到的结果就是：

1.如果第三步 interruptMode=THROW_IE

     i) acquireQueued方法未发生中断，最终interruptMode=THROW_IE;

     i)acquireQueued方法发生中断，最终interruptMode=THROW_IE;

2.如果第三步 interruptMode=REINTERRUPT

    i)acquireQueued方法未发生中断，最终interruptMode=REINTERRUPT;

    i)acquireQueued方法发生了中断，最终interruptMode=REINTERRUPT;

最后，再分析下reportInterruptAfterWait方法

java.util.concurrent.locks.AbstractQueuedSynchronizer.ConditionObject#reportInterruptAfterWait

interruptMode=THROW_IE，则抛出异常；

interruptMode=REINTERRUPT，则将当前线程中断；

java.util.concurrent.locks.AbstractQueuedSynchronizer#selfInterrupt

结论：

节点被挂起在条件队列中时，调用方法(如：signer())变更该节点状态时，

1.如果线程已中断，但节点状态还未更改成功就调用了transferAfterCancelledWait，那么最终会抛出异常；

2.如果线程已中断，且节点状态也已更新完毕，那么最终会将当前线程再次中断。

3.如果是通过业务代码中断该线程（只中断线程，不修改节点waitStatus），直接抛异常。

 

此时，再来理解作者方法的注释，是不是有不一样的心得呢？

/**
 * 如果在收到信号之前被中断，返回THROW_IE，
 * 如果收到信号后中断，返回REINTERRUPT，
 * 如果没有中断，则为0


 * Checks for interrupt, returning THROW_IE if interrupted
 * before signalled, REINTERRUPT if after signalled, or
 * 0 if not interrupted.
 */
private int checkInterruptWhileWaiting(Node node) {
	return Thread.interrupted() ?
		(transferAfterCancelledWait(node) ? THROW_IE : REINTERRUPT) :
		0;
}

 

我个人猜测，作者的本意大致为：

1.线程挂起在条件队列中，若发生一般的中断(如：我们自己在业务代码中对线程中断)，应该抛异常。

2.调用signer()后，再发生中断，恢复线程的中断状态即可。因为在acquireQueued方法获取所资源时，会再次判断节点的状态，并移除异常状态节点。

3.极端情况下，调用signer()方法，还未将节点状态变更却发生了中断，那么此时还是要抛出异常。

 

附录：

一、unpark方法测试

public static void main(String[] args) throws InterruptedException {
	Thread t = new Thread(new Runnable() {
		@Override
		public void run() {
			System.out.println("-------park子线程，等待被interrupt or unpark------");
			LockSupport.park(this);
			System.out.println("-------子线程被interrupt or unpark ,继续运行------");
		}
	});
	t.start();
	Thread.sleep(3*1000);
	System.out.println("--------main线程继续运行----");
    //可以通过 unpark或interrup方法唤醒处于park状态的线程
	t.interrupt();
    //LockSupport.unpark(t);
}

case1:不做任何处理，此时Thread t一直处于park状态，程序不会结束。

case2: 调用interrupt方法，Thread t 从park处继续执行，整个程序正常结束。

case3: 调用unpark方法，程序正常结束

 

二、测试在业务代码中，中断线程

程序抛出InterruptException

public static void main(String[] args) throws InterruptedException {
	final BlockingQueue<String> blockingQueue = new ArrayBlockingQueue<String>(1);
	List<Thread> list = new ArrayList<Thread>();
	for(int i=0,len=10;i<len;i++){
		Thread t1 = new Thread(new Runnable() {
			public void run() {
				try {
					blockingQueue.put("test");
				} catch (InterruptedException e) {
					e.printStackTrace();
				}
			}
		});
        t1.setName("MyThread-"+i);
		t1.start();
		list.add(t1);
	}
	Thread.sleep(3*1000);
    //模拟业务中断
	list.get(9).interrupt();
}

上述程序，ArrayBlockingQueue大小为1，开启10个线程调用put方法，只有一个能成功，其余9个线程都会被park,阻塞在条件队列中，此时调用某一个线程的interrupt方法，程序最终抛出异常。根据上述分析，推断此时程序的执行逻辑大致为：

step1:

调用put方法，队列已满，走notFull.await()逻辑

step2:

当前节点在条件队列中，因此while条件不满足，线程被park。

step3:

调用interrupt方法，程序继续从park处执行。

list.get(9).interrupt();

step4:

判断中断类型

step5:

业务代码中断，不可能修改节点状态，因此 transferAfterCancelledWait能执行成功，将node转移到同步队列中，并返回true,所以 interruptMode = THROW_IE。

step6:

此时已发生中断，直接退出while循环，acquireQueued获取锁，此时由于没有其他线程竞争，因此获取锁一定能成功，并继续往下走。

step7:

reportInterruptAfterWait

根据异常类型，最终抛出InterruptedException。

程序调试结果能佐证这推测