Java同步数据结构之LinkedTransferQueue
前言
LinkedTransferQueue是Java并发包中最强大的基于链表的无界FIFO阻塞传输队列。从JDK7开始出现，Doug Lea说LinkedTransferQueue是ConcurrentLinkedQueue、SynchronousQueue (公平模式下)、无界的LinkedBlockingQueues等的超集，这句话就已经说明了LinkedTransferQueue的特性了，首先LinkedTransferQueue是基于链表的无界FIFO阻塞队列，它是接口TransferQueue的实现类，而TransferQueue又继承了接口BlockingQueue，所以说它有无界的LinkedBlockingQueues的特性，它通过CAS实现，并且队列的head与tail指针如同ConcurrentLinkedQueue一样并不总是指向队列的头和尾节点，所以它有ConcurrentLinkedQueue的特性，最后它实现的接口TransferQueue定义的transfer接口方法实现了类似SynchronousQueue的特性，即生产者（调用transfer的线程）必须等到一个消费者（调用BlockingQueue.take()或定时poll的线程）接收指定的元素完成数据的单向传递才返回，否则阻塞等待。
我们知道SynchronousQueue虽然被设计成数据的单向传递工具，但是它其实并不是一个真正意义上的队列（对外部使用者来说），因为所有Collection的相关方法（包括迭代器）都将把SynchronousQueue当成一个空队列处理，然而LinkedTransferQueue却同时具有队列容量与SynchronousQueue的特性，这在某些时候是非常有用的，例如在消息传递应用程序中，生产者有时(使用TransferQueue的transfer方法)需要等待调用take或poll的消费者接收元素，而在其他时候又不需要等待接收就可以(通过put等BlockingQueue的方法)加入队列元素。还可以通过hasWaitingConsumer查询TransferQueue中是否有线程在等待数据。
TransferQueue接口
TransferQueue接口继承了BlockingQueue，它定义了如下几个自己特有的方法，TransferQueue被设计成类似SynchronousQueue的功能，即生产者可以等待消费者接收元素。
boolean tryTransfer(E e);
如果存在一个消费者已经在等待接收元素(通过BlockingQueue.take()或定时poll)，则立即传输指定的元素，否则返回false而不入队该元素。
void transfer(E e)；
如果存在一个消费者已经在等待接收元素(通过BlockingQueue.take()或定时poll)，则立即传输指定的元素，否则等待直到该元素被一个消费者接收。
boolean tryTransfer(E e, long timeout, TimeUnit unit)；超时版本的tryTransfer。
boolean hasWaitingConsumer()；
如果至少有一个消费者在通过BlockingQueue.take()或定时poll等待接收元素，则返回true。返回值表示事件的瞬时状态。
int getWaitingConsumerCount();
返回通过BlockingQueue.take()或定时poll等待接收元素的消费者数量的估计值。返回值是对事件瞬间状态的近似，如果消费者已经完成或放弃等待，则返回值可能不准确。该值可能对监视和启发有用，但对同步控制没用。此方法的实现可能比hasWaitingConsumer()方法的实现要慢得多。
与其他阻塞队列一样，TransferQueue可能有容量限制。如果是这样，尝试的传输操作可能首先阻塞等待可用空间，然后阻塞等待消费者接收。注意，在容量为零的队列中，例如SynchronousQueue, put和transfer实际上是同义词。
LinkedTransferQueue
原理简介
JavaDoc中使用了大量的说明来阐述其整个设计想法与具体实现，从中可以看出LinkedTransferQueue采用基于松弛阈值的双队列实现，所谓双队列即它的节点既可以表示数据，也可以表示请求，这和SynchronousQueue的节点定义是一样的，甚至其内部节点的源码都与SynchronousQueue的公平模式下的节点字段一样，当然其实现元素传递的过程也与SynchronousQueue的原理差不多：当一个线程试图入队一个数据节点，但遇到一个请求节点时，它会与其完成“匹配”并出队,反之亦然。具体来说，对BlockingQueue的实现部分会使未被匹配的请求节点入队阻塞直到其它数据线程来与其完成匹配，而对TransferQueue的实现同步队列部分也会使未被匹配的数据节点入队阻塞直到其它请求线程来与其完成匹配，LinkedTransferQueue可以通过调用者传递的参数来同时对这两种模式进行支持。
而所谓的松弛阈值其实指，在对head、tail两个指针的维护时，允许它们距离第一个未匹配节点/最后一个节点的距离，ConcurrentLinkedQueue中也有相应的设计，即head不总是指向队列第一个节点，tail也不总是指向队列的最后一个节点，因为当维护(通过CAS)这些head和tail指针时，容易受到可伸缩性和开销限制，这种基于松弛阈值的策略减少了对队列指针更新的开销和争用，LinkedTransferQueue与ConcurrentLinkedQueue中该阈值都为2，即只要距离超过1就需要更新head/tail，这时候可以通过检查遍历指针的相等性来实现大于1的路径，除非队列只有一个元素，在这种情况下，我们将阈值保持为1。该松弛阈值的最佳取值是一个经验问题，在1-3的范围内使用非常小的常量在各种平台上工作得最好。较大的值会增加缓存未命中的成本和长遍历链(即，遍历时遇到无效节点需要从head重遍历)的风险，而较小的值会增加CAS争用和开销。
作为对松弛阈值技术的扩展，通过将无效节点的next指向自身（即自链接）限制了死链接的长度，这对垃圾回收也是一种优化考虑，然而这将使得遍历过程变得复杂化，在遍历过程中遇到这种自链接节点就表明当前线程落后于head的更新，遍历必须重新从head开始，另外试图从“tail”开始查找当前真正的尾节点的遍历可能也会遇到自链接，在这种情况下，它们也会重新从“head”开始遍历。
LinkedTransferQueue使head和tail在第一个节点进入队列之前都为null（即初始化状态），而在第一次入队节点时才初始化head和tail。这简化了其他一些逻辑，并提供了更有效的显式路径控制。
LinkedTransferQueue的所有入队/出队操作都由单个方法“xfer”处理，其参数指示是作为哪种形式的offer、put、poll、take还是transfer(每个可能都有超时)，而整个出入队的过程由三个阶段也就是三个方法实现分别是xfer，tryAppend，awaitMatch。
阶段1. 尝试匹配一个存在的节点（xfer方法中的内部for循环）
- 从head开始，跳过已经匹配的节点，直到找到一个模式相反的未匹配节点，如果存在的话完成匹配并返回，如有必要，会将head更新到匹配节点的下一个节点(如果列表中没有其他未匹配的节点，则是节点本身)，以保证松弛阀值不超过1。匹配过程中如果发现当前循环到的节点已经出队，则从head重新开始。
- 如果没有找到候选节点，并且是被poll，tryTransfer调用，则立即返回。
阶段2. tryAppend --- 尝试添加一个新节点
- 从当前tail指针开始，找到实际的最后一个节点，并尝试添加一个新节点(如果head为null，则创建第一个节点)。只有当节点的前驱节点已经匹配或具有相同的模式时，才可以添加节点。如果检测到其他情况，则说明在遍历期间有模式相反的节点进入了队列中，因此必须重新尝试阶段1，遍历和更新步骤与阶段1类似：在CAS失败时重试并检查过期。如果遇到自链接，则可以通过从当前head重新遍历，安全地跳转到列表中的节点。
- 如果节点成功入队，并且调用是异步而不是同步，则立即返回。
阶段3. awaitMatch --- 等待匹配或取消
- 等待另一个线程匹配节点，如果当前线程被中断或等待超时，则取消。在多处理器上，我们使用front-of-queue自旋：即如果一个节点是队列中第一个不匹配的节点，它会在阻塞之前自旋一会。不论发生何种情况，在阻塞之前，它都会尝试将当前“head”和第一个未匹配节点之间的任何节点断开链接。
- 阻塞前这种自旋策略极大地提高了竞争激烈的队列的性能。而且如果自旋足够快和短暂，对竞争较少的队列的性能影响也不大。在自旋期间，线程会检查它们的中断状态，并生成一个线程本地随机数，以决定是否偶尔执行Thread.yield出让CPU。这种随机出让CPU的方式有可能降低自旋对竞争繁忙的队列造成的影响。此外，针对后面的更多链式的自旋节点采用更小（1/2）的自旋，从而避免大量节点的交替自旋和阻塞。
对于内部已删除或由于中断/超时而取消节点的清理，通常采用将其前驱的next指向被移除节点的next来清理它。但有两种情况下，我们不能保证能够通过这种方式清理该节点使其不可达：①如果s队列的尾节点（即，其next为null），它被认为是入队节点的目标节点，所以我们只有在有新节点入队之后才能清理它。②如果其前驱是已经被匹配(或被取消)的节点，这时候其前驱可能已经从队列中断开了链接，并且更前面的可达节点可能依然指向s。如果不考虑这些因素可能将会导致无限数量的可能已删除的节点仍然可访问，虽然这种情况并不多见，但在实践中是真实可能发生的例如，当一系列的带短时间超时时间的poll调用重复超时时，由于存在一个不定时的take操作导致那些超时poll不会从队列中移除。当出现这种情况时，并不会总是重新遍历整个队列，以找到一个要取消节点的真实前驱节点（这对情况①是没有任何作用的），而是记录清理失败的估计次数（通过sweepvote变量），当这个次数超过一个阀值（“SWEEP_THRESHOLD”）时，才触发一次完整的清理。这个阀值（“SWEEP_THRESHOLD”）的选取也是一个经验值，它平衡了浪费精力和争用的可能性，而不是将无效节点长期保留在队列中的最坏情况界限。
源码解析
通过上面的原理简介其实已经把LinkedTransferQueue的原理说的很清楚了，接下来看源码会容易的多，首先看看其基础字段属性和节点内部类Node：
//是否是多处理器
private static final boolean MP = Runtime.getRuntime().availableProcessors() > 1; //第一个等待入队节点在阻塞之前在多处理器上自旋的次数
private static final int FRONT_SPINS = 1 << 7; //当一个节点前面已经有一个明显在自旋的节点时，在阻塞之前自旋的次数。该值是第一个自旋节点自旋次数的一半。
private static final int CHAINED_SPINS = FRONT_SPINS >>> 1; //在必须清理队列之前要容忍的最大估计清理失败次数阀值(sweepvote)，该值必须至少为2，以避免在删除尾节点时进行无用的清理。
static final int SWEEP_THRESHOLD = 32; /** 队列的head，第一个节点入队之前该值为null */
transient volatile Node head; /** 队列的tail，第一个节点入队之前该值为null */
private transient volatile Node tail; /** 清理已删除节点失败的次数 */
private transient volatile int sweepVotes; // 字段的CAS方法 --- tail
private boolean casTail(Node cmp, Node val) {
return UNSAFE.compareAndSwapObject(this, tailOffset, cmp, val);
} // 字段的CAS方法 --- head
private boolean casHead(Node cmp, Node val) {
return UNSAFE.compareAndSwapObject(this, headOffset, cmp, val);
} // 字段的CAS方法 --- sweepVotes
private boolean casSweepVotes(int cmp, int val) {
return UNSAFE.compareAndSwapInt(this, sweepVotesOffset, cmp, val);
} /*
* xfer方法中“how”参数的可能值。
*/
private static final int NOW = 0; // 非定时的poll和tryTransfer
private static final int ASYNC = 1; // 对offer, put, add方法使用
private static final int SYNC = 2; // 对transfer, take方法使用
private static final int TIMED = 3; // 定时版本的poll和tryTransfer @SuppressWarnings("unchecked")
static <E> E cast(Object item) { //数据类型转换方法
// assert item == null || item.getClass() != Node.class;
return (E) item;
} //创建初始为空的LinkedTransferQueue。
public LinkedTransferQueue() {
}
//创建一个最初包含给定集合元素的LinkedTransferQueue，按集合迭代器的遍历顺序添加。
public LinkedTransferQueue(Collection<? extends E> c) {
this();
addAll(c);
} //队列的节点类，允许在使用之后忘记节点数据item，
static final class Node {
final boolean isData; // 如果这是一个请求节点，则为false
volatile Object item; // 如果是数据节点item不为空，通过CAS进行交换该数据
volatile Node next; // 下一个节点引用
volatile Thread waiter; // 阻塞等待的线程 // 对字段next进行更新的CAS方法
final boolean casNext(Node cmp, Node val) {
return UNSAFE.compareAndSwapObject(this, nextOffset, cmp, val);
} // 对节点数据item进行更新的CAS方法
final boolean casItem(Object cmp, Object val) {
// assert cmp == null || cmp.getClass() != Node.class;
return UNSAFE.compareAndSwapObject(this, itemOffset, cmp, val);
} /**
* 构造一个新节点。使用普通写而不是volatile写，因为只有在通过CAS执行了casNext将其加入到队列中之后才需要被可见，而casNext本身就会顺带着完成item的可见性。
*/
Node(Object item, boolean isData) {
UNSAFE.putObject(this, itemOffset, item);
this.isData = isData;
} /**
* 将next指向自身以避免垃圾存留，因为只会在casHead之后调用，所以这里也使用普通写。
*/
final void forgetNext() {
UNSAFE.putObject(this, nextOffset, this);
} /**
* 将item指向自身，将waiter置为null，以避免在匹配和取消之后的对引用的持有（垃圾存留）。
* 使用普通写，因为有序性已经在其调用的上下文中得到保证：只有在volatile/atomic的item操作之后才会调用该方法，
* 同样，清理waiter要么在CAS操作之后，要么从阻塞唤醒之后（如果没有阻塞过，则没有任何影响）。
*/
final void forgetContents() {
UNSAFE.putObject(this, itemOffset, this);
UNSAFE.putObject(this, waiterOffset, null);
} /**
* 如果该节点已经被匹配则返回true，包括由于取消而导致的伪造匹配。
*/
final boolean isMatched() {
Object x = item;
return (x == this) || ((x == null) == isData);
} /**
* 如果这是一个未匹配的请求节点，则返回true。
*/
final boolean isUnmatchedRequest() {
return !isData && item == null;
} /**
* 如果无法将一个给定模式的节点链接到该节点，则返回true，因为该节点未被匹配，并且具有与其相反的节点模式。
*/
final boolean cannotPrecede(boolean haveData) {
boolean d = isData;
Object x;
//模式相反 && 未取消 && 未匹配
return d != haveData && (x = item) != this && (x != null) == d;
} /**
* 尝试人为匹配一个数据节点(由remove使用)
*/
final boolean tryMatchData() {
// assert isData;
Object x = item;
//是数据节点 && 未匹配和取消，清空数据
if (x != null && x != this && casItem(x, null)) {
LockSupport.unpark(waiter); //唤醒等待线程
return true;
}
return false;
} private static final long serialVersionUID = -3375979862319811754L; // Unsafe mechanics
private static final sun.misc.Unsafe UNSAFE;
private static final long itemOffset;
private static final long nextOffset;
private static final long waiterOffset;
static {
try {
UNSAFE = sun.misc.Unsafe.getUnsafe();
Class<?> k = Node.class;
itemOffset = UNSAFE.objectFieldOffset
(k.getDeclaredField("item"));
nextOffset = UNSAFE.objectFieldOffset
(k.getDeclaredField("next"));
waiterOffset = UNSAFE.objectFieldOffset
(k.getDeclaredField("waiter"));
} catch (Exception e) {
throw new Error(e);
}
}
}
通过构造方法可见LinkedTransferQueue是无界队列，Node节点的字段isData、item、next、waiter与SynchronousQueue的公平模式下的节点字段一样。其它都很简单就不一一说明。
入队操作
LinkedTransferQueue提供了add、put、offer以及超时版本的offer三类方法，用于将元素插入队列中：
//将指定的元素插入到此队列的末尾。因为队列是无界的，所以这个方法永远不会阻塞。
public void put(E e) {
xfer(e, true, ASYNC, 0);
}
//超时版本的offer
public boolean offer(E e, long timeout, TimeUnit unit) {
xfer(e, true, ASYNC, 0);
return true;
}
//将指定的元素插入到此队列的末尾。由于队列是无界的，这个方法永远不会返回false。
public boolean offer(E e) {
xfer(e, true, ASYNC, 0);
return true;
}
//将指定的元素插入到此队列的末尾。由于队列是无界的，这个方法永远不会抛出IllegalStateException或返回false。
public boolean add(E e) {
xfer(e, true, ASYNC, 0);
return true;
}
LinkedTransferQueue的入队方法都是通过xfer(e, true, ASYNC, 0)实现，所以add、put、offer、超时offer这几个方法完全可以看作一个方法，它们没有任何区别，由于LinkedTransferQueue是无界的，不会阻塞，所以在调用xfer方法是传入的是ASYNC(异步)，同时直接返回true.
出队操作
LinkedTransferQueue提供了take、poll以及超时版本的poll方法用于出列元素：
public E take() throws InterruptedException {
E e = xfer(null, false, SYNC, 0);
if (e != null)
return e;
Thread.interrupted();
throw new InterruptedException();
}
//超时版本的poll
public E poll(long timeout, TimeUnit unit) throws InterruptedException {
E e = xfer(null, false, TIMED, unit.toNanos(timeout));
if (e != null || !Thread.interrupted())
return e;
throw new InterruptedException();
}
public E poll() {
return xfer(null, false, NOW, 0);
}
take是阻塞方法，必须拿到一个元素才返回所以传入 xfer的"how"参数为SYNC（同步），方法poll传入的NOW所以不论如何都会立即返回，毕竟它的定义是直接拿走队列的头部有效元素，如果没有就算了，超时版本的poll传入的TIMED.
数据传输操作
LinkedTransferQueue实现了TransferQueue的数据传递方法：
//传输指定的数据元素给一个消费者，阻塞直到成功。
//更精确地说，如果已经有消费者在等待接收指定的元素(通过take或超时版本的poll方法)，则立即传输指定的元素，否则将指定的元素插入队列的末尾，并阻塞等待直到有消费者接收到该元素。
public void transfer(E e) throws InterruptedException {
if (xfer(e, true, SYNC, 0) != null) {
Thread.interrupted(); // failure possible only due to interrupt
throw new InterruptedException();
}
} //如果可能，立即将指定的数据元素传递给一个正在等待的消费者。
//更精确地说，如果已经有消费者在等待接收指定的元素(通过take或超时版本的poll方法)，则立即传输指定的元素，否则返回false，而不需要将元素加入队列。
public boolean tryTransfer(E e) {
return xfer(e, true, NOW, 0) == null;
} //如果可能在超时之前将元素传输给使用者，则将该元素传输给使用者。
//更准确地说,如果已经有消费者在等待接收指定的元素(通过take或超时版本的poll方法)，则立即传输指定的元素，否则将指定的元素插入队列的末尾并阻塞等待直到有消费者接收到该元素。如果在指定的超时时间到底之后依然没有被消费者接收则立即返回false
public boolean tryTransfer(E e, long timeout, TimeUnit unit)
throws InterruptedException {
if (xfer(e, true, TIMED, unit.toNanos(timeout)) == null)
return true;
if (!Thread.interrupted())
return false;
throw new InterruptedException();
}
transfer是一个方法阻塞方法，所以传入 xfer的"how"参数为SYNC（同步），方法tryTransfer传入的NOW所以不论如何都会立即返回，超时版本的tryTransfer传入的TIMED.
核心方法1：E xfer（E e, boolean haveData, int how, long nanos）
通过上面几个核心方法的源码我们可以清楚的看到，最终都是调用xfer()方法，该方法接受四个参数，数据item或者是null的数据E，put操作为true、take操作为false的havaData，how（有四个值NOW, ASYNC, SYNC, or TIMED，分别表示不同的操作），超时纳秒数nanos。
/**
* 实现所有队列方法。见上面的解释。
*
* @param e 入队数据或null（执行take时）
* @param haveData true表示put操作，否则表示take操作
* @param how NOW, ASYNC, SYNC, or TIMED
* @param nanos 超时纳秒数，仅仅用于超时模式
* @return 返回匹配的数据item，否则返回参数e
* @throws NullPointerException 如果是put操作但是e为null则抛出空指针异常
*/
private E xfer(E e, boolean haveData, int how, long nanos) {
if (haveData && (e == null))
throw new NullPointerException();
Node s = null; // the node to append, if needed retry:
for (;;) { // restart on append race //从head开始找一个未匹配的互补节点尝试进行匹配交换数据
for (Node h = head, p = h; p != null;) { // find & match first node
boolean isData = p.isData;
Object item = p.item;
// p节点未被匹配，并且节点模式合符规定
if (item != p && (item != null) == isData) {
// 当前节点与待处理数据模式相同，不能匹配，重新开始
if (isData == haveData)
break;
// 到这里说明当前节点与待处理数据模式互补，故进行匹配即交换数据
if (p.casItem(item, e)) {
for (Node q = p; q != h;) {
Node n = q.next; // update by 2 unless singleton
//维护head与第一个未匹配节点之间的阈值不超过1
//如果当前节点已经是最后一个节点了则head指向该节点，否则指向该节点的下一个节点
if (head == h && casHead(h, n == null ? q : n)) {
h.forgetNext(); //让原head的next指向自身，形成自链接
break;
}
//如果head已经变化，或者更新head失败，则重新查看head与第一个未匹配节点的距离
//注意这里通过 q = h.next改变了q的指向
if ((h = head) == null ||
(q = h.next) == null || !q.isMatched())
break; // if条件成立说明head距离第一个未匹配节点没有超过1，所以不需要更新head
} //匹配完成之后唤醒被阻塞在当前节点的线程，返回节点数据
LockSupport.unpark(p.waiter);
return LinkedTransferQueue.<E>cast(item);
}
}
//如果当前节点已经被匹配或者匹配失败则继续看下一个节点
//如果当前节点已经出队了，则从head重新开始
Node n = p.next;
p = (p != n) ? n : (h = head); // Use head if p offlist
}
//到这里说明没有找到可以匹配的节点
//how不为NOW（put，offer，add，take、超时poll，transfer，超时tryTransfer），说明需要入队
if (how != NOW) { // No matches available
if (s == null)
s = new Node(e, haveData); //创建节点实例
Node pred = tryAppend(s, haveData); //尝试加入队尾，返回其前驱节点
if (pred == null) //前驱为null，说明有与其互补的未匹配节点入队
continue retry; // 这个时候需要重新尝试匹配（万一刚刚有模式互补的节点入队呢）
if (how != ASYNC) //how 不是异步即是同步或者超时等待（take，超时poll，transfer，超时tryTransfer），说明需要阻塞等待
return awaitMatch(s, pred, e, (how == TIMED), nanos);
}
return e; //不需要等待直接返回数据e（put，offer，超时offer，add入队之后返回；poll，tryTransfer不入队返回）
}
xfer方法的核心算法就是寻找互补未匹配节点进行匹配，匹配成功就唤醒对应节点的线程然后返回，匹配失败就考虑是不是需要入队，以及需不需要阻塞等待的问题，具体逻辑如下：
- 从head开始依次往后尝试找到一个与当前操作互补的未匹配节点进行匹配。匹配成功之后在返回之前有两件事需要考虑做：①维护松弛阀值即保证head与第一个未匹配节点之间的距离不超过1一个节点；②唤醒阻塞在匹配节点的线程。
- 如果步骤1没有找到可以匹配的节点，就看要不要将当前操作（生产者或消费者）构造新节点入队等待，如果how是"NOW"（poll，tryTransfer）则不需要入队所以立即返回数据e；
- 否则若步骤2判断需要入队（put，offer，add，take、超时poll，transfer，超时tryTransfer），则构造新节点通过tryAppend方法入队。
- 步骤3三入队完成之后再看需不需要等待，如果how不是“ASYNC” （take，超时poll，transfer，超时tryTransfer）则需要阻塞等待，否则入队完成之后就可以立即返回e了（put，offer，超时版本offer，add）。
从xfer方法可以看出，①所有入队操作都不会被阻塞，但在入队之前会尝试从队列头部开始往后找与其互补的未匹配节点进行匹配交换数据，如果成功了就不需要入队从而立即返回，否则需要入队链接到队尾，当然在入队过程中如果有互补节点入队导致入队失败，也会继续尝试匹配，否则入队成功或继续尝试匹配还是失败之后则立即返回。②take、超时poll、transfer，超时tryTransfer需要入队并阻塞等待。③poll，tryTransfer这种非阻塞方法不需要入队，不论步骤1成功失败都将立即返回。
核心方法2：Node tryAppend(Node s, boolean haveData)
从上面的xfer方法实现可以看到在需要入队节点的时候需要执行另一个核心方法tryAppend，s表示当前需要入队的节点本身，haveData指示当前节点的模式。
/**
* 尝试将节点s追加为尾部。
* 返回值：
* 1. 队列为空，刚刚入队的s是队列中唯一的节点，返回s本身
* 2. 队列不为空，成功将s链接到最后一个节点p之后，返回s的前驱p
* 3. 队列不为空，但是队列中存在与其互补的未匹配节点，返回null
*/
private Node tryAppend(Node s, boolean haveData) {
for (Node t = tail, p = t;;) { // move p to last node and append
Node n, u; // temps for reads of next & tail
//队列为空，则直接将s设置成head，返回s本身
if (p == null && (p = head) == null) {
if (casHead(null, s))
return s; // initialize
}
//当前节点p是一个模式互补且未被匹配的节点则不能链接到该节点之后
//因为它完全可以和节点s完成匹配使它们都返回
else if (p.cannotPrecede(haveData))
return null;
//当前节点p不是实际的最后一个节点，继续循环寻找最后一个节点
else if ((n = p.next) != null)
p = p != t && t != (u = tail) ? (t = u) : // tail被更新了则取新的tail
(p != n) ? n : null; // 取p的下一个节点或者若p已经失效重新从head开始
//p是最后一个节点，将s链接到它的下一个节点
//如果被其它线程抢先入队则p指向其next继续循环
else if (!p.casNext(null, s))
p = p.next;
else {
//到这里说明成功将s链接到p的next，根据需要维护尾节点的松弛阀值不超过1
if (p != t) { // update if slack now >= 2
while ((tail != t || !casTail(t, s)) && //tail还没被更新则更新指向新的尾节点s
(t = tail) != null &&
(s = t.next) != null && // advance and retry
(s = s.next) != null && s != t);
}
return p; //返回s的前驱
}
}
}
tryAppend的逻辑很简单，主要就是从tail开始寻找最后一个模式相同的节点，然后将其链接到它的next。在遍历过程中：
- 如果队列为空，则直接将节点s设置成head，返回s本身。
- 如果发现一个与s模式互补的未匹配节点则返回null，在xfer中将会继续尝试匹配。
- 如果遍历到的当前节点不是队列的最后一个节点（tail可以不指向最后一个节点），则将遍历指针指向下一个节点（如果发现tail被更新了就重新从tail出开始遍历）。
- 否则p是最后一个节点，尝试将s链接到它的next，如果失败则将遍历指针指向p的next继续遍历。成功则根据需要维护tail节点的松弛阀值，使其距离队列最后一个节点的距离不超过一个节点。最后返回s的前驱节点p。
tryAppend的返回值有以下几种情况：
- 队列为空，刚刚入队的s是队列中唯一的节点，返回s本身
- 队列不为空，成功将s链接到最后一个节点p之后，返回s的前驱p
- 队列不为空，但是队列中存在与其互补的未匹配节点，返回null
核心方法3：E awaitMatch(Node s, Node pred, E e, boolean timed, long nanos)
/**
* 自旋/出让CPU/阻塞，直到节点s被匹配或调用者放弃。
* 返回匹配的数据，或者e如果在中断或超时发生时依然还没有匹配成功
*/
private E awaitMatch(Node s, Node pred, E e, boolean timed, long nanos) {
final long deadline = timed ? System.nanoTime() + nanos : 0L;
Thread w = Thread.currentThread();
int spins = -1; // initialized after first item and cancel checks
ThreadLocalRandom randomYields = null; // bound if needed for (;;) {
Object item = s.item;
//数据已经发生变化说明已经被匹配了
if (item != e) { // matched
// assert item != s;
s.forgetContents(); // 消除垃圾存留
return LinkedTransferQueue.<E>cast(item); //返回被匹配的数据项
}
//如果发生了中断或超时，则取消节点，即将数据item指向自身，返回e
if ((w.isInterrupted() || (timed && nanos <= 0)) &&
s.casItem(e, s)) { // cancel
unsplice(pred, s); //断开s节点的链接
return e;
} //到这里说明节点没有发生异常，要进行阻塞
//先获取阻塞前的自旋次数，以及随机出让CPU的随机数实例
//关于自旋次数：
if (spins < 0) {
if ((spins = spinsFor(pred, s.isData)) > 0)
randomYields = ThreadLocalRandom.current();
}
//自旋，过程中随机出让CPU
else if (spins > 0) { // spin
--spins;
if (randomYields.nextInt(CHAINED_SPINS) == 0)
Thread.yield(); // occasionally yield
}
//自旋结束，做阻塞前准备，将线程设置到waiter
else if (s.waiter == null) {
s.waiter = w; // request unpark then recheck
}
//已经做好了阻塞准备，根据不同情况分别做无限期阻塞或者定时阻塞
else if (timed) {
nanos = deadline - System.nanoTime();
if (nanos > 0L)
LockSupport.parkNanos(this, nanos); 定时阻塞
}
else {
LockSupport.park(this); 无限期阻塞
}
}
} //返回具有给定前驱节点和数据模式的节点s的自旋次数
private static int spinsFor(Node pred, boolean haveData) {
if (MP && pred != null) { //是多处理器才需要自旋
//这种情况什么时候发生，说明什么？我确实没有搞懂
if (pred.isData != haveData)
return FRONT_SPINS + CHAINED_SPINS;
// 前驱已经被匹配了，即当前节点是第一个自旋节点，自旋次数为FRONT_SPINS
if (pred.isMatched())
return FRONT_SPINS;
// 前驱也处于自旋状态，则自旋次数为其一半
if (pred.waiter == null)
return CHAINED_SPINS;
}
return 0; //单核CPU不需要自旋，自旋次数为0
}
在xfer中节点入队之后，如果how不是ASYNC则需要入队等待，即执行awaitMatch方法，该方法的逻辑很简单，主要分三个阶段：
- 第一阶段：进行状态检测，是否已经被匹配，是否已经被中断、超时，已经被匹配则说明匹配之后被对方唤醒所以直接返回匹配的数据即可，中断或超时则返回自身e；
- 第二阶段：若第一阶段的情况未发生，则根据情况进行不同的自旋次数，在自旋过程中随机出让CPU, 自旋完成过程中若第一阶段的情况依然没有发生，则准备阻塞（将当前线程引用赋值给节点的waiter字段）；
- 第三阶段：第二阶段完成之后，根据不同的情况做无限期阻塞或定时阻塞，等待唤醒或超时自动醒来。
在awaitMatch的第一阶段中，若发生了超时或中断，在返回之前还需要断开该节点的链接，即unsplice方法：
/**
* 断开已经取消或删除的节点s与其前驱节点的链接
*
* @param pred a node that was at one time known to be the
* predecessor of s, or null or s itself if s is/was at head
* @param s the node to be unspliced
*/
final void unsplice(Node pred, Node s) {
s.forgetContents(); // 防止垃圾引用持有
/*
* 1. 如果前驱依然指向s，尝试断开与s的链接。
* 2. 如果操作失败（由于s是尾节点或者前驱已经断开了），并且前驱和s都不是head也没有出队，则积累失败次数
* 3. 当失败次数累计到临界值就进行清理
*/
if (pred != null && pred != s && pred.next == s) {//前驱的依然next指向s
Node n = s.next;
//s是尾节点 或者 （为何pred.casNext(s, n)成功了还要执行下面这些逻辑？？？）前驱已经被匹配
if (n == null ||
(n != s && pred.casNext(s, n) && pred.isMatched())) {
// 看是否是head或将要成为新的head，根据需要更新head指向第一个未匹配节点
for (;;) {
Node h = head;
if (h == pred || h == s || h == null)
return; // 是头节点或者队列为空，直接返回
if (!h.isMatched()) //head未被匹配，则不需对head进行处理
break;
Node hn = h.next;
if (hn == null)
return; // 队列为空，返回
if (hn != h && casHead(h, hn)) //使head指向第一个未匹配节点
h.forgetNext();
}
//重新检查节点是否已经出队，若没有对失败次数进行累计，
//当失败次数达到临界值SWEEP_THRESHOLD，执行sweep进行清理
//sweep就是从head开始遍历清除队列中那些已经匹配过的节点
if (pred.next != pred && s.next != s) { for (;;) {
int v = sweepVotes;
if (v < SWEEP_THRESHOLD) {
if (casSweepVotes(v, v + 1))
break;
}
else if (casSweepVotes(v, 0)) {
sweep();
break;
}
}
}
}
}
}
说实话，unsplice中的第二个if条件没有看明白，n == null 表示s是尾节点，作为下次入队节点的前驱，所以不能断开s的链接这个可以理解，后面的条件n != s && pred.casNext(s, n) && pred.isMatched() 就没有看懂了，为什么pred.casNext(s, n) 成功将s与其前驱的节点断开了还要执行里面的逻辑？？？不过if块里面的逻辑很简单：for (;;) 维护head使其在必要是被更新指向第一个未匹配节点；对断开链接的失败次数进行累计，当达到临界值SWEEP_THRESHOLD，执行sweep进行对整个队列的无效节点进行清理。
内部节点移除方法：boolean remove(Object o)
//从此队列中删除指定元素的单个实例(如果存在)。
public boolean remove(Object o) {
return findAndRemove(o);
} private boolean findAndRemove(Object e) {
if (e != null) {
for (Node pred = null, p = head; p != null; ) {
Object item = p.item;
//如果是数据节点
if (p.isData) {
//与数据节点进行数据比较，找到之后进行人为的伪匹配，
//并唤醒对应的阻塞线程，然后尝试断开节点与其前驱的链接，返回true
if (item != null && item != p && e.equals(item) &&
p.tryMatchData()) {
unsplice(pred, p);
return true;
}
}
//第一个节点若不是数据节点，则表示队列中都是请求节点。直接返回false
else if (item == null)
break;
//到这里说明队列中是数据节点，但是当前遍历节点数据不是目标数据
//更新遍历指针到下一个节点，或者从head重新开始遍历（当前节点已经失效）
pred = p;
if ((p = p.next) == pred) { // stale
pred = null;
p = head;
}
}
}
return false;
}
内部节点移除方法，就是找到队列中第一个数据item与其相等（item.equals(o)）的节点并移除，通过源码可见移除是通过伪匹配实现的，即伪造成被请求线程匹配，然后唤醒对应的阻塞线程，尝试断开该节点与其前驱的链接。
boolean hasWaitingConsumer()方法
//是否存在等待的消费者
public boolean hasWaitingConsumer() {
return firstOfMode(false) != null;
} //返回队列中第一个未匹配的指定模式的节点
private Node firstOfMode(boolean isData) {
for (Node p = head; p != null; p = succ(p)) {
if (!p.isMatched()) //未匹配
return (p.isData == isData) ? p : null;//模式相同则返回节点，否则返回null
}
return null;
}
如果队列中存在至少一个未匹配的数据请求节点则返回true，否则返回false。
getWaitingConsumerCount() 和size()方法
//返回队列中未匹配的数据节点个数
public int size() {
return countOfMode(true);
}
//返回队列中未匹配的请求节点个数
public int getWaitingConsumerCount() {
return countOfMode(false);
} //返回队列中指定模式的未匹配节点的个数
private int countOfMode(boolean data) {
int count = 0;
for (Node p = head; p != null; ) {
if (!p.isMatched()) {//未匹配的节点
//第一个节点模式相反就表示没有该模式的节点
if (p.isData != data)
return 0;
//否则计数器加1，直到增大到Integer.MAX_VALUE为止
if (++count == Integer.MAX_VALUE) // saturated
break;
}
//更新遍历指针
Node n = p.next;
if (n != p)
p = n; //p的next
else { //p已经无效了，从head重新开始数
count = 0;
p = head;
}
}
return count;
}
getWaitingConsumerCount方法返回队列中未匹配的请求节点的个数，size与其相反，返回的是队列中未匹配的数据节点的个数，如果超过了Integer.MAX_VALUE个，就返回Integer.MAX_VALUE；size只是一个瞬时值，因为队列随时都在异步变化。
另外一些方法：
peek()方法返回的是队列中的第一个未匹配的数据节点的数据；isEmpty() 方法判断的是队列中是否存在未匹配的数据节点；remainingCapacity()返回的总是Integer.MAX_VALUE，因为队列的无界的；drainTo方法转移所有或最多多少个的队列中的数据元素到指定的集合中，该集合不能是当前队列本身；contains(o)查看队列中是否存在数据item与其相等的数据节点，不论是否已经被匹配；
不能保证批量操作addAll、removeAll、retainAll、containsAll、equals和toArray是原子执行的。例如，与addAll操作并发操作的迭代器可能只能查看到部分添加的元素。
迭代器
LinkedTransferQueue的迭代器与ConcurrentLinkedQueue结构类似，但是比ConcurrentLinkedQueue的实现要复杂的多，但是都是在创建迭代器实例的时候就已经拿到了第一个节点以及节点数据，每一次执行next的时候又准备好下一次迭代的返回对象，但是LinkedTransferQueue在迭代的过程中会对队列中的无效节点进行清理，由于LinkedTransferQueue队列是双队列，既可以存放数据节点，也可以存放请求节点，但同一时刻，队列中只能是一种节点，其迭代器只会对数据节点进行遍历，由于LinkedTransferQueue对节点的清理比起ConcurrentLinkedQueue来说要复杂的多，ConcurrentLinkedQueue只需要将节点数据item清空即可，但是LinkedTransferQueue则需要通过其前驱节点来对节点进行清理，所以其迭代器还需要对前驱节点lastPred
进行维护，以用于调用迭代器的remove方法使用。LinkedTransferQueue的迭代器的remove方法会进行伪匹配，唤醒对应的阻塞线程，并执行unsplice对节点进行清理。其代码有点复杂难懂，就不贴源码咯。
可拆分迭代器Spliterator
LinkedTransferQueue实现了自己的可拆分迭代器内部类LTQSpliterator，但是其可拆分迭代器与ConcurrentLinkedQueue的实现几乎一致，只不过它只对队列中的item有效的数据节点进行处理，tryAdvance获取队列中第一个item有效的数据节点的数据做指定的操作，forEachRemaining循环遍历当前队列中item有效的数据节点的数据做指定的操作源码都很简单，就不贴代码了，至于它的拆分方法trySplit，其实和ConcurrentLinkedQueue拆分方式是一样的，代码都几乎一致，它不是像ArrayBlockingQueue那样每次分一半，而是第一次只拆一个元素，第二次拆2个，第三次拆三个，依次内推，拆分的次数越多，拆分出的新迭代器分的得元素越多，直到一个很大的数MAX_BATCH（33554432） ，后面的迭代器每次都分到这么多的元素，拆分的实现逻辑很简单，每一次拆分结束都记录下拆分到哪个元素，下一次拆分从上次结束的位置继续往下拆分，直到没有元素可拆分了返回null。
总结
LinkedTransferQueue是Java同步包队列（非双端队列）中最强大的队列，它是一种双队列，即节点存在数据节点，请求节点这种互补模式，这两种模式代表可以完成数据交换，但大多时候其实现的集合方法在没有特别强调的情况下都是对有效数据节点的数据进行处理而非请求节点，因为请求节点携带的数据为null，它同时满足了ConcurrentLinkedQueue那样的非阻塞（CAS）实现的无界链表队列实现，它的所有入队方法包括带有超时时间的offer都是相同的实现，所以调用任意一个都是相同的效果，最主要的是它还实现了类似SynchronousQueue那样的数据传递的阻塞方法，通常来说无界队列的入队方法都是非阻塞的，因为无容量限制，只要内存足够就可以无限制的往里面加入元素，它无法确定丢进去的数据是否/什么时候被消费掉的，但LinkedTransferQueue实现类似SynchronousQueue的功能即TransferQueue接口特有的transfer/超时tryTransfer方法提供了这种特性，它是一个阻塞入队方法，直到入队数据被消费或超时才返回，另外还能对正在等待消费线程的个数进行估计，它可以说是ConcurrentLinkedQueue + SynchronousQueue的综合体，其代码实现所以也相对的复杂的多，但一般来说不需要这种传输特性的时候使用ConcurrentLinkedQueue 完全足以，虽然据说LinkedTransferQueue的性能要比ConcurrentLinkedQueue 好很多，但我没有去去验证。使用的时候就按照这个优先顺序吧：LinkedTransferQueue/ConcurrentLinkedQueue -> LinkedBlockingQueues -> ArrayBlockingQueue.
最新文章
- 玩转Redis之Window安装使用(干货)
- 关于已配置log4j，运行tomcat时显示警告的分析
- ASP.NET MVC ModelValidator小结
- SaltStack安装篇
- MySQL分库分表总结参考
- autofac 学习记录
- 《c和指针》1.5编程练习问题
- css盒子模型，定位，浮动
- Nlpir Parser灵玖文本语义挖掘系统数据采集
- Windows环境下JDK的下载与安装
- 修改maven项目jdk版本,并解决Dynamic Web Module 3.1 requires Java 1.7 or newer错误
- ProgressBar的简单使用
- idea新建maven工程没有artifacts
- 代码文档生成工具Doxygen的使用备忘
- [转]WEB页获取串口数据
- HandlerSocket介绍
- day 26 网络通讯流程 初识socke
- Android JNI学习(三)——Java与Native相互调用
- 768. Max Chunks To Make Sorted II
- Node.js之Express四