Java并发编程-原子操作

摘要：这个规则比较好理解，无论是在单线程环境还是多线程环境，一个锁处于被锁定状态，那么必须先执行操作后面才能进行操作。线程启动规则独享的方法先行于此线程的每一个动作。

关于指令重排序的概念，比较复杂，不好理解。我们从一个例子分析：

public class SimpleHappenBefore {

    /** 这是一个验证结果的变量 */
    private static int a=0;

    /** 这是一个标志位 */
    private static boolean flag=false;

    public static void main(String[] args) throws InterruptedException {

        //由于多线程情况下未必会试出重排序的结论,所以多试一些次
        for(int i = 0; i < 1000; i++){

            ThreadA threadA=new ThreadA();
            ThreadB threadB=new ThreadB();

            threadA.start();
            threadB.start();

            //这里等待线程结束后,重置共享变量,以使验证结果的工作变得简单些.
            threadA.join();
            threadB.join();

            a = 0;
            flag = false;
        }
    }

    static class ThreadA extends Thread{
        public void run(){
            a = 1;
            flag = true;
        }
    }

    static class ThreadB extends Thread{
        public void run(){
            if(flag){
                a = a * 1;
            }

            if(a == 0){
                System.out.println("ha,a==0");
            }
        }
    }
}

一个简单的展示Happen-Before的例子.
这里有两个共享变量:a和flag,初始值分别为0和false.在ThreadA中先给a=1,然后flag=true.

如果按照有序的话,那么在ThreadB中如果if(flag)成功的话,则应该a=1,而a=a*1之后a仍然为1,下方的if(a==0)应该永远不会为真,永远不会打印.

但实际情况是:在试验100次的情况下会出现0次或几次的打印结果,而试验1000次结果更明显,有十几次打印.

在虚拟机层面，为了尽可能减少内存操作速度远慢于CPU运行速度所带来的CPU空置的影响，虚拟机会按照自己的一些规则(这规则后面再叙述)将程序编写顺序打乱——即写在后面的代码在时间顺序上可能会先执行，而写在前面的代码会后执行——以尽可能充分地利用CPU。
拿上面的例子来说：假如不是a=1的操作，而是a=new byte[1024*1024](分配1M空间)，那么它会运行地很慢，此时CPU是等待其执行结束呢，还是先执行下面那句flag=true呢？显然，先执行flag=true可以提前使用CPU，加快整体效率，当然这样的前提是不会产生错误(什么样的错误后面再说)。虽然这里有两种情况：后面的代码先于前面的代码开始执行；前面的代码先开始执行，但当效率较慢的时候，后面的代码开始执行并先于前面的代码执行结束。不管谁先开始，总之后面的代码在一些情况下存在先结束的可能。

不管怎么重排序，单线程程序的执行结果不能被改变。编译器、运行时和处理器都必须遵守“as-if-serial”语义。拿个简单例子来说，

public void execute(){
    int a = 0;
    int b = 1;
    int c = a+b;
}

这里a=0,b=1两句可以随便排序，不影响程序逻辑结果，但c=a+b这句必须在前两句的后面执行。

在JMM中，如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在happens-before关系。

happens-before原则非常重要，它是判断数据是否存在竞争、线程是否安全的主要依据，依靠这个原则，我们解决在并发环境下两操作之间是否可能存在冲突的所有问题。
happens-before原则定义如下：

如果一个操作happens-before另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前。

两个操作之间存在happens-before关系，并不意味着一定要按照happens-before原则制定的顺序来执行。如果重排序之后的执行结果与按照happens-before关系来执行的结果一致，那么这种重排序并不非法。

重排序在多线程环境下出现的概率还是挺高的，在关键字上有volatile和synchronized可以禁用重排序，除此之外还有一些规则，也正是这些规则，使得我们在平时的编程工作中没有感受到重排序的坏处。

程序次序规则(Program Order Rule)：在一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作。准确地说应该是控制流顺序而不是代码顺序，因为要考虑分支、循环等结构。
一段代码在单线程中执行的结果是有序的。注意是执行结果，因为虚拟机、处理器会对指令进行重排序（重排序后面会详细介绍）。虽然重排序了，但是并不会影响程序的执行结果，所以程序最终执行的结果与顺序执行的结果是一致的。故而这个规则只对单线程有效，在多线程环境下无法保证正确性。

