SynchronousQueue#TransferQueue

阻塞队列中，SynchronousQueue算得上是一个比较有意思的队列，因为所有人对它的印象是如下

• 无容量
• 性能相较其他阻塞队列更佳。

翻了一下它的源码实现，发现设计上也确实有意思，跟我预想的设计完全不同。

数据结构

数据结构上选择的是一种双向的单链表，双向意味着维护首尾指针

/** Head of queue */
 transient volatile QNode head;
/** Tail of queue */
transient volatile QNode tail;

节点的设计上看，如果说按照生产者与消费者的角度来分析SynchronousQueue， 可以将isData作为区分点，如果isData是true则说明该线程是本次操作是生产者，反之则为消费者。waiter指针保存着当前线程对象，目的在于处理线程的阻塞/唤醒。

volatile QNode next;
volatile Object item;
volatile Thread waiter; 
final boolean isData;  

运作流程

初始化时创建了一个空的QNode节点，第一次进行put(e)， 操作的时候，会入队，入队后线程却被阻塞，等待e = take()来互补，也就是说“无容量”的说法其实不是很正确，它去入队之后被阻塞而已，但是队列中确实保存了对象

如下图，连续两个线程进行put(e)操作，（ct 指currentThread）

image.png

而此时又来一次e = take(e)操作

image.png

假设多次e = take()后，期间并未有put(e)操作

此时看下图发现，队列中维护的数据节点是消费者节点，而阻塞的正是消费者线程

image.png

核心的判断在于(h == t || t.isData == isData)，其次要注意由于初始化时创建了一个QNode节点，意味着head指向的节点为无效节点，所以看到程序代码中取有效数据会写head->next，这称之为哨兵节点的设计比较常见。

消费者与生产者同时会被维护到队列中，当互补匹配成功后会唤醒节点上阻塞的线程（消费者或者生产者），在整个生产者-消费者模型中，所有操作都没有任何加锁操作，这也是并发中性能略高的一点个(但是CAS自旋损耗不可忽视)。这个设计核心在于不能出现有消费者在入队等待，但是生产投递时却入队阻塞的现象，所以维护的队列节点要么都是生产者（生产 > 消费），要么都是消费者（消费 > 生产）

这个设计理念在RocketMQ中也有相似的设计，即可靠消息服务的设计。

服务端维护着一个数组列表，数组列表的元素包括数据，以及本次请求的线程包含的CountDownLatch对象。请求达到服务端后放入数组列表并通过CountDownLatch进行超时阻塞。同时服务端有另外的线程从数组列表中读取数据处理，处理完成后通过数据节点包含的CountDownLatch唤醒请求线程并返回，所以如果超时会唤醒线程进行二次请求处理，意味着下次被重复投递。

网上很多说性能更优，或者其他怎么怎么样，但是实际使用必须辩证看待。如果消费大于生产，那么性能自然很好，否则会出现生产者线程大量阻塞的情况，如果是Tomcat线程被大量阻塞，直接导致无线程可用，自然是得不偿失。用是一个层面，但是从该队列的设计来看，确实有意思，比我设想的设计要优很多。