TransferQueue是一个继承了 BlockingQueue的接口，并且增加若干新的方法。LinkedTransferQueue是实现类，其定义为一个无界的队列，一样具有先进先出(FIFO : first-in-first-out)的特性。
Doug Lea 这样评价它：
TransferQueue是一个聪明的队列，它是ConcurrentLinkedQueue, SynchronousQueue (在公平模式下), 无界的LinkedBlockingQueues等的超集。
显然易见，混合了若干高级特性，并且具有高性能的一个组合体，一个多面手。
这里有一个有关LinkedTransferQueue的Doug Lea等人所撰写论文，讨论了其算法、性能等，地址：http://www.cs.rice.edu/~wns1/papers/2006-PPoPP-SQ.pdf
单纯从队列来看，TransferQueue接口增加了一些很实用的新特性，其transfer方法提供了线程之间直接交换对象的捷径，下面一一说来。
- transfer(E e)
若当前存在一个正在等待获取的消费者线程，即立刻移交之；否则，会插入当前元素e到队列尾部，并且等待进入阻塞状态，到有消费者线程取走该元素。 - tryTransfer(E e)
若当前存在一个正在等待获取的消费者线程（使用take()或者poll()函数），使用该方法会即刻转移/传输对象元素e；
若不存在，则返回false，并且不进入队列。
这是一个不阻塞的操作。 - tryTransfer(E e, long timeout, TimeUnit unit)
若当前存在一个正在等待获取的消费者线程，会立即传输给它;
否则将插入元素e到队列尾部，并且等待被消费者线程获取消费掉,
若在指定的时间内元素e无法被消费者线程获取，则返回false，同时该元素被移除。 - hasWaitingConsumer()
很明显，判断是否终端消费者线程 - getWaitingConsumerCount()
字面意思很明白，获取终端所有等待获取元素的消费线程数量 - size()
因为队列的异步特性，检测当前队列的元素个数需要逐一迭代，可能会得到一个不太准确的结果，尤其是在遍历时有可能队列发生更改。 - 批量操作
类似于 addAll，removeAll, retainAll, containsAll, equals, toArray 等方法，API不能保证一定会立刻执行。
因此，我们在使用过程中，不能有所期待，这是一个具有异步特性的队列。
注意事项：- 无论是transfer还是tryTransfer方法，在>=1个消费者线程等待获取元素时（此时队列为空），都会立刻转交，这属于线程之间的元素交换。注意，这时，元素并没有进入队列。
- 在队列中已有数据情况下，transfer将需要等待前面数据被消费掉，直到传递的元素e被消费线程取走为止。
- 使用transfer方法，工作者线程可能会被阻塞到生产的元素被消费掉为止
- 消费者线程等待为零的情况下，各自的处理元素入队与否情况有所不同。
- size()方法，需要迭代，可能不太准确，尽量不要调用。
或许，下次我们在构造一个线程池时，可以考虑使用TransferQueue：
public static ExecutorService newTransferCachedThreadPool() {
return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
60L, TimeUnit.SECONDS,
new LinkedTransferQueue());
}
简单测试代码: