Queue概览
如图所示，在并发队列上，JDK提供了2套实现，一个是以ConcurrentLinkedQueue为代表的高性能非阻塞队列，一个是以BlockingQueue接口为代表的阻塞队列，无论哪种都继承自Queue。使用阻塞算法的队列可以用一个锁（入队和出队用同一把锁）或两个锁（入队和出队用不同的锁）等方式来实现，而非阻塞的实现方式则可以使用循环CAS的方式来实现,下面我们来一一分析。
ConcurrentLinkedQueue
一个适用于高并发场景下的队列，通过无锁的方式（CAS+volatile），实现了高并发下的高性能，通常ConcurrentLinkedQueue的性能好于BlockingQueue。
它是一个基于链接节点的无界线程安全队列，遵循先进先出的原则，头是最先加入的，尾是最近加入的，不允许加入null元素。
注意add()/offer()都是加入元素的方法，这里没有区别；poll()/peek()是取出头元素的方法，区别点在于poll会删除元素，而peek不会。
要特别注意到由于它的非阻塞性，并不像其他普通集合那样，获取队列的SIZE的方法并不是常量时间的花费，而是O（N）的，因此我们应该尽可能避免使用size()方法，可以考虑使用isEmpty()代替。
虽然使用到了CAS+VOLATILE的机制避免了锁，但是我们要明白的是，这只是保证单个操作，如peek()的安全，但是多个操作如果想保证的话，需要使用锁机制来达到同步的效果。
BlockingQueue API
入队：
offer(E e)：如果队列没满，立即返回true； 如果队列满了，立即返回false-->不阻塞
put(E e)：如果队列满了，一直阻塞，直到数组不满了或者线程被中断-->阻塞
offer(E e, long timeout, TimeUnit unit)：在队尾插入一个元素,，如果数组已满，则进入等待，直到等待时间超时
出队：
poll():非阻塞拿数据，立即返回
take():阻塞拿数据
poll(long timeout, TimeUnit unit):带有一定超时时间的poll拿取数据
ArrayBlockingQueue
基于数组的阻塞队列实现，在其内部维护了一个定长数组，以便缓存队列中的数据对象，由于ArrayBlockingQueue内部只有一个锁对象（ReentrantLock），因此读写没有实现分离，也就意味着生产消费不能完全并行。由于长度需要定义，因此也叫有界队列。
LinkedBlockingQueue
基于链表的阻塞队列实现，同ArrayBlockingQueue类似，其内部也维持着一个数据缓冲队列（链表构成）。
LinkedBlockingQueue之所以较ArrayBlockingQueue更加高效的处理并发数据，是因为内部实现采用了2把锁，也就是实现了入队、出队分别上锁，即读写分离，从而生产者、消费者完全到达了并行。
无需定义长度，也叫无界队列。当然不定义长度时，需要注意下生产者的速度和消费者的速度，因为默认情况下队列长度是Integer.MAX_VALUE。
SynchronousQueue
一个没有缓冲的队列，生产者生产的数据会直接被消费者获取到并消费。它是一个轻量级的阻塞队列，因为不具备容量，在用法上，只能是一个线程阻塞着取元素，等待另一个线程往队列里面放入一个元素，然后会被等待着的线程立即取走，其实就是实现了线程间的轻量级的单元素交换。
PriorityBlockingQueue
基于优先级的阻塞队列（优先级的判断通过构造函数传入的Compator对象决定，也就是传入队列中对象必须实现Comparable接口）。
在实现PriorityBlockingQueue时，内部控制线程同步的锁采用的是公平锁，也是一个无界的队列。
通俗的来说，不是先进先出的队列了，而是谁的优先级低谁先出去。那么可以思考下，是否每次add/offer都会进行一次排序呢？我们是否需要按照优先级进行全排序呢？实际上，可以大致看一看add/take方法，会了解到PriorityBlockingQueue的设计思想：在add时，并不进行排序处理，当进行take时，选择优先级最小的拿出来而已，这样既避免了在add时花费时间排序，又在take时节省了时间，因为并没有全排序，仅仅是挑选了一个优先级低的元素而已。
DelayQueue
带有延迟时间的Queue,其中的元素只有当指定的延迟时间到了，才能从队列中获取到该元素。队列中的元素必须实现Delayed接口，没有大小限制。本质上来说，是借助于PriorityBlockingQueue来实现的，以延迟时间作为优先级。延迟队列的应用场景很多，比如缓存超时的数据进行移除，任务超时处理，空闲连接的关闭等等。
本文转自zfz_linux_boy 51CTO博客，原文链接：http://blog.51cto.com/zhangfengzhe/1878323，如需转载请自行联系原作者
