Java内存模型及volatile

工作后时间紧张，但是还是要不忘学习。本片主要记录了java内存模型和并发编程中的三个特性：原子性，可见性，有序性，然后分别从这三个方面了解了volatile这个关键字的用法及注意的地方。

目录

java内存区域划分

JAVA内存模型

并发编程的三个概念

原子性

可见性

有序性

JMM提供的解决方案

happens-before 原则

volatile关键字

内存屏障 Memory Barrier

volatile保证可见性吗？

volatile保证原子性吗？

volatile保证有序性吗？

volatiile的实现原理

volatile的使用

总结

---

java内存区域划分

Java虚拟机在运行程序时会把其自动管理的内存划分为：共享内存【方法区和堆】和私有内存【虚拟机栈／本地方法栈／程序计数器】。

java内存模型

方法区（Method Area）：

方法区属于线程共享的内存区域，又称Non-Heap（非堆），主要用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据，根据Java 虚拟机规范的规定，当方法区无法满足内存分配需求时，将抛出OutOfMemoryError 异常。值得注意的是在方法区中存在一个叫运行时常量池(Runtime Constant Pool）的区域，它主要用于存放编译器生成的各种字面量和符号引用，这些内容将在类加载后存放到运行时常量池中，以便后续使用。

JVM堆（Java Heap）：

Java 堆也是属于线程共享的内存区域，它在虚拟机启动时创建，是Java 虚拟机所管理的内存中最大的一块，主要用于存放对象实例，几乎所有的对象实例都在这里分配内存，注意Java 堆是垃圾收集器管理的主要区域，因此很多时候也被称做GC 堆，如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError 异常。

程序计数器(Program Counter Register)：

属于线程私有的数据区域，是一小块内存空间，主要代表当前线程所执行的字节码行号指示器。字节码解释器工作时，通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。

虽然JVM中的程序计数器并不像汇编语言中的程序计数器一样是物理概念上的CPU寄存器，但是JVM中的程序计数器的功能跟汇编语言中的程序计数器的功能在逻辑上是等同的，也就是说是用来指示 执行哪条指令的。

虚拟机栈(Java Virtual Machine Stacks)：

属于线程私有的数据区域，与线程同时创建，总数与线程关联，代表Java方法执行的内存模型。每个方法执行时都会创建一个栈桢来存储方法的的变量表、操作数栈、动态链接方法、返回值、返回地址等信息。具体栈帧如下：

 

栈帧

本地方法栈(Native Method Stacks)：

本地方法栈属于线程私有的数据区域，这部分主要与虚拟机用到的 Native 方法相关，一般情况下，我们无需关心此区域。

这里之所以简要说明这部分内容，注意是为了区别Java内存模型与Java内存区域的划分，毕竟这两种划分是属于不同层次的概念。

JAVA内存模型

       Java内存模型(即Java Memory Model，简称JMM)本身是一种抽象的概念，并不真实存在，它描述的是一组规则或规范，通过这组规范定义了程序中各个变量（包括实例字段，静态字段和构成数组对象的元素）的访问方式。由于JVM运行程序的实体是线程，而每个线程创建时JVM都会为其创建一个工作内存(有些地方称为栈空间)，用于存储线程私有的数据，而Java内存模型中规定所有变量都存储在主内存，主内存是共享内存区域，所有线程都可以访问，但线程对变量的操作(读取赋值等)必须在工作内存中进行，首先要将变量从主内存拷贝的自己的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，不能直接操作主内存中的变量，工作内存中存储着主内存中的变量副本拷贝，前面说过，工作内存是每个线程的私有数据区域，因此不同的线程间无法访问对方的工作内存，线程间的通信(传值)必须通过主内存来完成。

线程之间通信主要通过两种方式(通信是指线程之间以何种机制来交换信息)：

• 共享内存：通过读-写内存中的公共区域进行隐式通信。
• 消息传递：线程之间发送消息进行显式通信。

 

线程不能自己创建变量，线程在工作内存中操作的变量全都是从主内存【堆空间】里copy到【线程栈空间】的变量副本。

JMM中规定了8种操作来完成工作内存和主内存的交互：

• 加锁 lock：把主内存中的一个变量标识为一条线程独占的状态。
• 解锁 unlock：把主内存中处于加锁状态的变量释放出来。
• 读取 read：把主内存的变量的值传输到工作内存中。
• 载入load：把主内存传输过来的变量值放进工作内存的变量副本中。
• 使用 use：把变量副本的值传递给执行引擎进行运算操作。
• 赋值 assign：工作内存接受执行引擎传递过来的值放进变量副本里。
• 存储 store：把工作内存的变量副本的值传输给主内存。
• 写入 write ：把工作内存接收到的值放进主内存的变量中。

由于共享数据区【堆】有多线程的操作和访问，所以存在线程安全问题。但是工作区域内【栈】都是线程私有的，所以不存在其他线程的访问，所以不存在线程安全问题。

并发编程的三个概念

• 原子性
• 有序性
• 可见性

原子性

原子性：即一个操作或者多个操作 要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行，不可被中断，不会出现中间状态。如下例一：

x = 1;         //语句1
y = x;         //语句2
x++;           //语句3
x = x + 1;     //语句4

以上四个语句那几个是原子操作呢，答案只有语句一。语句一是直接将10写入到工作内存中。

　　语句2实际上包含2个操作，(1)、先去读取x的值；(2)、再将x的值写入内存；单一的操作是原子的，但是两步合起来就不是了；

　　同样的，x++和 x = x+1包括3个操作：(1)、读取x的值；(2)、进行加1操作；(3)、写入新的值。

 　　所以上面4个语句只有语句1的操作具备原子性。

　　也就是说，只有简单的读取、赋值（而且必须是将数字赋值给某个变量，变量之间的相互赋值不是原子操作）才是原子操作。

　　另外一个很经典的例子就是银行账户转账问题：

　　比如从账户A向账户B转1000元，那么必然包括2个操作：从账户A减去1000元，往账户B加上1000元。

　　试想一下，如果这2个操作不具备原子性，会造成什么样的后果。假如从账户A减去1000元之后，操作突然中止。然后又从B取出了500元，取出500元之后，再执行 往账户B加上1000元 的操作。这样就会导致账户A虽然减去了1000元，但是账户B没有收到这个转过来的1000元。

　　所以这2个操作必须要具备原子性才能保证不出现一些意外的问题。

       值得注意的是：对于32位系统的来说，对于基本数据类型，byte,short,int,float,boolean,char读写是原子操作。而long和double则是64位的存储单元，对它们的操作不是原子的。这样会导致一个线程在写时，操作完前32位的原子操作后，轮到B线程读取时，恰好只读取到了后32位的数据，这样可能会读取到一个既非原值又不是线程修改值的变量，它可能是“半个变量”的数值，即64位数据被两个线程分成了两次读取，需要注意一下。

可见性

　　可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。如下例二：

//线程thread1执行的代码
int i = 0;
i = 2;
 
//线程thread2执行的代码
j = i;

　　假若执行线程1的是CPU1，执行线程2的是CPU2。由上面的分析可知，当线程1执行 i =10这句时，会先把i的初始值加载到CPU1的高速缓存中，然后赋值为2，那么在CPU1的高速缓存当中i的值变为2了，却没有立即写入到主存当中。

　　此时线程2执行 j = i，它会先去主存读取i的值并加载到CPU2的缓存当中，注意此时内存当中i的值还是0，那么就会使得j的值为0，而不是2.

　　这就是可见性问题，线程1对变量i修改了之后，线程2没有立即看到线程1修改的值。

       对于串行程序来说，可见性是不存在的，因为我们在任何一个操作中修改了某个变量的值，后续的操作中都能读取这个变量值，并且是修改过的新值。但在多线程环境中可就不一定了，前面我们分析过，由于线程对共享变量的操作都是线程拷贝到各自的工作内存进行操作后才写回到主内存中的，这就可能存在一个线程A修改了共享变量x的值，还未写回主内存时，另外一个线程B又对主内存中同一个共享变量x进行操作，但此时A线程工作内存中共享变量x对线程B来说并不可见，这种工作内存与主内存同步延迟现象就造成了可见性问题，另外指令重排以及编译器优化也可能导致可见性问题。

有序性

有序性：即程序执行的顺序按照代码的先后顺序执行。

看下面代码，如下例三：

int i = 0;            //语句1
boolean result = true;//语句2
i = 2;                //语句3  
result = false;         //语句4

上面代码定义了一个int型变量，定义了一个boolean类型变量，然后分别对两个变量进行赋值操作。从代码顺序上看，语句1是在语句2前面的，那么JVM在真正执行这段代码的时候会保证语句1一定会在语句2前面执行吗？不一定，为什么呢？这里可能会发生指令重排序（Instruction Reorder）。

　　下面解释一下什么是指令重排序，一般来说，处理器为了提高程序运行效率，可能会对输入代码进行优化，它不保证程序中各个语句的执行先后顺序同代码中的顺序一致，但是它通过指令之间的依赖性来保证程序最终执行结果和代码顺序执行的结果是一致的。指令重排包括：编译期重排，指令并行的重排和内存系统的重排。编译器优化的重排属于编译期重排，指令并行的重排和内存系统的重排属于处理器重排，在多线程环境中，这些重排优化可能会导致程序出现内存可见性问题

　　比如上面的代码中，语句1和语句2谁先执行对最终的程序结果并没有影响，那么就有可能在执行过程中，语句2先执行而语句1后执行。但是语句2和4之间有依赖关系，指令4依赖指令2，所以2一定在4之前执行。

程序的顺序是：1-2-3-4，但是jvm实际执行的顺序可以是：2-4-1-3，1-3-2-4，2-1-3-4。

虽然重排序不会影响单个线程内程序执行的结果，但是多线程就不一定了？如下例四：

//线程1:
config = getConfig();   //语句1
inited = true;             //语句2
 
//线程2:
while(!inited ){
  sleep()
}
doSomethingwithconfig(config);

上面代码中，由于语句1和语句2没有数据依赖性，因此可能会被重排序。假如发生了重排序，在线程1执行过程中先执行语句2，而此是线程2会以为初始化工作已经完成，那么就会跳出while循环，去执行doSomethingwithconfig(config)方法，而此时config并没有配置完成。

 　　从上面可以看出，指令重排序不会影响单个线程的执行，但是会影响到线程并发执行的正确性。

　　也就是说，要想并发程序正确地执行，必须要保证原子性、可见性以及有序性。只要有一个没有被保证，就有可能会导致程序运行不正确。

JMM提供的解决方案

对于上面提到的原子性，可见性以及有序性问题，JMM是如何保证的呢？

在Java内存模型中都提供一套解决方案供Java工程师在开发过程使用：

原子性问题：除了JVM自身提供的对基本数据类型读写操作的原子性外，对于方法级别或者代码块级别的原子性操作，可以使用synchronized关键字或者重入锁(ReentrantLock)保证程序执行的原子性。

可见性问题：对于工作内存与主内存同步延迟现象导致的可见性，也可以使用synchronized和volatile关键字解决，它强制了线程的同步串行对临界资源的修改，使其他线程可见。对于指令重排导致的可见性问题和有序性问题，则可以利用volatile关键字解决，因为volatile的另外一个作用就是通过内存屏障禁止重排序优化；

有序性问题：除了synchronized和volatile关键字外，JMM内部还定义一套happens-before 原则来保证多线程环境下两个操作间的原子性、可见性以及有序性。

happens-before 原则

（1）程序顺序原则，即在一个线程内必须保证语义串行性，也就是说按照代码顺序执行。

（2）锁规则 解锁(unlock)操作必然发生在后续的同一个锁的加锁(lock)之前，也就是说，如果对于一个锁解锁后，再加锁，那么加锁的动作必须在解锁动作之后(同一个锁)。

（3）volatile规则 volatile变量的写，先发生于读，这保证了volatile变量的可见性，简单的理解就是，volatile变量在每次被线程访问时，都强迫从主内存中读该变量的值，而当该变量发生变化时，又会强迫将最新的值刷新到主内存，任何时刻，不同的线程总是能够看到该变量的最新值。

（4）线程启动规则 线程的start()方法先于它的每一个动作，即如果线程A在执行线程B的start方法之前修改了共享变量的值，那么当线程B执行start方法时，线程A对共享变量的修改对线程B可见

（5）传递性 A先于B ，B先于C 那么A必然先于C

（6）线程终止规则 线程的所有操作先于线程的终结，Thread.join()方法的作用是等待当前执行的线程终止。假设在线程B终止之前，修改了共享变量，线程A从线程B的join方法成功返回后，线程B对共享变量的修改将对线程A可见。

（7）线程中断规则 对线程 interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测线程是否中断。

（8）对象终结规则 对象的构造函数执行，结束先于finalize()方法

注意：上述8条原则无需手动添加任何同步手段(synchronized|volatile)即可达到效果，这个是jvm在执行的时候默认遵守的原则。

volatile关键字

volatile是Java虚拟机提供的轻量级的同步机制。volatile关键字有如下两个作用：

• 保证被volatile修饰的共享变量对所有线程总数可见的；【也就是当一个线程修改了一个被volatile修饰共享变量的值，新值总是可以被其他线程立即得知】

• 禁止指令重排序优化。【个人认为并不是完全的禁止指令重排，只是禁止对插入内存屏障前后的指令重排】

volatile仅仅用来保证该变量对所有线程的可见性，但不保证原子性。

内存屏障 Memory Barrier

  内存屏障（Memory Barrier），又称内存栅栏，是一个CPU指令。作用如下：

• 使写缓冲区的内容刷新到内存，保证对其他线程/CPU可见；
• 禁止读写操作的越过内存屏障进行重排序；

      编译器和CPU可以在保证输出结果一样的情况下对指令重排序，使性能得到优化。插入一个内存屏障，相当于告诉CPU和编译器先于这个命令的必须先执行，后于这个命令的必须后执行。内存屏障另一个作用是强制更新一次不同CPU的缓存。

内存屏障（Memory Barrier）和volatile什么关系？

    如果你的字段是volatile，Java内存模型将在写操作后插入一个写屏障指令，在读操作前插入一个读屏障指令。这意味着如果你对一个volatile字段进行写操作，结果就是：

   1)、一旦你完成写入，任何访问这个字段的线程将会得到最新的值。

   2)、在你写入前，会保证所有之前发生的事已经发生，并且任何更新过的数据值也是可见的，因为内存屏障会把之前的写入值都刷新到缓存。