监视器锁定规则(Monitor Lock Rule)：一个unlock操作先行发生于后面对同一个对象锁的lock操作。这里强调的是同一个锁，而“后面”指的是时间上的先后顺序，如发生在其他线程中的lock操作。
这个规则比较好理解，无论是在单线程环境还是多线程环境，一个锁处于被锁定状态，那么必须先执行unlock操作后面才能进行lock操作。

volatile变量规则(Volatile Variable Rule):对一个volatile变量的写操作发生于后面对这个变量的读操作，这里的“后面”也指的是时间上的先后顺序。
这是一条比较重要的规则，它标志着volatile保证了线程可见性。通俗点讲就是如果一个线程先去写一个volatile变量，然后一个线程去读这个变量，那么这个写操作一定是happens-before读操作的。

线程启动规则(Thread Start Rule)：Thread独享的start()方法先行于此线程的每一个动作。
假定线程A在执行过程中，通过执行ThreadB.start()来启动线程B，那么线程A对共享变量的修改在接下来线程B开始执行后确保对线程B可见。

线程终止规则(Thread Termination Rule)：线程中的每个操作都先行发生于对此线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值检测到线程已经终止执行。

线程中断规则(Thread Interruption Rule)：对线程interrupte()方法的调用优先于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测线程是否已中断。

对象终结原则(Finalizer Rule)：一个对象的初始化完成(构造函数执行结束)先行发生于它的finalize()方法的开始。
假定线程A在执行的过程中，通过制定ThreadB.join()等待线程B终止，那么线程B在终止之前对共享变量的修改在线程A等待返回后可见。

传递性(Transitivity)：如果操作A先行发生于操作B，操作B先行发生于操作C，那就可以得出操作A先行发生于操作C的结论。
体现了happens-before原则具有传递性

如果不符合以上规则，那么在多线程环境下就不能保证执行顺序等同于代码顺序，也就是“如果在本线程中观察，所有的操作都是有序的；如果在一个线程中观察另外一个线程，则不符合以上规则的都是无序的”，因此，如果我们的多线程程序依赖于代码书写顺序，那么就要考虑是否符合以上规则，如果不符合就要通过一些机制使其符合，最常用的就是synchronized、Lock以及volatile修饰符。

上面八条是原生Java满足Happens-before关系的规则，但是我们可以对他们进行推导出其他满足happens-before的规则：

将一个元素放入一个线程安全的队列的操作Happens-Before从队列中取出这个元素的操作

将一个元素放入一个线程安全容器的操作Happens-Before从容器中取出这个元素的操作

在CountDownLatch上的倒数操作Happens-Before CountDownLatch#await()操作

释放Semaphore许可的操作Happens-Before获得许可操作

Future表示的任务的所有操作Happens-Before Future#get()操作

向Executor提交一个Runnable或Callable的操作Happens-Before任务开始执行操作

happen-before原则是JMM中非常重要的原则，它是判断数据是否存在竞争、线程是否安全的主要依据，保证了多线程环境下的可见性。

volatile相当于synchronized的弱实现，类似于synchronized的语义，但是没有锁机制。在JDK及开源框架随处可见，但是在JDK6之后synchronized关键字性能被大幅优化之后，几乎没有使用了场景。

第一条语义：JMM不会对volatile指令的操作进行重排序。这个保证了对volatile变量的操作时按照指令的出现顺序执行的。

第二条语义是保证线程间变量的可见性，简单地说就是当线程A对变量X进行了修改后，在线程A后面执行的其他线程能看到变量X的变动，更详细地说是要符合以下两个规则：

线程对变量进行修改之后，要立刻回写到主内存。

线程对变量读取的时候，要从主内存中读，而不是缓存。

虽然volatile字段保证了可见性，但是由于缺少同步机制，所以volatile的字段的操作不是原子性的，并不能保证线程安全。

volatile是在synchronized性能低下的时候提出的。如今synchronized的效率已经大幅提升，所以volatile存在的意义不大。

如今非volatile的共享变量，在访问不是超级频繁的情况下，已经和volatile修饰的变量有同样的效果了。

volatile不能保证原子性，这点是大家没太搞清楚的，所以很容易出错。

volatile可以禁止重排序

通常应用场景如下：

volatile boolean done = flase;
//...

while(!done){
   // ...
}

在多线程竞争下，加锁、释放锁会导致比较多的上下文切换和调度延时，引起性能问题。

一个线程持有锁会导致其它所有需要此锁的线程挂起。

