1、内存屏障（Memory Barrier）

内存屏障（memory barrier）是一个CPU指令，是为了解决因为cpu、高速缓存、主内存之间运行速度差异而导致的可见性和重排序问题。

因为计算机的运算任务需要CPU和内存相互配合共同完成，其中CPU负责逻辑计算，内存负责数据存储。但是在真正的实际开发中CPU是要与内存进行交互的，但因为内存和CPU的计算速度是有差距的，因此为了提高CPU的利用效率，现代处理器结构都加入了一层读写速度尽可能接近CPU运算速度的高速缓存来作为内存与CPU之间的缓冲：将运算需要使用的数据复制到缓存中，让CPU运算可以快速进行，计算结束后再将计算结果从缓存同步到主内存中，这样处理器就无须等待缓慢的内存读写了。但在高速缓存解决CPU和内存之间速度的矛盾，但是在多CPU系统中也带来了新的问题：可见性问题和重排序问题。

1.1 可见性ABA问题

假设有两个线程A、B分别在两个不同的CPU上运行，它们共享同一个变量X。如果线程A对X进行修改后，并没有将X更新后的结果同步到主内存，则变量X的修改对B线程是不可见的。这样就会造成可见性问题

1.2 重排序问题

假设A、B两个线程共享两个变量X、Y，A和B分别在不同的CPU上运行。在A中先更改变量X的值放到高速缓存区，然后再更改变量Y的值放到高速缓存区。这时有可能发生Y的值被同步回主内存，而X的值没有同步回主内存的情况，此时对于B线程来说是无法感知到X变量被修改的，或者可以认为对于B线程来说，Y变量的修改被重排序到了X变量修改的前面。

2、为什么需要内存屏障

每个CPU都会有自己的缓存，缓存的目的就是为了提高性能，避免每次都要向内存取。但是这样的弊端也很明显：不能实时的和内存发生信息交换，分在不同CPU执行的不同线程对同一个变量的缓存值不同。

在多CPU（核）场景下，为了充分利用CPU，会通过流水线将指令并行进行。为了能并行执行，又需要将指令进行重排序以便并行执行。这些指令不是在所有场景下都能进行重排，除了本身的一些规则（如Happens Before 规则）之外，还需要确保多CPU的高速缓存中的数据与内存保持一致性，不能确保内存与CPU缓存数据一致性的指令也不能重排，内存屏障正是通过阻止屏障两边的指令重排序来避免编译器和硬件的不正确优化而提出的一种解决办法。

3、内存屏障的主要作用

a) 确保一些特定操作执行的顺序（阻止屏障两侧的指令重排序）；

b) 影响一些数据的可见性(可能是某些指令执行后的结果)。

编译器和CPU可以在保证输出结果一样的情况下对指令重排序，使性能得到优化。插入一个内存屏障，相当于告诉CPU和编译器先于这个命令的必须先执行，后于这个命令的必须后执行。内存屏障另一个作用是强制更新一次不同CPU的缓存（强制把写缓冲区/高速缓存中的脏数据等写回主内存，让缓存中相应的数据失效）。例如，一个写屏障会把这个屏障前写入的数据刷新到缓存，这样任何试图读取该数据的线程将得到最新值，而不用考虑到底是被哪个CPU执行的。

4、硬件层的内存屏障

硬件层的内存屏障分为两种：Load Barrier 和 Store Barrier即读屏障和写屏障。

Load Barrie：在指令前插入Load Barrier，可以让高速缓存中的数据失效，强制从新从主内存加载数据；
Store Barrie：在指令后插入Store Barrier，能让写入缓存中的最新数据更新写入主内存，让其他线程可见。

5、JAVA内存屏障

不同硬件实现内存屏障的方式不同，Java内存模型屏蔽了这种底层硬件平台的差异，由JVM来为不同的平台生成相应的机器码，完成一系列的屏障和数据同步功能。

Java内存屏障主要有Load和Store两类。在实际使用中，通过上述两种的组合，又分为以下四种：LoadLoad, StoreStore, LoadStore, StoreLoad。下面的Load1 和 Load2代表两条读取指令，Store1 、Store2代表两条写入指令。