volatile保证可见性吗？

先来看下面一个中断程序，例五：

//中断程序
//线程1
boolean volatile stop = false;
while(!stop){
    doSomething();
}
 
//线程2
stop = true;

     在中断程序中，如果stop没有用volatile修饰，一定会发生中断吗，答案是不确定。因为每个线程在运行过程中都有自己的工作内存，那么线程1在运行的时候，会将stop变量的值拷贝一份放在自己的工作内存当中。那么当线程2更改了stop变量的值之后，但是还没来得及写入主存当中，线程2转去做其他事情了，那么线程1由于不知道线程2对stop变量的更改，这样会导致线程一工作内存中的值永远是false，因此还会一直循环下去。

  所以volatile是可以保证可见性的。

导致可见性的原因：

• 读写缓冲区；
• 缓存的使用；
• 指令重排顺序无法确定；

volatile如何保证可见性及禁止指令重排：

• 使用volatile修饰，对该变量的读取会插入一条内存屏障lock，cpu不会将其后面的指令放在其前面执行，反之亦然；
• 使用volatile修饰，会强制将修改的值刷新到主存；
• 使用volatile修饰，对变量的写操作会导致其他缓存行的值无效，再次读取时会到主存去读取；

volatile保证原子性吗？

我们先看下面一个测试

