前言：

BlockingQueue很好的解决了多线程中，如何高效安全“传输”数据的问题。通过这些高效并且线程安全的队列类，为我们快速搭建高质量的多线程程序带来极大的便利。本文详细介绍了BlockingQueue家庭中的两个重要成员，包括他们各自的功能以及常见使用场景。

认识BlockingQueue

阻塞队列，顾名思义，首先它是一个队列，而一个队列在数据结构中所起的作用大致如下图所示：

从图中我们可以很清楚看到，通过一个共享的队列，可以使得数据由队列的一端输入，从另外一端输出；常用的队列主要有以下两种：(当然通过不同的实现方式，还可以延伸出很多不同类型的队列，DelayQueue就是其中的一种)

先进先出(FIFO)：先插入的队列的元素也最先出队列，类似于排队的功能。从某种程度上来说这种队列也体现了一种公平性。

后进先出(LIFO)：后插入队列的元素最先出队列，这种队列优先处理最近发生的事件。

多线程环境中，通过队列可以很容易实现数据共享，比如经典的“生产者”和“消费者”模型中，通过队列可以很便利地实现两者之间的数据共享。假设我们有若干生产者线程，另外又有若干个消费者线程。如果生产者线程需要把准备好的数据共享给消费者线程，利用队列的方式来传递数据，就可以很方便地解决他们之间的数据共享问题。但如果生产者和消费者在某个时间段内，万一发生数据处理速度不匹配的情况呢？理想情况下，如果生产者产出数据的速度大于消费者消费的速度，并且当生产出来的数据累积到一定程度的时候，那么生产者必须暂停等待一下(阻塞生产者线程)，以便等待消费者线程把累积的数据处理完毕，反之亦然。

然而，在concurrent包发布以前，在多线程环境下，我们每个程序员都必须去自己控制这些细节，尤其还要兼顾效率和线程安全，而这会给我们的程序带来不小的复杂度。好在此时，强大的concurrent包横空出世了，而他也给我们带来了强大的BlockingQueue。(在多线程领域：所谓阻塞，在某些情况下会挂起线程，一旦条件满足，被挂起的线程又会自动被唤醒)

下面两幅图演示了BlockingQueue的两个常见阻塞场景：

如图所示：当队列中没有数据的情况下，消费者端的所有线程都会被自动阻塞(挂起)，直到有数据放入队列。

如图所示：当队列中填满数据的情况下，生产者端的所有线程都会被自动阻塞(挂起)，直到队列中有空的位置，线程被自动唤醒。

这也是我们在多线程环境下，为什么需要BlockingQueue的原因。作为BlockingQueue的使用者，我们再也不需要关心什么时候需要阻塞线程，什么时候需要唤醒线程，因为这一切BlockingQueue都给你一手包办了。既然BlockingQueue如此神通广大，让我们一起来见识下它的常用方法：

BlockingQueue的核心方法：

放入数据：

offer(anObject):表示如果可能的话,将anObject加到BlockingQueue里,即如果BlockingQueue可以容纳,则返回true,否则返回false.(本方法不阻塞当前执行方法的线程)

offer(E o, long timeout, TimeUnit unit),可以设定等待的时间，如果在指定的时间内，还不能往队列中加入BlockingQueue，则返回失败。

put(anObject):把anObject加到BlockingQueue里,如果BlockQueue没有空间,则调用此方法的线程被阻断直到BlockingQueue里面有空间再继续.

获取数据：

poll(time):取走BlockingQueue里排在首位的对象,若不能立即取出,则可以等time参数规定的时间,取不到时返回null;

poll(long timeout, TimeUnit unit)：从BlockingQueue取出一个队首的对象，如果在指定时间内，队列一旦有数据可取，则立即返回队列中的数据。否则知道时间超时还没有数据可取，返回失败。

take():取走BlockingQueue里排在首位的对象,若BlockingQueue为空,阻断进入等待状态直到BlockingQueue有新的数据被加入;

drainTo():一次性从BlockingQueue获取所有可用的数据对象(还可以指定获取数据的个数)，通过该方法，可以提升获取数据效率；不需要多次分批加锁或释放锁。

常见BlockingQueue

在了解了BlockingQueue的基本功能后，让我们来看看BlockingQueue家庭大致有哪些成员？

1. ArrayBlockingQueue

基于数组的阻塞队列实现，在ArrayBlockingQueue内部，维护了一个定长数组，以便缓存队列中的数据对象，这是一个常用的阻塞队列，除了一个定长数组外，ArrayBlockingQueue内部还保存着两个整形变量，分别标识着队列的头部和尾部在数组中的位置。

ArrayBlockingQueue在生产者放入数据和消费者获取数据，都是共用同一个锁对象，由此也意味着两者无法真正并行运行，这点尤其不同于LinkedBlockingQueue；

按照实现原理来分析，ArrayBlockingQueue完全可以采用分离锁，从而实现生产者和消费者操作的完全并行运行。之所以没这样去做，猜测是因为ArrayBlockingQueue的数据写入和获取操作已经足够轻巧，以至于引入独立的锁机制，除了给代码带来额外的复杂性外，其在性能上完全占不到任何便宜。

