非阻塞算法

时间 2019-11-11

标签阻塞算法繁體版

原文原文链接

原文地址做者：Jakob Jenkov 译者：张坤html

在并发上下文中，非阻塞算法是一种容许线程在阻塞其余线程的状况下访问共享状态的算法。在绝大多数项目中，在算法中若是一个线程的挂起没有致使其它的线程挂起，咱们就说这个算法是非阻塞的。java

为了更好的理解阻塞算法和非阻塞算法之间的区别，我会先讲解阻塞算法而后再讲解非阻塞算法。算法

阻塞并发算法

一个阻塞并发算法通常分下面两步：缓存

执行线程请求的操做
阻塞线程直到能够安全地执行操做

不少算法和并发数据结构都是阻塞的。例如，java.util.concurrent.BlockingQueue的不一样实现都是阻塞数据结构。若是一个线程要往一个阻塞队列中插入一个元素，队列中没有足够的空间，执行插入操做的线程就会阻塞直到队列中有了能够存放插入元素的空间。安全

下图演示了一个阻塞算法保证一个共享数据结构的行为：数据结构

非阻塞并发算法

一个非阻塞并发算法通常包含下面两步：多线程

执行线程请求的操做
通知请求线程操做不能被执行

Java也包含几个非阻塞数据结构。AtomicBoolean,AtomicInteger,AtomicLong,AtomicReference都是非阻塞数据结构的例子。并发

下图演示了一个非阻塞算法保证一个共享数据结构的行为：ide

非阻塞算法 vs 阻塞算法

阻塞算法和非阻塞算法的主要不一样在于上面两部分描述的它们的行为的第二步。换句话说，它们之间的不一样在于当请求操做不可以执行时阻塞算法和非阻塞算法会怎么作。性能

阻塞算法会阻塞线程知道请求操做能够被执行。非阻塞算法会通知请求线程操做不可以被执行，并返回。

一个使用了阻塞算法的线程可能会阻塞直到有可能去处理请求。一般，其它线程的动做使第一个线程执行请求的动做成为了可能。若是，因为某些缘由线程被阻塞在程序某处，所以不能让第一个线程的请求动做被执行，第一个线程会阻塞——可能一直阻塞或者直到其余线程执行完必要的动做。

例如，若是一个线程产生往一个已经满了的阻塞队列里插入一个元素，这个线程就会阻塞，直到其余线程从这个阻塞队列中取走了一些元素。若是因为某些缘由，从阻塞队列中取元素的线程假定被阻塞在了程序的某处，那么，尝试往阻塞队列中添加新元素的线程就会阻塞，要么一直阻塞下去，要么知道从阻塞队列中取元素的线程最终从阻塞队列中取走了一个元素。

非阻塞并发数据结构

在一个多线程系统中，线程间一般经过一些数据结构”交流“。例如能够是任何的数据结构，从变量到更高级的俄数据结构（队列，栈等）。为了确保正确，并发线程在访问这些数据结构的时候，这些数据结构必须由一些并发算法来保证。这些并发算法让这些数据结构成为并发数据结构。

若是某个算法确保一个并发数据结构是阻塞的，它就被称为是一个阻塞算法。这个数据结构也被称为是一个阻塞，并发数据结构。

若是某个算法确保一个并发数据结构是非阻塞的，它就被称为是一个非阻塞算法。这个数据结构也被称为是一个非阻塞，并发数据结构。

每一个并发数据结构被设计用来支持一个特定的通讯方法。使用哪一种并发数据结构取决于你的通讯须要。在接下里的部分，我会引入一些非阻塞并发数据结构，并讲解它们各自的适用场景。经过这些并发数据结构工做原理的讲解应该能在非阻塞数据结构的设计和实现上一些启发。

Volatile 变量

Java中的volatile变量是直接从主存中读取值的变量。当一个新的值赋给一个volatile变量时，这个值老是会被当即写回到主存中去。这样就确保了，一个volatile变量最新的值老是对跑在其余CPU上的线程可见。其余线程每次会从主存中读取变量的值，而不是好比线程所运行CPU的CPU缓存中。

colatile变量是非阻塞的。修改一个volatile变量的值是一耳光原子操做。它不可以被中断。不过，在一个volatile变量上的一个 read-update-write 顺序的操做不是原子的。所以，下面的代码若是由多个线程执行可能致使竞态条件。

volatile myVar = 0;
...
int temp = myVar;
temp++;
myVar = temp;

首先，myVar这个volatile变量的值被从主存中读出来赋给了temp变量。而后，temp变量自增1。而后，temp变量的值又赋给了myVar这个volatile变量这意味着它会被写回到主存中。

