前言
最近在工作中用到了LinkedBlockingQueue，不过随后发现了另一个与此用途十分类似的类ArrayBlockingQueue。于是花了点时间，查阅了相关的文章介绍，本篇就来简单的做个小结，也是为了方便下次查阅。
LinkedBlockingQueue和ArrayBlockingQueue的共性
在讲述LinkedBlockingQueue和ArrayBlockingQueue的区别前，我们还是先了解下这2个队列结构间的一些“共性”。
第一，首先它们都继承了BlockingQueue的接口，也就是说，它们都是阻塞式的队列，这里的阻塞情况无外乎2种：一种是队列满时阻塞等待，另一种就是队列空时阻塞等待，前者等待的生成者，后者则是消费者。所以这种结构用在生产者-消费者的使用场景中是比较适用的。还有一点，因为是队列，所以肯定保证FIFO顺序性的。
第二，既然都继承了BlockingQueue的接口，那么它们所对外提供的方法也是一致的，add/offer/put，take/poll/remove。这里面还能够支持阻塞，非阻塞的调用形式，总体来说还是非常灵活的。
LinkedBlockingQueue和ArrayBlockingQueue的区别
OK，这里是本文的重点了，也就是二者之间的区别了。
首先第一个区别，ArrayBlockingQueue是有界的，而LinkedBlockingQueue默认是无界的（可以通过指定大小来变为有界）。ArrayBlockingQueue有界就意味着我们使用ArrayBlockingQueue必须指定capacity大小。这样的话，内存空间会直接预先分配好，所以在使用LinkedBlockingQueue无界情况下时要考虑到内存实际使用问题，防止内存溢出问题的发生。
第二点，锁使用的比较。ArrayBlockingQueue内部使用1个锁来控制队列项的插入、取出操作，而LinkedBlockingQueue则是使用了2个锁来控制，一个名为putLock，另一个是takeLock，但是锁的本质都是ReentrantLock。因为LinkedBlockingQueue使用了2个锁的情况下，所以在一定程度上LinkedBlockingQueue能更好支持高并发的场景操作，这里指的是并发性上，不是吞吐量。
第三点，吞吐性能上的比较。这里其实会涉及到里面具体的操作差异的问题。在ArrayBlockingQueue内部，因为是直接使用数组空间的，而且都是预先分配好的，所以操作没有那么复杂，而在LinkedBlockingQueue中，是通过链表进行维护的，而且每次插入的对象还要转为Node<>(e)对象，相当于多做了一步操作，但是根据LinkedBlockingQueue的官方描述，它是具有更好吞吐性能的。
Linked queues typically have higher throughput than array-based queues but
less predictable performance in most concurrent applications.
这里还提到了一点“less predictable performance”，这点笔者认为应该是它引入了2个锁来控制插入/取出操作有关，在这点上会比ArrayBlockingQueue要复杂些。但是笔者一直好奇一点，在小规模场景下，是否ArrayBlockingQueue会比LinkedBlockingQueue更适用呢？这个大家可以试试，笔者也还没试过。