java队列

java队列——queue详细分析

Queue： 基本上，一个队列就是一个先入先出（FIFO）的数据结构

Queue接口与List、Set同一级别，都是继承了Collection接口。LinkedList实现了Deque接 口。

 

Queue的实现

1、没有实现的阻塞接口的LinkedList： 实现了java.util.Queue接口和java.util.AbstractQueue接口
　　内置的不阻塞队列： PriorityQueue 和 ConcurrentLinkedQueue
　　PriorityQueue 和 ConcurrentLinkedQueue 类在 Collection Framework 中加入两个具体集合实现。 
　　PriorityQueue 类实质上维护了一个有序列表。加入到 Queue 中的元素根据它们的天然排序（通过其 java.util.Comparable 实现）或者根据传递给构造函数的 java.util.Comparator 实现来定位。
　　ConcurrentLinkedQueue 是基于链接节点的、线程安全的队列。并发访问不需要同步。因为它在队列的尾部添加元素并从头部删除它们，所以只要不需要知道队列的大 小，　　　　    　　ConcurrentLinkedQueue 对公共集合的共享访问就可以工作得很好。收集关于队列大小的信息会很慢，需要遍历队列。

2)实现阻塞接口的：
　　java.util.concurrent 中加入了 BlockingQueue 接口和五个阻塞队列类。它实质上就是一种带有一点扭曲的 FIFO 数据结构。不是立即从队列中添加或者删除元素，线程执行操作阻塞，直到有空间或者元素可用。
五个队列所提供的各有不同：
　　* ArrayBlockingQueue ：一个由数组支持的有界队列。单锁
　　* LinkedBlockingQueue ：一个由链接节点支持的可选有界队列。双锁
　　* PriorityBlockingQueue ：一个由优先级堆支持的无界优先级队列。
　　* DelayQueue ：一个由优先级堆支持的、基于时间的调度队列。
　　* SynchronousQueue ：一个利用 BlockingQueue 接口的简单聚集（rendezvous）机制。

公平锁（Fair）：加锁前检查是否有排队等待的线程，优先排队等待的线程，先来先得

非公平锁（Nonfair）：加锁时不考虑排队等待问题，直接尝试获取锁，获取不到自动到队尾等待

下表显示了jdk1.5中的阻塞队列的操作：

　　add        增加一个元索                     如果队列已满，则抛出一个IIIegaISlabEepeplian异常
　　remove   移除并返回队列头部的元素    如果队列为空，则抛出一个NoSuchElementException异常
　　element  返回队列头部的元素             如果队列为空，则抛出一个NoSuchElementException异常
　　offer       添加一个元素并返回true       如果队列已满，则返回false
　　poll         移除并返问队列头部的元素    如果队列为空，则返回null
　　peek       返回队列头部的元素             如果队列为空，则返回null
　　put         添加一个元素                      如果队列满，则阻塞
　　take        移除并返回队列头部的元素     如果队列为空，则阻塞

LinkedBlockingQueue的容量是没有上限的（说的不准确，在不指定时容量为Integer.MAX_VALUE，不要然的话在put时怎么会受阻呢），但是也可以选择指定其最大容量，它是基于链表的队列，此队列按 FIFO（先进先出）排序元素。

ArrayBlockingQueue在构造时需要指定容量， 并可以选择是否需要公平性，如果公平参数被设置true，等待时间最长的线程会优先得到处理（其实就是通过将ReentrantLock设置为true来 达到这种公平性的：即等待时间最长的线程会先操作）。通常，公平性会使你在性能上付出代价，只有在的确非常需要的时候再使用它。它是基于数组的阻塞循环队 列，此队列按 FIFO（先进先出）原则对元素进行排序。

PriorityBlockingQueue是一个带优先级的 队列，而不是先进先出队列。元素按优先级顺序被移除，该队列也没有上限（看了一下源码，PriorityBlockingQueue是对 PriorityQueue的再次包装，是基于堆数据结构的，而PriorityQueue是没有容量限制的，与ArrayList一样，所以在优先阻塞 队列上put时是不会受阻的。虽然此队列逻辑上是无界的，但是由于资源被耗尽，所以试图执行添加操作可能会导致 OutOfMemoryError），但是如果队列为空，那么取元素的操作take就会阻塞，所以它的检索操作take是受阻的。另外，往入该队列中的元 素要具有比较能力。

DelayQueue（基于PriorityQueue来实现的）是一个存放Delayed 元素的无界阻塞队列，只有在延迟期满时才能从中提取元素。该队列的头部是延迟期满后保存时间最长的 Delayed 元素。如果延迟都还没有期满，则队列没有头部，并且poll将返回null。当一个元素的 getDelay(TimeUnit.NANOSECONDS) 方法返回一个小于或等于零的值时，则出现期满，poll就以移除这个元素了。此队列不允许使用 null 元素。DelayQueue内部封装了一个PriorityQueue，它会根据time的先后时间排序（time小的排在前面），若time相同则根据sequenceNumber排序（ sequenceNumber小的排在前面）