LoadLoad 屏障（序列-Load1,Loadload,Load2）：在Load2要读取的数据被访问前，保证Load1要读取的数据被读取完毕。通常能执行预加载指令或/和支持乱序处理的处理器中需要显式声明Loadload屏障，因为在这些处理器中正在等待的加载指令能够绕过正在等待存储的指令。而对于总是能保证处理顺序的处理器上，设置该屏障相当于无操作。
StoreStore 屏障（序列-Store1,StoreStore,Store2 ）：在Store2写入执行前，保证Store1的写入操作对其它处理器可见（例如向主存刷新数据）。通常情况下，如果处理器不能保证从写缓冲或/和缓存向其它处理器和主存中按顺序刷新数据，那么它需要使用StoreStore屏障。
LoadStore 屏障（序列-Load1,LoadStore,Store2 ）：在Store2被写入前，保证Load1要读取的数据被读取完毕。在等待Store指令可以越过loads指令的乱序处理器上需要使用LoadStore屏障。
StoreLoad 屏障（序列-Store1,StoreLoad,Load2 ）：在Load2读取操作执行前，保证Store1的写入对所有处理器可见。StoreLoad屏障的开销是四种屏障中最大的。在大多数处理器的实现中，这个屏障是个万能屏障，兼具其它三种内存屏障的功能。StoreLoad屏障可以防止一个后续的load指令不正确的使用了Store1的数据，而不是另一个处理器在相同内存位置写入一个新数据。正因为如此，所以处理器为了在屏障前读取同样内存位置存过的数据，必须使用一个StoreLoad屏障将存储指令和后续的加载指令分开。它们昂贵的部分原因是它们必须关闭通常的略过缓存直接从写缓冲区读取数据的机制。这可能通过让一个缓冲区进行充分刷新（flush）,以及其他延迟的方式来实现。

6、java内存屏障使用方式

通过 Synchronized 关键字包住的代码区域，当线程进入到该区域读取变量信息时，保证读到的是最新的值。这是因为在同步区内对变量的写入操作，在离开同步区时就将当前线程内的数据刷新到内存中，而对数据的读取也不能从缓存读取，只能从内存中读取，保证了数据的读有效性.这就是插入了StoreStore屏障。

使用volatile修饰变量，则对变量的写操作，会插入StoreLoad屏障.

其余的操作，则需要通过Unsafe这个类来执行。

UNSAFE.putOrderedObject类似这样的方法，会插入StoreStore内存屏障；
Unsafe.putVolatiObject 则是插入了StoreLoad屏障。

7、volatile实现原理

7.1 volatile定义

java编程语言允许线程访问共享变量，为了确保共享变量能被准确和一致的更新，线程应该确保通过排他锁单独获得这个变量。

Java语言提供了volatile，在某些情况下比锁更加方便。如果一个字段被声明成volatile，java线程内存模型确保所有线程看到这个变量的值是一致的。

7.2 volatile作用

volatile作用是能保证可见性和防止指令重排序。volatile保证内存可见性和防止指令重排序的原理，本质上是同一个问题，也都是依靠内存屏障得到解决。

volatile关键字通过“内存屏障”来防止指令被重排序。为了实现volatile的内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。然而，对于编译器来说，发现一个最优布置来最小化插入屏障的总数几乎不可能，为此，Java内存模型采取保守策略。下面是基于保守策略的JMM内存屏障插入策略：

在每个volatile写操作前插入StoreStore屏障，这样就能让其他线程修改A变量后，把修改的值对当前线程可见；
在每个volatile写操作后插入StoreLoad屏障，这样就能让其他线程获取A变量的时候，能够获取到已经被当前线程修改的值；
在每个volatile读操作前插入LoadLoad屏障，这样就能让当前线程获取A变量的时候，保证其他线程也都能获取到相同的值，这样所有的线程读取的数据就一样了；
在每个volatile读操作后插入LoadStore屏障；这样就能让当前线程在其他线程修改A变量的值之前，获取到主内存里面A变量的的值。

volatile与synchronized对比：volatile变量修饰符如果使用恰当的话，它比synchronized的使用和执行成本会更低，因为它不会引起线程上下文的切换和调度。

