JAVA线程安全队列（二）

         下面再来说说ConcurrentLinkedQueue，它是一个无锁的并发线程安全的队列。 

         对比锁机制的实现，使用无锁机制的难点在于要充分考虑线程间的协调。简单的说就是多个线程对内部数据结构进行访问时，如果其中一个线程执行的中途因为一些原因出现故障，其他的线程能够检测并帮助完成剩下的操作。这就需要把对数据结构的操作过程精细的划分成多个状态或阶段，考虑每个阶段或状态多线程访问会出现的情况。
          ConcurrentLinkedQueue有两个volatile的线程共享变量：head，tail。要保证这个队列的线程安全就是保证对这两个Node的引用的访问（更新，查看）的原子性和可见性，由于volatile本身能够保证可见性，所以就是对其修改的原子性要被保证。

         下面通过offer方法的实现来看看在无锁情况下如何保证原子性： 

public boolean offer(E e) {
    if (e == null)throw new NullPointerException();
    Node n = new Node(e, null);
    for (;;) {
        Node t = tail;
        Node s = t.getNext();
        if (t == tail) { //------------------------------a
            if (s == null) {//---------------------------b
                if (t.casNext(s, n)) { //-------------------c
                    casTail(t, n); //------------------------d
                    return true;
                }
            } else {
                casTail(t, s); //----------------------------e
            }
        }
    }
}

         此方法的循环内首先获得尾指针和其next指向的对象，由于tail和Node的next均是volatile的，所以保证了获得的分别都是最新的值。 
         代码a：t==tail是最上层的协调，如果其他线程改变了tail的引用，则说明现在获得不是最新的尾指针需要重新循环获得最新的值。 
         代码b：s==null的判断。静止状态下tail的next一定是指向null的，但是多线程下的另一个状态就是中间态：tail的指向没有改变，但是其next已经指向新的结点，即完成tail引用改变前的状态，这时候s!=null。这里就是协调的典型应用，直接进入代码e去协调参与中间态的线程去完成最后的更新，然后重新循环获得新的tail开始自己的新一次的入队尝试。另外值得注意的是a,b之间，其他的线程可能会改变tail的指向，使得协调的操作失败。从这个步骤可以看到无锁实现的复杂性。
        代码c：t.casNext(s, n)是入队的第一步，因为入队需要两步：更新Node的next，改变tail的指向。代码c之前可能发生tail引用指向的改变或者进入更新的中间态，这两种情况均会使得t指向的元素的next属性被原子的改变，不再指向null。这时代码c操作失败，重新进入循环。
        代码d：这是完成更新的最后一步了，就是更新tail的指向，最有意思的协调在这儿又有了体现。从代码看casTail(t, n)不管是否成功都会接着返回true标志着更新的成功。首先如果成功则表明本线程完成了两步的更新，返回true是理所当然的；如果 casTail(t, n)不成功呢？要清楚的是完成代码c则代表着更新进入了中间态，代码d不成功则是tail的指向被其他线程改变。意味着对于其他的线程而言：它们得到的是中间态的更新，s!=null，进入代码e帮助本线程执行最后一步并且先于本线程成功。这样本线程虽然代码d失败了，但是是由于别的线程的协助先完成了，所以返回true也就理所当然了。
        通过分析这个入队的操作，可以清晰的看到无锁实现的每个步骤和状态下多线程之间的协调和工作。 
注：上面这大段文字看起来很累，先能看懂多少看懂多少，现在看不懂先不急，下面还会提到这个算法，并且用示意图说明，就易懂很多了。 

        在使用ConcurrentLinkedQueue时要注意，如果直接使用它提供的函数，比如add或者poll方法，这样我们自己不需要做任何同步。 
        但如果是非原子操作，比如： 

        Java代码 

1. if(!queue.isEmpty()) {
2.       queue.poll(obj);
3. }
   

        我们很难保证，在调用了isEmpty()之后，poll()之前，这个queue没有被其他线程修改。所以对于这种情况，我们还是需要自己同步： 

        Java代码 

1. synchronized(queue) {
2.    if(!queue.isEmpty()) {
3.         queue.poll(obj);
4.   }
5. }
   

        注：这种需要进行自己同步的情况要视情况而定，不是任何情况下都需要这样做。
        另外还说一下，ConcurrentLinkedQueue的size()是要遍历一遍集合的，所以尽量要避免用size而改用isEmpty()，以免性能过慢。 
        最后总结一下，阻塞算法其实很好理解，简单点理解就是加锁，比如在BlockingQueue中看到的那样，再往前推点，那就是synchronized。相比而言，非阻塞算法的设计和实现都很困难，要通过低级的原子性来支持并发。下面就简要的介绍一下非阻塞算法，以下部分的内容参照了一篇很经典的文章http://www.ibm.com/developerworks/cn/java/j-jtp04186/         

        注：我觉得可以这样理解，阻塞对应同步，非阻塞对应并发。也可以说：同步是阻塞模式，异步是非阻塞模式 

        举个例子来说明什么是非阻塞算法：非阻塞的计数器 
        首先，使用同步的线程安全的计数器代码如下 

