Java 7中的TransferQueue 以及 SynchronousQueue
Java7中加入了JSR 166y规范对集合类和并发类库的改进。其中的一项是增加了接口TransferQueue和其实现类LinkedTransferQueue。
TransferQueue继承了BlockingQueue（BlockingQueue又继承了Queue）并扩展了一些新方法。BlockingQueue（和Queue）是Java 5中加入的接口，它是指这样的一个队列：当生产者向队列添加元素但队列已满时，生产者会被阻塞；当消费者从队列移除元素但队列为空时，消费者会被阻塞。
TransferQueue则更进一步，生产者会一直阻塞直到所添加到队列的元素被某一个消费者所消费（不仅仅是添加到队列里就完事）。新添加的transfer方法用来实现这种约束。顾名思义，阻塞就是发生在元素从一个线程transfer到另一个线程的过程中，它有效地实现了元素在线程之间的传递（以建立Java内存模型中的happens-before关系的方式）。
TransferQueue还包括了其他的一些方法：两个tryTransfer方法，一个是非阻塞的，另一个带有timeout参数设置超时时间的。还有两个辅助方法hasWaitingConsumer()和getWaitingConsumerCount()。
当我第一次看到TransferQueue时，首先想到了已有的实现类SynchronousQueue。SynchronousQueue的队列长度为0，最初我认为这好像没多大用处，但后来我发现它是整个Java Collection Framework中最有用的队列实现类之一，特别是对于两个线程之间传递元素这种用例。
TransferQueue相比SynchronousQueue用处更广、更好用，因为你可以决定是使用BlockingQueue的方法（译者注：例如put方法）还是确保一次传递完成（译者注：即transfer方法）。在队列中已有元素的情况下，调用transfer方法，可以确保队列中被传递元素之前的所有元素都能被处理。Doug Lea说从功能角度来讲，LinkedTransferQueue实际上是ConcurrentLinkedQueue、SynchronousQueue（公平模式）和LinkedBlockingQueue的超集。而且LinkedTransferQueue更好用，因为它不仅仅综合了这几个类的功能，同时也提供了更高效的实现。
Joe Bowbeer提供了一篇William Scherer, Doug Lea, and Michael Scott的论文，在这篇论文中展示了LinkedTransferQueue的算法，性能测试的结果表明它优于Java 5的那些类（译者注：ConcurrentLinkedQueue、SynchronousQueue和LinkedBlockingQueue）。LinkedTransferQueue的性能分别是SynchronousQueue的3倍（非公平模式）和14倍（公平模式）。因为像ThreadPoolExecutor这样的类在任务传递时都是使用SynchronousQueue，所以使用LinkedTransferQueue来代替SynchronousQueue也会使得ThreadPoolExecutor得到相应的性能提升。考虑到executor在并发编程中的重要性，你就会理解添加这个实现类的重要性了。
Java 5中的SynchronousQueue使用两个队列（一个用于正在等待的生产者、另一个用于正在等待的消费者）和一个用来保护两个队列的锁。而LinkedTransferQueue使用CAS操作（译者注：参考wiki）实现一个非阻塞的方法，这是避免序列化处理任务的关键。这篇论文还罗列了很多的细节和数据，如果你感兴趣，非常值得一读。
SynchronousQueue
SynchronousQueue是这样 一种阻塞队列，其中每个 put 必须等待一个 take，反之亦然。同步队列没有任何内部容量，甚至连一个队列的容量都没有。
不能在同步队列上进行 peek，因为仅在试图要取得元素时，该元素才存在；
除非另一个线程试图移除某个元素，否则也不能（使用任何方法）添加元素；
也不能迭代队列，因为其中没有元素可用于迭代。队列的头是尝试添加到队列中的首个已排队线程元素； 如果没有已排队线程，则不添加元素并且头为 null。
对于其他 Collection 方法（例如 contains），SynchronousQueue 作为一个空集合。此队列不允许 null 元素。
同步队列类似于 CSP 和 Ada 中使用的 rendezvous 信道。
它非常适合于传递性设计，在这种设计中，在一个线程中运行的对象要将某些信息、
事件或任务传递给在另一个线程中运行的对象，它就必须与该对象同步。
对于正在等待的生产者和使用者线程而言，此类支持可选的公平排序策略。默认情况下不保证这种排序。
但是，使用公平设置为 true 所构造的队列可保证线程以 FIFO 的顺序进行访问。 公平通常会降低吞吐量，但是可以减小可变性并避免得不到服务。
注意1：它一种阻塞队列，其中每个 put 必须等待一个 take，反之亦然。
同步队列没有任何内部容量，甚至连一个队列的容量都没有。
注意2：它是线程安全的，是阻塞的。
注意3:不允许使用 null 元素。
注意4：公平排序策略是指调用put的线程之间，或take的线程之间。
公平排序策略可以查考ArrayBlockingQueue中的公平策略。
注意5:SynchronousQueue的以下方法很有趣：
* iterator() 永远返回空，因为里面没东西。
* peek() 永远返回null。
* put() 往queue放进去一个element以后就一直wait直到有其他thread进来把这个element取走。
* offer() 往queue里放一个element后立即返回，如果碰巧这个element被另一个thread取走了，offer方法返回true，认为offer成功；否则返回false。
* offer(2000, TimeUnit.SECONDS) 往queue里放一个element但是等待指定的时间后才返回，返回的逻辑和offer()方法一样。
* take() 取出并且remove掉queue里的element（认为是在queue里的。。。），取不到东西他会一直等。
* poll() 取出并且remove掉queue里的element（认为是在queue里的。。。），只有到碰巧另外一个线程正在往queue里offer数据或者put数据的时候，该方法才会取到东西。否则立即返回null。
* poll(2000, TimeUnit.SECONDS) 等待指定的时间然后取出并且remove掉queue里的element,其实就是再等其他的thread来往里塞。
* isEmpty()永远是true。
* remainingCapacity() 永远是0。
* remove()和removeAll() 永远是false。
转自：http://blog.csdn.net/hudashi/article/details/7076814
http://ifeve.com/java-transfer-queue/
http://www.cnblogs.com/wangzhongqiu/p/6441703.html