7.3 volatile为什么不能保证原子性

原子操作是一些列的操作要么全做，要么全不做，而volatile 是一种弱的同步机制，只能确保共享变量的更新操作及时被其他线程看到，以最常用的i++来说吧，包含3个步骤

从内存读取i当前的值 2
加 1 变成 3
把修改后的值刷新到内存

volatile无法保证这三个不被打断的执行完毕，如果在刷新到内存之前有中断，此时被其他线程修改了，之前的值也就无效了。

7.4 volatile的使用条件

Volatile 变量具有 synchronized 的可见性特性，但是不具备原子性。这就是说线程能够自动发现 volatile 变量的最新值。

Volatile 变量可用于提供线程安全，但是只能应用于非常有限的一组用例：多个变量之间或者某个变量的当前值与修改后值之间没有约束。因此，单独使用 volatile 还不足以实现计数器、互斥锁或任何具有与多个变量相关的不变式（Invariants）的类（例如 “start <=end”）。
出于简易性或可伸缩性的考虑，您可能倾向于使用 volatile 变量而不是锁。当使用 volatile 变量而非锁时，某些习惯用法（idiom）更加易于编码和阅读。此外，volatile 变量不会像锁那样造成线程阻塞，因此也很少造成可伸缩性问题。在某些情况下，如果读操作远远大于写操作，volatile 变量还可以提供优于锁的性能优势。

您只能在有限的一些情形下使用 volatile 变量替代锁。要使 volatile 变量提供理想的线程安全，必须同时满足下面两个条件：

对变量的写操作不依赖于当前值。

该变量没有包含在具有其他变量的不变式中。

实际上，这些条件表明，可以被写入 volatile 变量的这些有效值独立于任何程序的状态，包括变量的当前状态。

第一个条件的限制使 volatile 变量不能用作线程安全计数器。虽然增量操作（x++）看上去类似一个单独操作，实际上它是一个由（读取－修改－写入）操作序列组成的组合操作，必须以原子方式执行，而 volatile 不能提供必须的原子特性。实现正确的操作需要使x 的值在操作期间保持不变，而 volatile 变量无法实现这点。（然而，如果只从单个线程写入，那么可以忽略第一个条件。）

8、volatile的适用场景

volatile是在synchronized性能低下的时候提出的。如今synchronized的效率已经大幅提升，所以volatile在代码同步操作方面存在的意义不大，以下是它的一些应用场景。

8.1 状态标志

也许实现 volatile 变量的规范使用仅仅是使用一个布尔状态标志，用于指示发生了一个重要的一次性事件，例如完成初始化或请求停机。

volatile boolean shutdownRequested;
 
...
 
public void shutdown() { 
    shutdownRequested = true; 
}
 
public void doWork() { 
    while (!shutdownRequested) { 
        // do stuff
    }
}

线程1执行doWork()的过程中，可能有另外的线程2调用了shutdown，所以boolean变量必须是volatile。而如果使用 synchronized 块编写循环要比使用 volatile 状态标志编写麻烦很多。由于 volatile 简化了编码，并且状态标志并不依赖于程序内任何其他状态，因此此处非常适合使用 volatile。

这种类型的状态标记的一个公共特性是：通常只有一种状态转换；shutdownRequested 标志从false 转换为true，然后程序停止。这种模式可以扩展到来回转换的状态标志，但是只有在转换周期不被察觉的情况下才能扩展（从false 到true，再转换到false）。此外，还需要某些原子状态转换机制，例如原子变量。

8.2 一次性安全发布（one-time safe publication）

在缺乏同步的情况下，可能会遇到某个对象引用的更新值（由另一个线程写入）和该对象状态的旧值同时存在。

这就是造成著名的双重检查锁定（double-checked-locking）问题的根源，其中对象引用在没有同步的情况下进行读操作，产生的问题是您可能会看到一个更新的引用，但是仍然会通过该引用看到不完全构造的对象。可以参考：JAVA设计模式之单例模式（6种实现）

//注意volatile！！！！
private volatile static Singleton instace;   
  