public class VolatileAtomicTest {

    public volatile int inc = 0;

    public void increase() {
        inc++;
    }

    public static void main(String[] args) {

         VolatileAtomicTest atomicTest = new VolatileAtomicTest();
        for (int i = 0; i < 3; i++) {
            new Thread() {
                public void run() {
                    for (int j = 0; j < 1000; j++)
                        atomicTest.increase();
                }
            }.start();
        }
        try {
            sleep(1000);  //保证所有的线程都执行完毕
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println(atomicTest.inc);
    }

}

　　这个结果或是多少呢，我们的理想值是3000，但实际上每次都不一样，并且该值是一个小于3000的值。可能这里就会有疑问了，不对啊，上面是对变量inc进行自增操作，由于volatile保证了可见性，那么在每个线程中对inc自增完之后，在其他线程中都能看到修改后的值啊，所以有3个线程分别进行了1000次操作，那么最终inc的值应该是1000*3=3000。

　　这里面就有一个误区了，volatile关键字能保证可见性没有错，但是上面的程序错在没能保证原子性。可见性只能保证每次读取的是最新的值，但是volatile没办法保证对变量的操作的原子性。在前面例一中已经提到过，自增操作是不具备原子性的，它包括读取变量的原始值、进行加1操作、写入工作内存。那么就是说自增操作的三个子操作可能会分割开执行，就有可能导致下面这种情况出现：

　　假如某个时刻变量inc的值为10，

　　线程1对变量进行自增操作，线程1先读取了变量inc的原始值，然后线程1被阻塞了；

　　然后线程2对变量进行自增操作，线程2也去读取变量inc的原始值，由于线程1只是对变量inc进行读取操作，而没有对变量进行修改操作，所以不会导致线程2的工作内存中缓存变量inc的缓存行无效，所以线程2会直接去主存读取inc的值，发现inc的值时10，然后进行加1操作，并把11写入工作内存，最后写入主存。

　　然后线程1接着进行加1操作，由于已经读取了inc的值，注意此时在线程1的工作内存中inc的值仍然为10，所以线程1对inc进行加1操作后inc的值为11，然后将11写入工作内存，最后写入主存。

　　那么两个线程分别进行了一次自增操作后，inc只增加了1。

　　解释到这里，可能有朋友会有疑问，不对啊，前面不是保证一个变量在修改volatile变量时，会让缓存行无效吗？然后其他线程去读就会读到新的值，对，这个没错。这个就是上面的happens-before规则中的volatile变量规则，但是要注意，线程1对变量进行读取操作之后，被阻塞了的话，并没有对inc值进行修改。然后虽然volatile能保证线程2对变量inc的值读取是从内存中读取的，但是线程1没有进行修改，所以线程2根本就不会看到修改的值。

　　根源就在这里，自增操作不是原子性操作，而且volatile也无法保证对变量的任何操作都是原子性的。

我们可以采用synchronize/lock/automicInteger中的任何一个都可以达到上面的目标。

