看一下官方1.8的官方文档
官方文档告诉我们它们有这些特点:
- BlockingQueue实现被设计为主要用于生产者 - 消费者队列
- BlockingQueue实现是线程安全的。 所有排队方法使用内部锁或其他形式的并发控制在原子上实现其效果。
- BlockingQueue方法有四种形式，具有不同的操作方式，不能立即满足，但可能在将来的某个时间点满足：
- 一个抛出异常
- 返回一个特殊值（ null或false ，具体取决于操作）
- 第三个程序将无限期地阻止当前线程，直到操作成功为止
- 在放弃之前只有给定的最大时限。
看一下官方文档的解释->一个有限的blocking queue由数组支持。 这个队列排列元素FIFO（先进先出）。 队列的头部是队列中最长的元素。 队列的尾部是队列中最短时间的元素。 新元素插入队列的尾部，队列检索操作获取队列头部的元素。这是一个经典的“有界缓冲区”，其中固定大小的数组保存由生产者插入的元素并由消费者提取。 创建后，容量无法更改。 尝试put成满的队列的元件将导致在操作阻挡; 尝试take从空队列的元件将类似地阻塞。此类支持可选的公平策略，用于订购等待的生产者和消费者线程。 默认情况下，此订单不能保证。 然而，以公平设置为true的队列以FIFO顺序授予线程访问权限。 公平性通常会降低吞吐量，但会降低变异性并避免饥饿。
int count; // 队列元素数量
final ReentrantLock lock; // 内部线程安全性用了ReentrantLock
private final Condition notEmpty; // takes方法的等待条件
private final Condition notFull; // puts方法的等待条件public ArrayBlockingQueue(int capacity, boolean fair) {
if (capacity <= 0)
throw new IllegalArgumentException(); // 这里就不说了
this.items = new Object[capacity]; // 初始容量
lock = new ReentrantLock(fair); // fair参数决定是否公平锁
notEmpty = lock.newCondition(); // 上面已提到
notFull = lock.newCondition(); // 上面已提到
}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"); // 在这
}remove就不分析了
public boolean offer(E e) {
checkNotNull(e);
final ReentrantLock lock = this.lock; // 上面的add其实内部也调用了offer，当时我还觉得奇怪，add没上锁？。 原来offer上了锁的
lock.lock();
try {
if (count == items.length)
return false; // 满了，就false
else {
enqueue(e); // 否则，添加即可
return true; // 返回true，并不会抛出异常
}
} finally {
lock.unlock();
}
}poll不分析了
public void put(E e) throws InterruptedException {
checkNotNull(e); // 检查是否为空，为空就抛出空异常
final ReentrantLock lock = this.lock; // 上锁哦
lock.lockInterruptibly(); // 锁中断
try {
while (count == items.length) // 满了，挂起阻塞
notFull.await();
enqueue(e); // 否则添加
} finally {
lock.unlock();
}
}public E take() throws InterruptedException {
final ReentrantLock lock = this.lock; // 上锁
lock.lockInterruptibly(); // 锁中断
try {
while (count == 0)
notEmpty.await(); // 没有元素，挂起
return dequeue();
} finally {
lock.unlock();
}
}其实就是用了
long nanos = unit.toNanos(timeout);
四个方法和ArrayBlockingQueue的差不多，就不多分析了。它的特点之一在于，如果不指定容量，那么默认是等于Integer.MAX_VALUE。可以看一下源码
/** The capacity bound, or Integer.MAX_VALUE if none */
private final int capacity; // 一看注释，就晓得了
// 还有一些常见的和上面的差不多public LinkedBlockingQueue() {
this(Integer.MAX_VALUE); // 在这里， 嘿嘿嘿。
}基于链接节点的无界TransferQueue 。 这个队列相对于任何给定的生产者订购元素FIFO（先进先出）。 队列的头部是那些已经排队的元素是一些生产者的最长时间。 队列的尾部是那些已经在队列上的元素是一些生产者的最短时间。
四个方法就暂时不提了，大部分操作用了cas并且要关注transfer方法
先介绍几个标志参数：
private static final int NOW = 0; // for untimed poll, tryTransfer
private static final int ASYNC = 1; // for offer, put, add
private static final int SYNC = 2; // for transfer, take
private static final int TIMED = 3; // for timed poll, tryTransfer// 如果可能，立即将元素转移到等待的消费者。
public boolean tryTransfer(E e) {
return xfer(e, true, NOW, 0) == null; // xfer的now参数
}
// 还有一个重载参数的，带时间的。// 将元素传输到消费者，必要时等待。
public void transfer(E e) throws InterruptedException {
if (xfer(e, true, SYNC, 0) != null) { // SYNC
Thread.interrupted(); // failure possible only due to interrupt
throw new InterruptedException();
}
}一看名字就是优先级阻塞队列，它的优先级是由堆实现的，所以该类中有很多堆的方法。源码暂时就不看了，很多都是差不多的。
官方文档：每个插入操作必须等待另一个线程相应的删除操作，反之亦然。 同步队列没有任何内部容量，甚至没有一个容量。 个人感觉是生产者生产一个元素，消费者必须消费，生产者才能继续生产。内部也维护了一个TransferQueue，其中部分操作是利用cas。源码就不贴了。有兴趣的可以进去看看哦。