标签：style blog http io ar 使用 sp java for
在上一节中详细分析了LinkedBlockingQueue 的实现原理。实现一个可扩展的队列通常有两种方式：一种方式就像LinkedBlockingQueue一样使用链表，也就是每一个元素带有下一个元素的引用，这样的队列原生就是可扩展的；另外一种就是通过数组实现，一旦队列的大小达到数组的容量的时候就将数组扩充一倍（或者一定的系数倍），从而达到扩容的目的。常见的ArrayList就属于第二种。前面章节介绍过的HashMap确是综合使用了这两种方式。
对于一个Queue而言，同样可以使用数组实现。使用数组的好处在于各个元素之间原生就是通过数组的索引关联起来的，一次元素之间就是有序的，在通过索引操作数组就方便多了。当然也有它不利的一面，扩容起来比较麻烦，同时删除一个元素也比较低效。
ArrayBlockingQueue 就是Queue的一种数组实现。
ArrayBlockingQueue 原理
在没有介绍ArrayBlockingQueue原理之前可以想象下，一个数组如何实现Queue的FIFO特性。首先，数组是固定大小的，这个是毫无疑问的，那么初始化就是所有元素都为null。假设数组一段为头，另一端为尾。那么头和尾之间的元素就是FIFO队列。
有了上述几点分析，设计一个可阻塞的数组队列就比较容易了。
上图描述的ArrayBlockingQueue的数据结构。首先有一个数组E[]，用来存储所有的元素。由于ArrayBlockingQueue最终设置为一个不可扩展大小的Queue，所以这里items就是初始化就固定大小的数组（final类型）；另外有两个索引，头索引takeIndex，尾索引putIndex；一个队列的大小count；要支持阻塞就必须需要一个锁lock和两个条件（非空、非满），这三个元素都是不可变更类型的（final）。
由于只有一把锁，所以任何时刻对队列的操作都只有一个线程，这意味着对索引和大小的操作都是线程安全的，所以可以看到这个takeIndex/putIndex/count就不需要原子操作和volatile语义了。
清单1 描述的是一个可阻塞的添加元素过程。这与前面介绍的消费者、生产者模型相同。如果队列已经满了就挂起等待，否则就插入元素，同时唤醒一个队列已空的线程。对比清单2 可以看到是完全相反的两个过程。这在前面几种实现生产者-消费者模型的时候都介绍过了。
清单1 可阻塞的添加元素
public void put(E e) throws InterruptedException {
if (e == null) throw new NullPointerException();
final E[] items = this.items;
final ReentrantLock lock = this.lock;
lock.lockInterruptibly();
try {
try {
while (count == items.length)
notFull.await();
} catch (InterruptedException ie) {
notFull.signal(); // propagate to non-interrupted thread
throw ie;
}
insert(e);
} finally {
lock.unlock();
}
}
清单2 可阻塞的移除元素
public E take() throws InterruptedException {
final ReentrantLock lock = this.lock;
lock.lockInterruptibly();
try {
try {
while (count == 0)
notEmpty.await();
} catch (InterruptedException ie) {
notEmpty.signal(); // propagate to non-interrupted thread
throw ie;
}
E x = extract();
return x;
} finally {
lock.unlock();
}
}
需要注意到的是，尽管每次加入、移除一个元素使用的都是signal()通知，而不是signalAll()通知。我们参考上一节中notify替换notifyAll的原则：每一个await醒来的动作相同，每次最多唤醒一个线程来操作。显然这里符合这两种条件，因此使用signal要比使用signalAll要高效，并且是可靠的。
上图描述了take()/put()的索引位置示意图。
一开始takeIndex/putIndex都在E/0位置，然后每加入一个元素offer/put，putIndex都增加1，也就是往后边移动一位；每移除一个元素poll/take，takeIndex都增加1，也是往后边移动一位，显然takeIndex总是在putIndex的“后边”，因为当队列中没有元素的时候takeIndex和putIndex相等，同时当前位置也没有元素，takeIndex也就是无法再往右边移动了；一旦putIndex/takeIndex移动到了最后面，也就是size-1的位置（这里size是指数组的长度），那么就移动到0，继续循环。循环的前提是数组中元素的个数小于数组的长度。整个过程就是这样的。可见putIndex同时指向头元素的下一个位置（如果队列已经满了，那么就是尾元素位置，否则就是一个元素为null的位置）。
比较复杂的操作时删除任意一个元素。清单3 描述的是删除任意一个元素的过程。显然删除任何一个元素需要遍历整个数组，也就是它的复杂度是O(n)，这与根据索引从ArrayList中查找一个元素的复杂度O(1)相比开销要大得多。参考声明的结构图，一旦删除的是takeIndex位置的元素，那么只需要将takeIndex往“右边”移动一位即可；如果删除的是takeIndex和putIndex之间的元素怎么办？这时候就从删除的位置i开始，将i后面的所有元素位置都往“左”移动一位，直到putIndex为止。最终的结果是删除位置的所有元素都“后退”了一个位置，同时putIndex也后退了一个位置。
清单3 删除任意一个元素
public boolean remove(Object o) {
if (o == null) return false;
final E[] items = this.items;
final ReentrantLock lock = this.lock;
lock.lock();
try {
int i = takeIndex;
int k = 0;
for (;;) {
if (k++ >= count)
return false;
if (o.equals(items[i])) {
removeAt(i);
return true;
}
i = inc(i);
}} finally {
lock.unlock();
}
}
void removeAt(int i) {
final E[] items = this.items;
// if removing front item, just advance
if (i == takeIndex) {
items[takeIndex] = null;
takeIndex = inc(takeIndex);
} else {
// slide over all others up through putIndex.
for (;;) {
int nexti = inc(i);
if (nexti != putIndex) {
items[i] = items[nexti];
i = nexti;
} else {
items[i] = null;
putIndex = i;
break;
}
}
}
--count;
notFull.signal();
}
对于其他的操作，由于都是带着Lock的操作，所以都比较简单就不再展开了。
下一篇中将介绍另外两个BlockingQueue， PriorityBlockingQueue和SynchronousQueue 然后对这些常见的Queue进行一个小范围的对比。
深入浅出 Java Concurrency (22): 并发容器 part 7 可阻塞的BlockingQueue (2)[转]
标签：style blog http io ar 使用 sp java for
原文地址：http://www.cnblogs.com/0x2D-0x22/p/4138720.html