    // 法一：加入synchrozied，保证执行的原子性
    public synchronized void  increase() {
        inc++;
    }

    //方法二：采用lock机制
    Lock lock = new ReentrantLock();
    
    public  void increase() {
        lock.lock();
        try {
            inc++;
        } finally{
            lock.unlock();
        }
    }

    方法三：采用AtomicInteger机制
    public  AtomicInteger inc = new AtomicInteger();
     
    public  void increase() {
        inc.getAndIncrement();
    }

        atomic是利用CAS来实现原子性操作的（Compare And Swap），CAS实际上是利用处理器提供的CMPXCHG指令实现的，而处理器执行CMPXCHG指令是一个原子性操作。

    //AtomicInteger类的getAndIncrement的源代码
    public final int getAndIncrement() {
        for (; ; ) {
            int current = get();  // 取得AtomicInteger里存储的数值
            int next = current + 1;  // 加1
            if (compareAndSet(current, next))   // 调用compareAndSet执行原子更新操作
                return current;
        }
    }

cas利用了基于冲突检测的乐观并发策略 ，CAS自旋volatile变量，可以很高效的解决原子问题。在java 1.5的java.util.concurrent.atomic包下提供了一些原子操作类，即对基本数据类型的 自增（加1操作），自减（减1操作）、以及加法操作（加一个数），减法操作（减一个数）进行了封装，保证这些操作是原子性操作。

volatile保证有序性吗？

由于volatile能禁止指令的重排，所以在一定程度上可以保证有序性。前面也讲过，volatile主要通过内存屏障保证了值在内存中的可见性及有序性。主要有以下两点：