SynchronousQueue 使用SynchronousQueue的目的就是保证“对于提交的任务，如果有空闲线程，则使用空闲线程来处理；否则新建一个线程来处理任务”。
直接交付方式还会将更多关于任务状态的信息反馈给生产者。当交付被接受时，它就知道消费者已经得到了任务，而不是简单地把任务放入一个队列——这种区别就好比将文件直接交给同事，还是将文件放到她的邮箱中并希望她能尽快拿到文件。

因为SynchronousQueue没有存储功能，因此put和take会一直阻塞，直到有另一个线程已经准备好参与到交付过程中。仅当有足够多的消费者，并且总是有一个消费者准备好获取交付的工作时，才适合使用同步队列。
 

ReentrantLock常常对比着synchronized来分析，我们先对比着来看然后再一点一点分析。

（1）synchronized是独占锁，加锁和解锁的过程自动进行，易于操作，但不够灵活。ReentrantLock也是独占锁，加锁和解锁的过程需要手动进行，不易操作，但非常灵活。

（2）synchronized可重入，因为加锁和解锁自动进行，不必担心最后是否释放锁；ReentrantLock也可重入，但加锁和解锁需要手动进行，且次数需一样，否则其他线程无法获得锁。

（3）synchronized不可响应中断，一个线程获取不到锁就一直等着；ReentrantLock可以相应中断。

ReentrantLock好像比synchronized关键字没好太多，我们再去看看synchronized所没有的，一个最主要的就是ReentrantLock还可以实现公平锁机制。

ReentrantLock 锁有好几种，除了常用的lock ，tryLock ，其中有个lockInterruptibly 。

可重入是指一个线程在没有释放这个锁时，可以再次获取该锁，锁计数器+1.

阻塞队列的选择

阻塞队列的实现包括ArrayBlockingQueue与LinkedBlockingQueue。相同点不做赘述，区别有以下几点：
1.初始化时，ArrayBlockingQueue必须指定队列最大容量，LinkedBlockingQueue不强制指定，若不指定，默认Interger.Max为最大容量。
2.ArrayBlockingQueue内部数据结构是数组:Element[]，通过putIndex和takeIndex下标的循环移动控制队首和队尾；LinkedBlockingQueue内部结构是链表:Node<Element>，通过head 和 tail节点控制队首和队尾。
3.ArrayBlockingQueue生产与消费之间共用一把锁，而LinkedBlockingQueue生产与消费时用不同的锁竞争。

对于阻塞队列的选择，一方面考虑吞吐性能，另一方面考虑内存占用。

我们可以看到上面说的第三点，可以确定的是，在多生产者与多消费者的情况下，LinkedBlockingQueue的吞吐性能肯定是要更高的，而且ArrayBlockingQueue在初始化时直接就申请了一片连续的内存空间。所以在实际生产使用环境中，没有特殊限制考虑，我们在使用阻塞队列时往往用LinkedBlockingQueue。

那什么场景下我们会偏向于使用ArrayBlockingQueue呢？

• 生产者与消费者之间没有太大竞争，倾向于单消费者，单生产者，且两者之间冲突较小，这种情况下数组寻址是明显要比链表去指向next的操作要更快的
• 基本可以确定队列大小，且队列大小稳定在一定的数量，这个时候数组占用内存是比链表小的

阻塞队列与非阻塞队列的选择

首先，ConcurrentLinkedQueue相对阻塞队列来说，采用的是CAS无锁操作，没有take和put方法，主用poll与offer，无界。有人说，既然此队列内部进队和出队操作采用的是无锁，那性能肯定比有锁的BlockingQueue强，那BlockingQueue还有啥用武之地，其实不然，有些时候我们就需要线程进入阻塞状态而非不断自旋消耗CPU，我们可以归类以下场景：

• 数据入队速度过快，出队速度过慢，这个时候ConcurrentLinkedQueue如果不借助其他限制手段，随着时间的推移，JVM必然会进行频繁的FULL GC ,严重的情况下甚至会发生OOM。使用BlockingQueue可以更好的控制内存的状况。
• 数据入队速度过慢，出队速度过快，这个时候消费者线程如果一定想要拿到数据而不进行阻塞，将进入大量时间的自旋状态，白白浪费CPU资源。
• 入队与出队速度相仿。
  这时候要考虑速度，有多少个线程在同时做操作，线程操作的频率如何？
  在大部分场景下，ConcurrentLinkedQueue的性能是要比BlockingQueue要好的，注意是大部分，如果线程之间的竞争足够又高又快，CAS操作的CPU消耗以及线程操作的成功率是极低的，这个时候是会反而不如用锁竞争控制效率来的高。
  我们写了个测试类可以大致看下观感下，在同样的环境下，消费者与生产者在不断对队列进行操作，然后不断增加消费者与生产者内部线程的数量。