若是两个线程执行这段代码，而后它们都读取myVar的值，加1后，把它的值写回到主存。这样就存在myVar仅被加1，而没有被加2的风险。

你可能认为你不会写像上面这样的代码，可是在实践中上面的代码等同于以下的代码：

myVar++;

执行上面的代码时，myVar的值读到一个CPU寄存器或者一个本地CPU缓存中，myVar加1，而后这个CPU寄存器或者CPU缓存中的值被写回到主存中。

单个写线程的情景

在一些场景下，你仅有一个线程在向一个共享变量写，多个线程在读这个变量。当仅有一个线程在更新一个变量，无论有多少个线程在读这个变量，都不会发生竞态条件。所以，不管时候当仅有一个线程在写一个共享变量时，你能够把这个变量声明为volatile。

当多个线程在一个共享变量上执行一个 read-update-write 的顺序操做时才会发生竞态条件。若是你只有一个线程在执行一个 raed-update-write 的顺序操做，其余线程都在执行读操做，将不会发生竞态条件。

下面是一个单个写线程的例子，它没有采起同步手段但任然是并发的。

public class SingleWriterCounter{
    private volatile long count = 0;

    /**
     *Only one thread may ever call this method
     *or it will lead to race conditions
     */
     public void inc(){
         this.count++;
     }

     /**
      *Many reading threads may call this method
      *@return
      */
      public long count(){
          return this.count;
      }
}

多个线程访问同一个Counter实例，只要仅有一个线程调用inc()方法，这里，我不是说在某一时刻一个线程，个人意思是，仅有相同的，单个的线程被容许去调用inc()>方法。多个线程能够调用count()方法。这样的场景将不会发生任何竞态条件。

下图，说明了线程是如何访问count这个volatile变量的。

基于volatile变量更高级的数据结构

使用多个volatile变量去建立数据结构是能够的，构建出的数据结构中每个volatile变量仅被一个单个的线程写，被多个线程读。每一个volatile变量可能被一个不一样的线程写（但仅有一个）。使用像这样的数据结构多个线程可使用这些volatile变量以一个非阻塞的方法彼此发送信息。

下面是一个简单的例子：

public class DoubleWriterCounter{
    private volatile long countA = 0;
    private volatile long countB = 0;

    /**
     *Only one (and the same from thereon) thread may ever call this method,
     *or it will lead to race conditions.
     */
     public void incA(){
         this.countA++;
     }

     /**
      *Only one (and the same from thereon) thread may ever call this method, 
      *or it will  lead to race conditions.
      */
      public void incB(){
          this.countB++;
      }

      /**
       *Many reading threads may call this method
       */
      public long countA(){
          return this.countA;
      }

     /**
      *Many reading threads may call this method
      */
      public long countB(){
          return this.countB;
      }
}

如你所见，DoubleWriterCoounter如今包含两个volatile变量以及两对自增和读方法。在某一时刻，仅有一个单个的线程能够调用inc()，仅有一个单个的线程能够访问incB()。不过不一样的线程能够同时调用incA()和incB()。countA()和countB()能够被多个线程调用。这将不会引起竞态条件。

DoubleWriterCoounter能够被用来好比线程间通讯。countA和countB能够分别用来存储生产的任务数和消费的任务数。下图，展现了两个线程经过相似于上面的一个数据结构进行通讯的。

聪明的读者应该已经意识到使用两个SingleWriterCounter能够达到使用DoubleWriterCoounter的效果。若是须要，你甚至可使用多个线程和SingleWriterCounter实例。

使用CAS的乐观锁

变量是不合适的。你将会须要一些类型的排它锁（悲观锁）访问这个变量。下面代码演示了使用Java中的同步块进行排他访问的。若是你确实须要多个线程区写同一个共享变量，volatile

public class SynchronizedCounter{
    long count = 0;

    public void inc(){
        synchronized(this){
            count++;
        }
    }

    public long count(){
        synchronized(this){
            return this.count;
        }
    }
}

注意，，inc()和count()方法都包含一个同步块。这也是咱们像避免的东西——同步块和 wait()-notify 调用等。

咱们可使用一种Java的原子变量来代替这两个同步块。在这个例子是AtomicLong。下面是SynchronizedCounter类的AtomicLong实现版本。

import java.util.concurrent.atomic.AtomicLong;

public class AtomicLong{
    private AtomicLong count = new AtomicLong(0);