    （1）当程序执行到volatile变量的读操作或者写操作时，在其前面的操作的更改肯定全部已经进行，且结果已经对后面的操作可见；在其后面的操作肯定还没有进行；

　（2）在进行指令优化时，不能将在对volatile变量访问的语句放在其后面执行，也不能把volatile变量后面的语句放到其前面执行。

例如针对例四，我们做如下改动，例六：

//线程1:
x = 1;                              //语句1
y = 4;                              //语句2
config = getConfig();               //语句3

volatile inited = false;             //语句4  volatile


//线程2:
while( !inited ){
  x = x + 1;                          //语句5
  y = y + 1;                          //语句6
}
doSomethingwithconfig(config);

      我们知道在例四中由于语句3-4没有依赖性，可能会发生指令重排，可能导致config没有获取到配置信息，当线程2去执行的时候出错。但是当我们加上volatile后，就可以避免此类问题的发生。因为volatile保证了在执行语句4的时候，语句1-2-3一定执行完了，1-2-3的执行结果对语句5-6是可见的，禁止了volatile前后语句的指令重排序，保证来指令执行的有序，避免了例四的问题发生。但是语句1-2-3和语句5-6的执行顺序是不做保证的。

另外还有一个经典的double-check单例模式的应用，如下例七：

    //TODO 通过volatile设置内存屏障，禁止指令排序，使写先与读；
    private static volatile DoubleCheckLockSingletonTest singleInstance;

