JUC源码解析-阻塞队列-LinkedBlockingQueue与ArrayBlockingQueue
什么是阻塞队列？
阻塞队列（BlockingQueue）是一个支持两个附加操作的队列。这两个附加的操作是：
- 在队列为空时，获取元素的线程会阻塞等待，直到队列变为非空或超时。
- 当队列满时，存储元素的线程会等待队列可用。
阻塞队列常用于生产者和消费者的场景。
阻塞队列提供了四种处理方法:
- 抛出异常：是指当阻塞队列满时候，再往队列里插入元素，会抛出IllegalStateException(“Queue full”)异常。当队列为空时，从队列里获取元素时会抛出NoSuchElementException异常 。
- 返回特殊值：插入方法会返回是否成功，成功则返回true。移除方法，则是从队列里拿出一个元素，如果没有则返回null
- 一直阻塞：当阻塞队列满时，如果生产者线程往队列里put元素，队列会一直阻塞生产者线程，直到拿到数据，或者响应中断退出。当队列空时，消费者线程试图从队列里take元素，队列也会阻塞消费者线程，直到队列可用。
- 超时退出：当阻塞队列满时，队列会阻塞生产者线程一段时间，如果超过一定的时间，生产者线程就会退出。
ArrayBlockingQueue
ArrayBlockingQueue的内部是通过一个可重入锁ReentrantLock和两个Condition条件对象来实现阻塞。
关于 ReentrantLock
关于 Condition
public class ArrayBlockingQueue<E> extends AbstractQueue<E>
implements BlockingQueue<E>, java.io.Serializable {
// 存储数据的数组
final Object[] items;
// 获取数据的索引，用于take，poll，remove等方法
int takeIndex;
// 添加数据的索引，用于 put, offer, add等方法
int putIndex;
// 元素个数
int count;
// 锁
final ReentrantLock lock;
// Condition 内有个队连，有别于AQS的同步队列，我们称它为等待队列
// await 会先构建当前线程的节点放入等待队列，之后阻塞线程
// signal 一般不会唤醒线程，而是将节点放回AQS的同步队列，等待被唤醒
// notEmpty队列里放的是执行获取操作的线程，它们之前由于数组为空无法执行获取操作而阻塞
// 执行取操作的线程由于数组为空而被放入notEmpty的等待队列中等待
// 当执行添加操作的线程执行成功后调用notEmpty.signal将notEmpty队列中的
// 头节点放回AQS的同步队列，其代表的线程在队列中等待被唤醒
private final Condition notEmpty;
// notFull 的队列中放的是执行插入操作的线程，它们之前由于数组满无法执行添加操作而阻塞
private final Condition notFull;
// 迭代器
transient Itrs itrs = null;
在上面提到了AQS的同步队列与Condition的等待队列，它们在我的关于 ReentrantLock 和 Condition两篇源码分析文章中有详细介绍。
这里贴张图比那与理解：
第一条队列是AQS的同步队列，下面是Condition的等待队列。
关于 notEmpty 与 notFull 不太好记忆，可以将 notEmpty 与 get 联系在一起；notFull 与 put 联系在一起。
add，offer添加操作
public boolean add(E e) {
return super.add(e);
}
// 跳到AbstractQueue：
public boolean add(E e) {
if (offer(e))
return true;
else
throw new IllegalStateException("Queue full");
}
// offer方法在ArrayBlockingQueue的实现
public boolean offer(E e) {
checkNotNull(e);
final ReentrantLock lock = this.lock;
lock.lock();
try {
if (count == items.length)
return false;
else {
enqueue(e);
return true;
}
} finally {
lock.unlock();
}
}
private void enqueue(E x) {
// assert lock.getHoldCount() == 1;
// assert items[putIndex] == null;
final Object[] items = this.items;
items[putIndex] = x;
if (++putIndex == items.length)
putIndex = 0;
count++;
notEmpty.signal();
}
对重点进行下总结：
- 添加操作先获取锁；
- add 方法在数组满时抛异常，offer 则返回 false
- 唤醒一个notEmpty等待队列中的线程，该队列中的线程都是执行获取操作的
put操作
public void put(E e) throws InterruptedException {
checkNotNull(e);
final ReentrantLock lock = this.lock;
// lockInterruptibly相对于lock，就如其名一样，检测到中断就直接抛异常
lock.lockInterruptibly();
try {
while (count == items.length)
// 数组满无法插入，将插入线程放入notFull等待队列
notFull.await();
enqueue(e);
} finally {
lock.unlock();
}
}
可以看出 put 有别于 add，数组满就等待而不是抛异常。
remove，poll删除操作
public E remove() {
E x = poll();
if (x != null)
return x;
else
throw new NoSuchElementException();
}
public E poll() {
final ReentrantLock lock = this.lock;
lock.lock();
try {
return (count == 0) ? null : dequeue();
} finally {
lock.unlock();
}
}
private E dequeue() {
// assert lock.getHoldCount() == 1;
// assert items[takeIndex] != null;
final Object[] items = this.items;
@SuppressWarnings("unchecked")
E x = (E) items[takeIndex];
items[takeIndex] = null;
if (++takeIndex == items.length)
takeIndex = 0;
count--;
// takeIndex位置元素被删除，需根据情况对迭代器链上所有迭代器进行处理
if (itrs != null)
itrs.elementDequeued();
notFull.signal();
return x;
}
- 数组为空时，remove 抛异常，poll 返回 null 。
- 删除成功后将 notFull 中一个插入线程的节点放回同步队列，在队列中轮到它时就被唤醒执行插入操作，所谓轮到它指的是在同步队列中排在它之前的节点都被一一唤醒。
- 元素删除后可能会对一些迭代器造成影响，这里需要处理这种影响。
阻塞队列的迭代器实现原理分析我专门写了两篇分析：
深入Java并发之阻塞队列-迭代器（一）
深入Java并发之阻塞队列-迭代器（二）
take 阻塞获取
public E take() throws InterruptedException {
final ReentrantLock lock = this.lock;
lock.lockInterruptibly(); // 中断抛异常
try {
while (count == 0)
notEmpty.await();
return dequeue();
} finally {
lock.unlock();
}
}
首先要获取锁，数组为空则放入 notEmpty 等待队列。
element，peek
public E element() {
E x = peek();
if (x != null)
return x;
else
throw new NoSuchElementException();
}
public E peek() {
final ReentrantLock lock = this.lock;
lock.lock();
try {
return itemAt(takeIndex); // null when queue is empty
} finally {
lock.unlock();
}
}
数组为空 peek 返回 null；element 则抛异常。
LinkedBlockingQueue
LinkedBlockingQueue内部分别使用了 takeLock 和 putLock 两个锁对并发进行控制，添加和删除操作并不是互斥操作，可以同时进行，这样也就可以大大提高吞吐量。
public class LinkedBlockingQueue<E> extends AbstractQueue<E>
implements BlockingQueue<E>, java.io.Serializable {
节点
static class Node<E> {
E item;
Node<E> next;
Node(E x) { item = x; }
}
相关成员变量
//容量，默认为Integer.MAX_VALUE
private final int capacity;
//统计个数
private final AtomicInteger count = new AtomicInteger();
//头节点
transient Node<E> head;
//尾节点
private transient Node<E> last;
// take，poll等取操作的锁
private final ReentrantLock takeLock = new ReentrantLock();
// 数组为空无法执行取操作的线程被放入 notEmpty 队列中等待
private final Condition notEmpty = takeLock.newCondition();
// put，offer等插入操作的锁
private final ReentrantLock putLock = new ReentrantLock();
// 数组满而无法执行插入操作的线程被放入到 notFull 队列中等待
private final Condition notFull = putLock.newCondition();
构造函数
public LinkedBlockingQueue() {
this(Integer.MAX_VALUE); // 默认链最大长度为Integer.MAX_VALUE
}
public LinkedBlockingQueue(int capacity) {
if (capacity <= 0) throw new IllegalArgumentException();
this.capacity = capacity;
last = head = new Node<E>(null);
}
public LinkedBlockingQueue(Collection<? extends E> c) {
......
插入操作
add，offer
下面你会经常看见打了双引号的 唤醒 两字——“唤醒”：经过一开始的分析，AQS有个同步队列，通过它得到的Condition对象也有一个等待队列，await 就是线程放入等待队列，signal 就是将等待队列中的头节点放回同步队列尾，并非是唤醒线程，它在同步队列中等待直到被唤醒。具体的分析在我的 Condition 文章中，链接在上面。
public boolean add(E e) {
if (offer(e))
return true;
else
throw new IllegalStateException("Queue full");
}
public boolean offer(E e) {
if (e == null) throw new NullPointerException();
final AtomicInteger count = this.count;
if (count.get() == capacity) // 数组满直接返回false
return false;
int c = -1; // 开始时设为-1，若插入成功c的值应>=0，以此来判定offer操作是否成功
Node<E> node = new Node<E>(e);
final ReentrantLock putLock = this.putLock;
putLock.lock();
try {
// 若数组满不做任何处理，c仍未-1，最后会返回false。
if (count.get() < capacity) {
enqueue(node);
c = count.getAndIncrement(); // 这里返回的是增加之前的值
if (c + 1 < capacity) // 插入后数组未满
notFull.signal(); // “唤醒”一个插入线程
}
} finally {
putLock.unlock();
}
// c等于0 说明本次插入之前数组为空，则可鞥有不少获取操作的线程都在阻塞等待，
// 所以可以在这里唤醒一个，其实并不一定会唤醒线程，很可能是将节点从
// notEmpty 等待对队列中放回 takeLock 的同步队列。
// 具体分析见我分析 Condition 的文章
if (c == 0)
signalNotEmpty();
return c >= 0;
}
private void enqueue(Node<E> node) {
// assert putLock.isHeldByCurrentThread();
// assert last.next == null;
last = last.next = node;
}
private void signalNotEmpty() {
final ReentrantLock takeLock = this.takeLock;
takeLock.lock();
try {
notEmpty.signal();
} finally {
takeLock.unlock();
}
}
从上面可以看出这种双锁设计的好处，当前插入线程完成后“唤醒”下一个插入线程，跟取操作互不影响。代码最后在检测到此次插入前数组为空的情况时，会“唤醒”一个取线程，防止 notEmpty 队列中等待的取线程一直阻塞不被唤醒，当然无论是取还是插入，当其执行完后都会在”唤醒“下一个取或插入。
put
操作与上面基本相同，只是当数组满时 阻塞 线程。
......
while (count.get() == capacity) { //数组满就阻塞
notFull.await();
}
......
删除操作
remove，poll
public E remove() {
E x = poll();
if (x != null)
return x;
else
throw new NoSuchElementException();
}
public E poll() {
final AtomicInteger count = this.count;
if (count.get() == 0) // 数组为空 返回null
return null;
E x = null;
int c = -1;
final ReentrantLock takeLock = this.takeLock;
takeLock.lock();
try {
if (count.get() > 0) {
x = dequeue();
//将数量减一，返回值是删除之前的数量
c = count.getAndDecrement();
if (c > 1) // 代表删除之后数组仍不为空
notEmpty.signal(); // “唤醒”下一个取线程
}
} finally {
takeLock.unlock();
}
// 代表删除之前数组为满，则可能阻塞了不少插入线程，“唤醒”一个
if (c == capacity)
signalNotFull();
return x;
}
private E dequeue() {
// assert takeLock.isHeldByCurrentThread();
// assert head.item == null;
Node<E> h = head;
Node<E> first = h.next;
h.next = h; // help GC
head = first;
E x = first.item;
//将新头节点的item置空，已经删除没必要再持有对其的引用，不利于回收
first.item = null;
return x;
}
take 的实现与上面没什么不同，只是再数组为空时阻塞。
获取操作
public E element() {
E x = peek();
if (x != null)
return x;
else
throw new NoSuchElementException();
}
public E peek() {
if (count.get() == 0)
return null;
final ReentrantLock takeLock = this.takeLock;
takeLock.lock();
try {
Node<E> first = head.next;
if (first == null)
return null;
else
return first.item;
} finally {
takeLock.unlock();
}
}
实现很简单。由于并发下 head 不断变换，所以需要获取取锁以保证安全性。