    public void inc(){
        boolean updated = false;
        while(!updated){
            long prevCount = this.count.get();
            updated = this.count.compareAndSet(prevCount, prevCount + 1);
        }
    }

    public long count(){
        return this.count.get();
    }
}

方法的实现。方法中再也不含有一个同步块。而是被下面这些代码替代：这个版本仅仅是上一个版本的线程安全版本。这一版咱们感兴趣的是inc()inc()

boolean updated = false;
while(!updated){
    long prevCount = this.count.get();
    updated = this.count.compareAndSet(prevCount, prevCount + 1);
}

上面这些代码并非一个原子操做。也就是说，对于两个不一样的线程去调用inc()方法，而后执行long prevCount = this.count.get()语句，所以得到了这个计数器的上一个count。可是，上面的代码并无包含任何的竞态条件。

秘密就在于while循环里的第二行代码。compareAndSet()方法调用是一个原子操做。它用一个指望值和AtomicLong 内部的值去比较，若是这两个值相等，就把AtomicLong内部值替换为一个新值。compareAndSet()一般被CPU中的compare-and-swap指令直接支持。所以，不须要去同步，也不须要去挂起线程。

假设，这个AtomicLong的内部值是20,。而后，两个线程去读这个值，都尝试调用compareAndSet(20, 20 + 1)。尽管compareAndSet()是一个原子操做，这个方法也会被这两个线程相继执行（某一个时刻只有一个）。

第一个线程会使用指望值20（这个计数器的上一个值）与AtomicLong的内部值进行比较。因为两个值是相等的，AtomicLong会更新它的内部值至21（20 + 1 ）。变量updated被修改成true，while循环结束。

如今，第二个线程调用compareAndSet(20, 20 + 1)。因为AtomicLong的内部值再也不是20，这个调用将不会成功。AtomicLong的值不会再被修改成21。变量，updated被修改成false，线程将会再次在while循环外自旋。这段时间，它会读到值21并企图把值更新为22。若是在此期间没有其它线程调用inc()。第二次迭代将会成功更新AtomicLong的内部值到22。

为何称它为乐观锁

上一部分展示的代码被称为乐观锁（optimistic locking）。乐观锁区别于传统的锁，有时也被称为悲观锁。传统的锁会使用同步块或其余类型的锁阻塞对临界区域的访问。一个同步块或锁可能会致使线程挂起。

乐观锁容许全部的线程在不发生阻塞的状况下建立一份共享内存的拷贝。这些线程接下来可能会对它们的拷贝进行修改，并企图把它们修改后的版本写回到共享内存中。若是没有其它线程对共享内存作任何修改， CAS操做就容许线程将它的变化写回到共享内存中去。若是，另外一个线程已经修改了共享内存，这个线程将不得再也不次得到一个新的拷贝，在新的拷贝上作出修改，并尝试再次把它们写回到共享内存中去。

称之为“乐观锁”的缘由就是，线程得到它们想修改的数据的拷贝并作出修改，在乐观的假在此期间没有线程对共享内存作出修改的状况下。当这个乐观假设成立时，这个线程仅仅在无锁的状况下完成共享内存的更新。当这个假设不成立时，线程所作的工做就会被丢弃，但任然不使用锁。

乐观锁使用于共享内存竞用不是很是高的状况。若是共享内存上的内容很是多，仅仅由于更新共享内存失败，就用浪费大量的CPU周期用在拷贝和修改上。可是，若是砸共享内存上有大量的内容，不管如何，你都要把你的代码设计的产生的争用更低。

乐观锁是非阻塞的

咱们这里提到的乐观锁机制是非阻塞的。若是一个线程得到了一份共享内存的拷贝，当尝试修改时，发生了阻塞，其它线程去访问这块内存区域不会发生阻塞。

对于一个传统的加锁/解锁模式，当一个线程持有一个锁时，其它全部的线程都会一直阻塞直到持有锁的线程再次释放掉这个锁。若是持有锁的这个线程被阻塞在某处，这个锁将很长一段时间不能被释放，甚至可能一直不能被释放。

不可替换的数据结构

简单的CAS乐观锁能够用于共享数据结果，这样一来，整个数据结构均可以经过一个单个的CAS操做被替换成为一个新的数据结构。尽管，使用一个修改后的拷贝来替换真个数据结构并不老是可行的。

假设，这个共享数据结构是队列。每当线程尝试从向队列中插入或从队列中取出元素时，都必须拷贝这个队列而后在拷贝上作出指望的修改。咱们能够经过使用一个AtomicReference来达到一样的目的。拷贝引用，拷贝和修改队列，尝试替换在AtomicReference中的引用让它指向新建立的队列。