    private DoubleCheckLockSingletonTest() {
    }
    public static DoubleCheckLockSingletonTest getInstance() {
        if (singleInstance == null) {
            synchronized (DoubleCheckLockSingletonTest.class) {
                if (singleInstance == null) {
                    singleInstance = new DoubleCheckLockSingletonTest();
                }
            }
        }
        return singleInstance;
    }

以上代码中instance为什么需要用volatile来修饰，主要设计到指令的重排和原子操作。

主要在于singleInstance = new DoubleCheckLockSingletonTest();这句，这并非是一个原子操作，事实上在 JVM 中这句话大概做了下面 3 件事情：

memory = allocate();                   //第一步：给 singleton 分配内存；
DoubleCheckLockSingletonTest(memory);  //第二步：调用 构造函数来初始化成员变量，形成实例；
singleInstance = memory;               //第三步：将singleInstance对象指向分配的内存空间（执行完这步 singleInstance才是非 null 了）；

但是由于步骤2-3之间没有依赖性，所以步骤2-3可能会发生指令的重排序。这种重排序在串行的单线程是OK的，但是如果发生在高并发的多线程将产生不可估计的后果。有可能产生如下的执行顺序：

//2-3步发生来指令的重排序
memory = allocate();                   //第一步：给 singleton 分配内存；
singleInstance = memory;               //第三步：将singleInstance对象指向分配的内存空间（执行完这步 singleInstance才是非 null 了）；
DoubleCheckLockSingletonTest(memory);  //第二步：调用 构造函数来初始化成员变量，形成实例；

如果此时线程一正执行到重排后的第三步还未完成，此时线程2请求到达后，判断singleInstance不为空，但是实例化为完成，此时线程2返回的将是一个【线程一初始化未完成的实例这样一个中间状态的值】，所以肯定会出问题。

这里的关键是：线程一没有完成初始化，线程2就读取来其中的内容。所以volatile就派上来用场，volatile关键字的一个作用是禁止指令重排，把singleInstance声明为volatile之后，对它的写操作就会有一个内存屏障，这样在singleInstance的赋值写操作完成之前，就不用会调用对其读操作，从而保证了有序性。

注意：volatile阻止的不singleton = new Singleton()这句话内部[1-2-3]步的指令重排，而是保证了在一个写操作（[1-2-3]）步完成之前，不会调用读操作（if (singleInstance == null)）。

volatiile的实现原理

　　“观察加入volatile关键字和没有加入volatile关键字时所生成的汇编代码发现，加入volatile关键字时，会多出一个lock前缀指令”

　　lock前缀指令实际上相当于一个内存屏障（也成内存栅栏），上面也有讲过，内存屏障会提供3个功能：

1. 　　它确保指令重排序时不会把其后面的指令排到内存屏障之前的位置，也不会把前面的指令排到内存屏障的后面；即在执行到内存屏障这句指令时，在它前面的操作已经全部完成；
2. 　　它会强制将对缓存的修改操作立即写入主存；
3. 　　如果是写操作，它会导致其他CPU中对应的缓存行无效。

volatile的使用

注意：      

   synchronized关键字是防止多个线程同时执行一段代码，那么就会很影响程序执行效率，而volatile关键字在某些情况下性能要优于synchronized，但是要注意volatile关键字是无法替代synchronized关键字的，因为volatile关键字无法保证操作的原子性，存在依赖关系的时候。

     ##只有保证操作的原子性，才能保证使用volatile关键字的程序在并发时能够正确执行，否则将会发生意想不到的事情。

      不要将volatile用在getAndOperate场合（这种场合不原子，需要再加锁synchronized或者lock或者使用Atomic*类），仅仅set或者get的场景是适合volatile的。

缺点：

• 不保证原子性
• 读内存的开销

总结

• synchronized: 具有原子性，有序性和可见性；
• volatile：具有有序性和可见性

 

初学java，积少成多。资料参考：

《java并发编程的艺术》 方腾飞 程晓明

《深入理解jvm虚拟机》 周志明

https://blog.csdn.net/caoshangpa/article/details/78853919
https://blog.csdn.net/u012233832/article/details/79619648
https://www.cnblogs.com/dolphin0520/p/3920373.html
https://blog.csdn.net/zdxiq000/article/details/60874848
https://blog.csdn.net/javazejian/article/details/72772461#java%E5%86%85%E5%AD%98%E5%8C%BA%E5%9F%9F
http://www.cnblogs.com/Mainz/p/3556430.html

感谢以上的有心的作者提供了很不错的学习资料。