Java代码 

1. public finalclass Counter {
2. private long value =0;
3. public synchronizedlong getValue() {
4.        return value;
5. }
6. public synchronizedlong increment() {
7.       return ++value;
8. }
9. }
   

         下面的代码显示了一种最简单的非阻塞算法：使用 AtomicInteger的compareAndSet()（CAS方法）的计数器。compareAndSet()方法规定“将这个变量更新为新值，但是如果从我上次看到这个变量之后其他线程修改了它的值，那么更新就失败”

Java代码 

1. public class NonblockingCounter {
2. private AtomicInteger value;//前面提到过，AtomicInteger类是以原子的方式操作整型变量。
3. public int getValue() {
4.        return value.get();
5. }
6. public int increment() {
7.      int v;
8.      do {
9.          v = value.get();
10.          while (!value.compareAndSet(v, v +1));
11.          return v + 1;
12.       }
13. }
    

         非阻塞版本相对于基于锁的版本有几个性能优势。首先，它用硬件的原生形态代替 JVM 的锁定代码路径，从而在更细的粒度层次上（独立的内存位置）进行同步，失败的线程也可以立即重试，而不会被挂起后重新调度。更细的粒度降低了争用的机会，不用重新调度就能重试的能力也降低了争用的成本。即使有少量失败的 CAS 操作，这种方法仍然会比由于锁争用造成的重新调度快得多。
         NonblockingCounter 这个示例可能简单了些，但是它演示了所有非阻塞算法的一个基本特征——有些算法步骤的执行是要冒险的，因为知道如果 CAS 不成功可能不得不重做。非阻塞算法通常叫作乐观算法，因为它们继续操作的假设是不会有干扰。如果发现干扰，就会回退并重试。在计数器的示例中，冒险的步骤是递增——它检索旧值并在旧值上加一，希望在计算更新期间值不会变化。如果它的希望落空，就会再次检索值，并重做递增计算。

          再来一个例子，Michael-Scott 非阻塞队列算法的插入操作，ConcurrentLinkedQueue 就是用这个算法实现的，现在来结合示意图分析一下，很明朗：

Java代码 

public class LinkedQueue  {
    private staticclass Node  {
        final E item;
        final AtomicReference> next;
        Node(E item, Node next) {
        this.item = item;
            this.next = new AtomicReference>(next);
        }
    }
    private AtomicReference> head= new AtomicReference>(new Node(null,null));
    private AtomicReference> tail = head;
    public boolean put(E item) {
        Node newNode = new Node(item,null);
        while (true) {
            Node curTail = tail.get();
            Node residue = curTail.next.get();
            if (curTail == tail.get()) {
                if (residue == null)/* A */ {
                    if (curTail.next.compareAndSet(null, newNode))/* C */ {
                        tail.compareAndSet(curTail, newNode) /* D */ ;
                        return true;
                    }
                } else {
                    tail.compareAndSet(curTail, residue) /* B */;
                }
            }
        }
    }
}

        这代码完全就是ConcurrentLinkedQueue 源码。 
        插入一个元素涉及头指针和尾指针两个指针更新，这两个更新都是通过 CAS 进行的：从队列当前的最后节点（C）链接到新节点，并把尾指针移动到新的最后一个节点（D）。如果第一步失败，那么队列的状态不变，插入线程会继续重试，直到成功。一旦操作成功，插入被当成生效，其他线程就可以看到修改。还需要把尾指针移动到新节点的位置上，但是这项工作可以看成是 “清理工作”，因为任何处在这种情况下的线程都可以判断出是否需要这种清理，也知道如何进行清理。
        队列总是处于两种状态之一：正常状态（或称静止状态，图 1 和 图 3）或中间状态（图 2）。在插入操作之前和第二个 CAS（D）成功之后，队列处在静止状态；在第一个 CAS（C）成功之后，队列处在中间状态。在静止状态时，尾指针指向的链接节点的 next 字段总为 null，而在中间状态时，这个字段为非 null。任何线程通过比较 tail.next 是否为 null，就可以判断出队列的状态，这是让线程可以帮助其他线程 “完成” 操作的关键。

上图显示的是：有两个元素，处在静止状态的队列 

插入操作在插入新元素（A）之前，先检查队列是否处在中间状态。如果是在中间状态，那么肯定有其他线程已经处在元素插入的中途，在步骤（C）和（D）之间。不必等候其他线程完成，当前线程就可以 “帮助” 它完成操作，把尾指针向前移动（B）。如果有必要，它还会继续检查尾指针并向前移动指针，直到队列处于静止状态，这时它就可以开始自己的插入了。
第一个 CAS（C）可能因为两个线程竞争访问队列当前的最后一个元素而失败；在这种情况下，没有发生修改，失去 CAS 的线程会重新装入尾指针并再次尝试。如果第二个 CAS（D）失败，插入线程不需要重试 —— 因为其他线程已经在步骤（B）中替它完成了这个操作！

 
上图显示的是：处在插入中间状态的队列，在新元素插入之后，尾指针更新之前 

上图显示的是：在尾指针更新后，队列重新处在静止状态