ArrayBlockingQueue和LinkedBlockingQueue间还有一个明显的不同之处在于，前者在插入或删除元素时不会产生或销毁任何额外的对象实例，而后者则会生成一个额外的Node对象。这在长时间内需要高效并发地处理大批量数据的系统中，其对于GC的影响还是存在一定的区别。而在创建ArrayBlockingQueue时，我们还可以控制对象的内部锁是否采用公平锁，默认采用非公平锁。

2. LinkedBlockingQueue

基于链表的阻塞队列，同ArrayListBlockingQueue类似，其内部也维持着一个数据缓冲队列(该队列由一个链表构成)，当生产者往队列中放入一个数据时，队列会从生产者手中获取数据，并缓存在队列内部，而生产者立即返回；只有当队列缓冲区达到最大值缓存容量时(LinkedBlockingQueue可以通过构造函数指定该值)，才会阻塞生产者队列，直到消费者从队列中消费掉一份数据，生产者线程会被唤醒，反之对于消费者这端的处理也基于同样的原理。而LinkedBlockingQueue之所以能够高效的处理并发数据，还因为其对于生产者端和消费者端分别采用了独立的锁来控制数据同步，这也意味着在高并发的情况下生产者和消费者可以并行地操作队列中的数据，以此来提高整个队列的并发性能。

作为开发者，我们需要注意的是，如果构造一个LinkedBlockingQueue对象，而没有指定其容量大小，LinkedBlockingQueue会默认一个类似无限大小的容量(Integer.MAX_VALUE)，这样的话，如果生产者的速度一旦大于消费者的速度，也许还没有等到队列满阻塞产生，系统内存就有可能已被消耗殆尽了。

ArrayBlockingQueue和LinkedBlockingQueue是两个最普通也是最常用的阻塞队列，一般情况下，在处理多线程间的生产者消费者问题，使用这两个类足以。

BlockingQueueTest.java

importjava.util.concurrent.BlockingQueue;

importjava.util.concurrent.ExecutorService;

importjava.util.concurrent.Executors;

importjava.util.concurrent.LinkedBlockingQueue;

public classBlockingQueueTest {

public static void main(String[] args) throwsInterruptedException {

//声明一个容量为10的缓存队列

BlockingQueue queue = new LinkedBlockingQueue(10);

Producer producer1 = newProducer(queue);

Producer producer2 = newProducer(queue);

Producer producer3 = newProducer(queue);

Consumer consumer = newConsumer(queue);

//借助Executors

ExecutorService service =Executors.newCachedThreadPool();

//启动线程

service.execute(producer1);

service.execute(producer2);

service.execute(producer3);

service.execute(consumer);

//执行10s

Thread.sleep(10 * 1000);

producer1.stop();

producer2.stop();

producer3.stop();

Thread.sleep(2000);

//退出Executor

service.shutdown();

}

}

Cosumer.java

importjava.util.Random;

importjava.util.concurrent.BlockingQueue;

importjava.util.concurrent.TimeUnit;

public class Consumer implementsRunnable {

public Consumer(BlockingQueuequeue) {

this.queue =queue;

}

public voidrun() {

System.out.println("启动消费者线程！");

Random r = newRandom();

boolean isRunning = true;

try{

while(isRunning) {

System.out.println("正从队列获取数据...");

String data = queue.poll(2, TimeUnit.SECONDS);

if (null !=data) {

System.out.println("拿到数据：" +data);

System.out.println("正在消费数据：" +data);

Thread.sleep(r.nextInt(DEFAULT_RANGE_FOR_SLEEP));

} else{

//超过2s还没数据，认为所有生产线程都已经退出，自动退出消费线程。

isRunning = false;

}

}

} catch(InterruptedException e) {

e.printStackTrace();

Thread.currentThread().interrupt();

} finally{

System.out.println("退出消费者线程！");

}

}

private BlockingQueuequeue;

private static final int DEFAULT_RANGE_FOR_SLEEP = 1000;

}

Producer.java

importjava.util.Random;

importjava.util.concurrent.BlockingQueue;

importjava.util.concurrent.TimeUnit;

importjava.util.concurrent.atomic.AtomicInteger;

public class Producer implementsRunnable {

publicProducer(BlockingQueue queue) {

this.queue =queue;

}

public voidrun() {

String data = null;

Random r = newRandom();

System.out.println("启动生产者线程！");

try{

while(isRunning) {

System.out.println("正在生产数据...");

Thread.sleep(r.nextInt(DEFAULT_RANGE_FOR_SLEEP));

data = "data:" +count.incrementAndGet();

System.out.println("将数据：" + data + "放入队列...");

if (!queue.offer(data, 2, TimeUnit.SECONDS)) {

System.out.println("放入数据失败：" +data);

}

}

} catch(InterruptedException e) {

e.printStackTrace();

Thread.currentThread().interrupt();

} finally{

System.out.println("退出生产者线程！");

}

}

public voidstop() {

isRunning = false;

}

private volatile boolean isRunning = true;

privateBlockingQueue queue;

private static AtomicInteger count = newAtomicInteger();

private static final int DEFAULT_RANGE_FOR_SLEEP = 1000;

}

执行结果：

。。。。。。。。。。。。。。。

正从队列获取数据...

拿到数据：data:36正在消费数据：data:36正从队列获取数据...

拿到数据：data:37正在消费数据：data:37正从队列获取数据...

拿到数据：data:38正在消费数据：data:38。。。。。。。。。。。。

原文：http://www.cnblogs.com/liqiu/p/3630281.html