public static Singleton getInstance(){   
    //第一次null检查     
    if(instance == null){            
        synchronized(Singleton.class) {    //1     
            //第二次null检查       
            if(instance == null){       //2  
                instance = new Singleton();//3  
            }  
        }           
    }  
    return instance;

如果不用volatile，则因为内存模型允许所谓的“无序写入”，可能导致失败。

某个线程可能会获得一个未完全初始化的实例。

考察上述代码中的 //3 行。此行代码创建了一个 Singleton 对象并初始化变量 instance 来引用此对象。这行代码的问题是：在Singleton 构造函数体执行之前，变量instance 可能成为非 null 的！

什么？这一说法可能让您始料未及，但事实确实如此。

在解释这个现象如何发生前，请先暂时接受这一事实，我们先来考察一下双重检查锁定是如何被破坏的。假设上述代码执行以下事件序列：

线程 1 进入 getInstance() 方法。
由于 instance 为 null，线程 1 在 //1 处进入synchronized 块。
线程 1 前进到 //3 处，但在构造函数执行之前，使实例成为非null。
线程 1 被线程 2 预占。
线程 2 检查实例是否为 null。因为实例不为 null，线程 2 将instance 引用返回，返回一个构造完整但部分初始化了的Singleton 对象。
线程 2 被线程 1 预占。
线程 1 通过运行 Singleton 对象的构造函数并将引用返回给它，来完成对该对象的初始化。

8.3 独立观察（independent observation）

安全使用 volatile 的另一种简单模式是：定期 “发布” 观察结果供程序内部使用。【例如】假设有一种环境传感器能够感觉环境温度。一个后台线程可能会每隔几秒读取一次该传感器，并更新包含当前文档的 volatile 变量。然后，其他线程可以读取这个变量，从而随时能够看到最新的温度值。

使用该模式的另一种应用程序就是收集程序的统计信息。【例】如下代码展示了身份验证机制如何记忆最近一次登录的用户的名字。将反复使用lastUser 引用来发布值，以供程序的其他部分使用。

public class UserManager {
    public volatile String lastUser; //发布的信息
 
    public boolean authenticate(String user, String password) {
        boolean valid = passwordIsValid(user, password);
        if (valid) {
            User u = new User();
            activeUsers.add(u);
            lastUser = user;
        }
        return valid;
    }
}

8.4 “volatile bean” 模式

volatile bean 模式的基本原理是：很多框架为易变数据的持有者（例如 HttpSession）提供了容器，但是放入这些容器中的对象必须是线程安全的。
在 volatile bean 模式中，JavaBean 的所有数据成员都是 volatile 类型的，并且 getter 和 setter 方法必须非常普通——即不包含约束！

@ThreadSafe
public class Person {
    private volatile String firstName;
    private volatile String lastName;
    private volatile int age;
 
    public String getFirstName() { return firstName; }
    public String getLastName() { return lastName; }
    public int getAge() { return age; }
 
    public void setFirstName(String firstName) { 
        this.firstName = firstName;
    }
 
    public void setLastName(String lastName) { 
        this.lastName = lastName;
    }
 
    public void setAge(int age) { 
        this.age = age;
    }
}

8.5 开销较低的“读－写锁”策略

如果读操作远远超过写操作，您可以结合使用内部锁和 volatile 变量来减少公共代码路径的开销。

如下显示的线程安全的计数器，使用 synchronized 确保增量操作是原子的，并使用 volatile 保证当前结果的可见性。如果更新不频繁的话，该方法可实现更好的性能，因为读路径的开销仅仅涉及 volatile 读操作，这通常要优于一个无竞争的锁获取的开销。

@ThreadSafe
public class CheesyCounter {
    // Employs the cheap read-write lock trick
    // All mutative operations MUST be done with the 'this' lock held
    @GuardedBy("this") private volatile int value;
 
    //读操作，没有synchronized，提高性能
    public int getValue() { 
        return value; 
    } 
 
    //写操作，必须synchronized。因为x++不是原子操作
    public synchronized int increment() {
        return value++;
    }
}

使用锁进行所有变化的操作，使用 volatile 进行只读操作。其中，锁一次只允许一个线程访问值，volatile 允许多个线程执行读操作。

8.6 反例：volatile变量不能用于约束条件中