如果一个优先级高的线程等待一个优先级低的线程释放锁会导致优先级倒置，引起性能风险。

独占锁是一种悲观锁，synchronized就是一种独占锁，会导致其它所有需要锁的线程挂起，等待持有锁的线程释放锁。而另一个更加有效的锁就是乐观锁。所谓乐观锁就是，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。

CAS 操作包含三个操作数——内存位置（V）、预期原值（A）和新值(B)。如果内存位置的值与预期原值相匹配，那么处理器会自动将该位置值更新为新值。否则，处理器不做任何操作。无论哪种情况，它都会在 CAS 指令之前返回该位置的值。（在 CAS 的一些特殊情况下将仅返回 CAS 是否成功，而不提取当前值。）CAS 有效地说明了“我认为位置 V 应该包含值 A；如果包含该值，则将 B 放到这个位置；否则，不要更改该位置，只告诉我这个位置现在的值即可。”

通常将 CAS 用于同步的方式是从地址 V 读取值 A，执行多步计算来获得新值 B，然后使用 CAS 将 V 的值从 A 改为 B。如果 V 处的值尚未同时更改，则 CAS 操作成功。

CAS其底层是通过CPU的1条指令来完成3个步骤，因此其本身是一个原子性操作，不存在其执行某一个步骤的时候而被中断的可能。

从性能角度考虑：
如果使用锁来进行并发控制，当某一个线程(T1)抢占到锁之后，那么其他线程再尝试去抢占锁时就会被挂起，当T1释放锁之后，下一个线程(T2)再抢占到锁后并且重新恢复到原来的状态大约需要经过8W个时钟周期。

假设我们业务代码本身并不具备很复杂的操作，执行整个操作可能就花费3-10个时钟周期左右，那么当我们使用无锁操作时，线程T1和线程T2对共享变量进行并发的CAS操作，假设T1成功了，T2最多再执行一次，它执行多次的所消耗的时间远远小于由于线程所挂起到恢复所消耗的时间，因此无锁的CAS操作在性能上要比同步锁高很多。

示例代码：

public class SimulatedCAS {
     private int value;
 
     public synchronized int getValue() { return value; }
 
    public synchronized int compareAndSwap(int expectedValue, int newValue) {
         int oldValue = value;
         if (value == expectedValue)
             value = newValue;
         return oldValue;
     }
}

非阻塞算法:一个线程的失败或者挂起不应该影响其他线程的失败或挂起的算法。

基于CAS的并发算法称为非阻塞算法，CAS 操作成功还是失败，在任何一种情况中，它都在可预知的时间内完成。如果 CAS 失败，调用者可以重试 CAS 操作或采取其他适合的操作。下面显示了重新编写的计数器类来使用 CAS 替代锁定：

public class CasCounter {
    private SimulatedCAS value;
    public int getValue() {
        return value.getValue();
    }
    public int increment() {
        int oldValue = value.getValue();
        while (value.compareAndSwap(oldValue, oldValue + 1) != oldValue)
            oldValue = value.getValue();
        return oldValue + 1;
    }
}

无论是直接的还是间接的，几乎 java.util.concurrent 包中的所有类都使用原子变量，而不使用同步。类似 ConcurrentLinkedQueue 的类也使用原子变量直接实现无等待算法，而类似 ConcurrentHashMap 的类使用 ReentrantLock 在需要时进行锁定。然后， ReentrantLock 使用原子变量来维护等待锁定的线程队列。

CAS策略有如下需要注意的事项：

在线程抢占资源特别频繁的时候(相对于CPU执行效率而言)，会造成长时间的自旋，耗费CPU性能。

有ABA问题(即在更新前的值是A，但在操作过程中被其他线程更新为B，又更新为A)，这时当前线程认为是可以执行的，其实是发生了不一致现象，如果这种不一致对程序有影响(真正有这种影响的场景很少，除非是在变量操作过程中以此变量为标识位做一些其他的事，比如初始化配置)，则需要使用AtomicStampedReference(除了对更新前的原值进行比较，也需要用更新前的stamp标志位来进行比较)。

只能对一个变量进行原子性操作。如果需要把多个变量作为一个整体来做原子性操作，则应该使用AtomicReference来把这些变量放在一个对象里，针对这个对象做原子性操作。

java的多线程机制引用

【死磕Java并发】-----Java内存模型之happens-before

深入浅出 Java Concurrency (4): 原子操作 part 3 指令重排序与happens-before法则

流行的原子