然而，一个大的数据结构可能会须要大量的内存和CPU周期来复制。这会使你的程序占用大量的内存和浪费大量的时间再拷贝操做上。这将会下降你的程序的性能，特别是这个数据结构的竞用很是高状况下。更进一步说，一个线程花费在拷贝和修改这个数据结构上的时间越长，其它线程在此期间修改这个数据结构的可能性就越大。如你所知，若是另外一个线程修改了这个数据结构在它被拷贝后，其它全部的线程都不等再也不次执行拷贝-修改操做。这将会增大性能影响和内存浪费，甚至更多。

接下来的部分将会讲解一种实现非阻塞数据结构的方法，这种数据结构能够被并发修改，而不只仅是拷贝和修改。

共享预期的修改

用来替换拷贝和修改整个数据结构，一个线程能够共享它们对共享数据结构预期的修改。一个线程向对修改某个数据结构的过程变成了下面这样：

检查是否另外一个线程已经提交了对这个数据结构提交了修改
若是没有其余线程提交了一个预期的修改，建立一个预期的修改，而后向这个数据结构提交预期的修改
执行对共享数据结构的修改
移除对这个预期的修改的引用，向其它线程发送信号，告诉它们这个预期的修改已经被执行

如你所见，第二步能够阻塞其余线程提交一个预期的修改。所以，第二步实际的工做是做为这个数据结构的一个锁。若是一个线程已经成功提交了一个预期的修改，其余线程就不能够再提交一个预期的修改直到第一个预期的修改执行完毕。

若是一个线程提交了一个预期的修改，而后作一些其它的工做时发生阻塞，这时候，这个共享数据结构其实是被锁住的。其它线程能够检测到它们不可以提交一个预期的修改，而后回去作一些其它的事情。很明显，咱们须要解决这个问题。

可完成的预期修改

为了不一个已经提交的预期修改能够锁住共享数据结构，一个已经提交的预期修改必须包含足够的信息让其余线程来完成此次修改。所以，若是一个提交了预期修改的线程从未完成此次修改，其余线程能够在它的支持下完成此次修改，保证这个共享数据结构对其余线程可用。

下图说明了上面描述的非阻塞算法的蓝图：

修改必须被当作一个或多个CAS操做来执行。所以，若是两个线程尝试去完成同一个预期修改，仅有一个线程能够全部的CAS操做。一旦一条CAS操做完成后，再次企图完成这个CAS操做都不会“得逞”。

A-B-A问题

上面演示的算法能够称之为A-B-A问题。A-B-A问题指的是一个变量被从A修改到了B，而后又被修改回A的一种情景。其余线程对于这种状况却一无所知。

若是线程A检查正在进行的数据更新，拷贝，被线程调度器挂起，一个线程B在此期可能能够访问这个共享数据结构。若是线程对这个数据结构执行了所有的更新，移除了它的预期修改，这样看起来，好像线程A自从拷贝了这个数据结构以来没有对它作任何的修改。然而，一个修改确实已经发生了。当线程A继续基于如今已通过期的数据拷贝执行它的更新时，这个数据修改已经被线程B的修改破坏。

下图说明了上面提到的A-B-A问题：

A-B-A问题的解决方案

A-B-A一般的解决方法就是再也不仅仅替换指向一个预期修改对象的指针，而是指针结合一个计数器，而后使用一个单个的CAS操做来替换指针 + 计数器。这在支持指针的语言像C和C++中是可行的。所以，尽管当前修改指针被设置回指向 “不是正在进行的修改”（no ongoing modification），指针 + 计数器的计数器部分将会被自增，使修改对其它线程是可见的。

在Java中，你不能将一个引用和一个计数器归并在一块儿造成一个单个的变量。不过Java提供了AtomicStampedReference类，利用这个类可使用一个CAS操做自动的替换一个引用和一个标记（stamp）。

一个非阻塞算法模板

下面的代码意在在如何实现非阻塞算法上一些启发。这个模板基于这篇教程所讲的东西。

注意：在非阻塞算法方面，我并非一位专家，因此，下面的模板可能错误。不要基于我提供的模板实现本身的非阻塞算法。这个模板意在给你一个关于非阻塞算法大体是什么样子的一个idea。若是，你想实现本身的非阻塞算法，首先学习一些实际的工业水平的非阻塞算法的时间，在实践中学习更多关于非阻塞算法实现的知识。

import java.util.concurrent.atomic.AtomicBoolean;
import java.util.concurrent.atomic.AtomicStampedReference;

public class NonblockingTemplate{
    public static class IntendedModification{
        public AtomicBoolean completed = new AtomicBoolean(false);
    }

    private AtomicStampedReference<IntendedModification> ongoinMod = new AtomicStampedReference<IntendedModification>(null, 0);
    //declare the state of the data structure here.

    public void modify(){
        while(!attemptModifyASR());
    }


    public boolean attemptModifyASR(){
        boolean modified = false;

        IntendedMOdification currentlyOngoingMod = ongoingMod.getReference();
        int stamp = ongoingMod.getStamp();

        if(currentlyOngoingMod == null){
            //copy data structure - for use
            //in intended modification

            //prepare intended modification
            IntendedModification newMod = new IntendModification();

            boolean modSubmitted = ongoingMod.compareAndSet(null, newMod, stamp, stamp + 1);

            if(modSubmitted){
                 //complete modification via a series of compare-and-swap operations.
                //note: other threads may assist in completing the compare-and-swap
                // operations, so some CAS may fail
                modified = true;
            }
        }else{
             //attempt to complete ongoing modification, so the data structure is freed up
            //to allow access from this thread.
            modified = false;
        }

        return modified;
    }
}

非阻塞算法是不容易实现的

正确的设计和实现非阻塞算法是不容易的。在尝试设计你的非阻塞算法以前，看一看是否已经有人设计了一种非阻塞算法正知足你的需求。

Java已经提供了一些非阻塞实现（好比 ConcurrentLinkedQueue），相信在Java将来的版本中会带来更多的非阻塞算法的实现。

除了Java内置非阻塞数据结构还有不少开源的非阻塞数据结构可使用。例如，LAMX Disrupter和Cliff Click实现的非阻塞 HashMap。查看个人Java concurrency references page查看更多的资源。

使用非阻塞算法的好处

非阻塞算法和阻塞算法相比有几个好处。下面让咱们分别看一下：

选择

非阻塞算法的第一个好处是，给了线程一个选择当它们请求的动做不可以被执行时作些什么。再也不是被阻塞在那，请求线程关于作什么有了一个选择。有时候，一个线程什么也不能作。在这种状况下，它能够选择阻塞或自我等待，像这样把CPU的使用权让给其它的任务。不过至少给了请求线程一个选择的机会。

在一个单个的CPU系统可能会挂起一个不能执行请求动做的线程，这样可让其它线程得到CPU的使用权。不过即便在一个单个的CPU系统阻塞可能致使死锁，线程饥饿等并发问题。

没有死锁

非阻塞算法的第二个好处是，一个线程的挂起不能致使其它线程挂起。这也意味着不会发生死锁。两个线程不能互相彼此等待来得到被对方持有的锁。由于线程不会阻塞当它们不能执行它们的请求动做时，它们不能阻塞互相等待。非阻塞算法任然可能产生活锁（live lock），两个线程一直请求一些动做，但一直被告知不可以被执行（由于其余线程的动做）。

没有线程挂起

挂起和恢复一个线程的代价是昂贵的。没错，随着时间的推移，操做系统和线程库已经愈来愈高效，线程挂起和恢复的成本也不断下降。不过，线程的挂起和户对任然须要付出很高的代价。

不管何时，一个线程阻塞，就会被挂起。所以，引发了线程挂起和恢复过载。因为使用非阻塞算法线程不会被挂起，这种过载就不会发生。这就意味着CPU有可能花更多时间在执行实际的业务逻辑上而不是上下文切换。

在一个多个CPU的系统上，阻塞算法会对阻塞算法产生重要的影响。运行在CPUA上的一个线程阻塞等待运行在CPU B上的一个线程。这就下降了程序天生就具有的并行水平。固然，CPU A能够调度其余线程去运行，可是挂起和激活线程（上下文切换）的代价是昂贵的。须要挂起的线程越少越好。

下降线程延迟

在这里咱们提到的延迟指的是一个请求产生到线程实际的执行它之间的时间。由于在非阻塞算法中线程不会被挂起，它们就不须要付昂贵的，缓慢的线程激活成本。这就意味着当一个请求执行时能够获得更快的响应，减小它们的响应延迟。

非阻塞算法一般忙等待直到请求动做能够被执行来下降延迟。固然，在一个非阻塞数据数据结构有着很高的线程争用的系统中，CPU可能在它们忙等待期间中止消耗大量的CPU周期。这一点须要紧紧记住。非阻塞算法可能不是最好的选择若是你的数据结构哦有着很高的线程争用。不过，也经常存在经过重构你的程序来达到更低的线程争用。