volatile关键字的原理，作用，使用

1.volatile的作用

1，可以使得在多处理器环境下保证了共享变量的可见性。
2，禁止指令重排序优化

什么是可见性呢？
在多线程环境下，读和写发生在不同的线程中的时候，可能会出现：读线程不能及时的读取到其他线程写入的最新的值。这就是所谓的可见性。

volatile 关键字是如何保证可见性的？
使用【hsdis】这个工具，查看lock汇编指令，在多处理器环境下，lock 汇编指令可以基于总线锁或者缓存锁的机制来达到可见性的一个效果。

可见性的本质总结：
由于 CPU 高速缓存的出现使得 如果多个 cpu 同时缓存了相同的共享数据时，可能存在可见性问题。也就是 CPU0 修改了自己本地缓存的值对于 CPU1 不可见。不可见导致的后果是 CPU1 后续在对该数据进行写入操作时，是使用的脏数据。使得数据最终的结果不可预测。 所以要使用volatile关键字来解决这个不可见的问题。

缓存一致性
当提出cpu的告诉缓存问题，就会引出缓存一致性问题。
那么什么是缓存一致性问题呢？有了高速缓存的存在以后，每个 CPU 的处理过程是，先将计算需要用到的数据缓存在 CPU 高速缓存中，在 CPU进行计算时，直接从高速缓存中读取数据并且在计算完成之后写入到缓存中。在整个运算过程完成后，再把缓存中的数据同步到主内存。由于在多 CPU 种，每个线程可能会运行在不同的 CPU 内，并且每个线程拥有自己的高速缓存。同一份数据可能会被缓存到多个 CPU 中，如果在不同 CPU 中运行的不同线程看到同一份内存的缓存值不一样就会存在缓存不一致的问题。

解决缓存不一致的问题解决方案

1. 总线锁
2. 缓存锁

总线锁，简单来说就是，在多 cpu 下，当其中一个处理器要对共享内存进行操作的时候，在总线上发出一个 LOCK#信号，这个信号使得其他处理器无法通过总线来访问到共享内存中的数据，总线锁定把 CPU 和内存之间的通信锁住了，这使得锁定期间，其他处理器不能操作其他内存地址的数据，所以总线锁定的开销比较大，这种机制显然是不合适的。
如何优化呢？最好的方法就是控制锁的保护粒度，我们只需要保证对于被多个 CPU 缓存的同一份数据是一致的就行。所以引入了缓存锁，它核心机制是基于缓存一致性协议来实现的。

什么是指令重排序
是指CPU采用了允许将多条指令不按程序规定的顺序分开发送给各相应电路单元处理。
那么禁止指令重排序就相当于一个内存屏障，（内存屏障的作用可以通过防止 CPU 对内存的乱序访问来保证共享数据在多线程并行执行下的可见性）
但是这个屏障怎么来加呢？回到最开始我们讲 volatile 关键字的代码，这个关键字会生成一个 Lock 的汇编指令，这个指令其实就相当于实现了一种内存屏障。

volatile的使用场景：
模式 #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）。此外，还需要某些原子状态转换机制，例如原子变量。

模式 #2：一次性安全发布（one-time safe publication）
在缺乏同步的情况下，可能会遇到某个对象引用的更新值（由另一个线程写入）和该对象状态的旧值同时存在。

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

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;   
}

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

使用该模式的另一种应用程序就是收集程序的统计信息。

【例】如下代码展示了身份验证机制如何记忆最近一次登录的用户的名字。将反复使用lastUser 引用来发布值，以供程序的其他部分使用。（主要利用了volatile的可见性）

复制代码
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;  
}  

}
复制代码
模式 #4：“volatile bean” 模式
volatile bean 模式的基本原理是：很多框架为易变数据的持有者（例如 HttpSession）提供了容器，但是放入这些容器中的对象必须是线程安全的。

在 volatile bean 模式中，JavaBean 的所有数据成员都是 volatile 类型的，并且 getter 和 setter 方法必须非常普通——即不包含约束！

复制代码
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;  
}  

}
复制代码
模式 #5：开销较低的“读－写锁”策略
如果读操作远远超过写操作，您可以结合使用内部锁和 volatile 变量来减少公共代码路径的开销。

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

复制代码
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 允许多个线程执行读操作。

单例模式
定义：

确保某个类只有一个实例，并提供一个全局访问点。

类图：

public class Singleton{  
    private static final Singleton instance;  
    private Singleton(){  
    }  
    public static Singleton getInstance(){      
        if(instance == null){          //1  
            instance = new Singleton();//2  
        }  
        return instance;               //3  
   }  
    ...  
}

优点：

内存中只有一个对象，减少内存开支；
单例可避免对资源的多重占用，例如写文件动作，可避免对同一资源文件的同时写操作。
缺点：

单例模式一般没有接口，扩展很困难； ——单例并不是用来继承的。
不利于测试，并行开发时，若单例未完成，则不能进行测试；
与单一职责原则冲突，把“要单例”和业务逻辑融合在一个类中。
使用场景：

若出现多个对象就会出现“不良反应”，应该用单例，具体场景如下：

要求生成唯一序列号的环境；
在整个项目中需要一个共享访问点或共享数据。例如页面计数器；
创建一个对象需要消耗的资源过多时；
需要定义大量的静态常量和静态方法的环境。
为什么不直接用全局变量来实现单例？

有缺点：全局变量必须在程序一开始就创建好。而单例模式可以延迟初始化。

类加载器对单例的影响：

不同的类加载器可能会加载同一个类。

如果程序有多个类加载器，可在单例中指定某个加载器，并指定同一个加载器。

多线程的影响：

上文代码示例在多线程环境下有bug：

线程 1 调用 getInstance() 方法并决定 instance 在 //1 处为null。
线程 1 进入 if 代码块，但在执行 //2 处的代码行时被线程 2 预占。
线程 2 调用 getInstance() 方法并在 //1 处决定 instance 为 null。
线程 2 进入 if 代码块并创建一个新的 Singleton 对象并在 //2 处将变量instance 分配给这个新对象。
线程 2 在 //3 处返回 Singleton 对象引用。
线程 2 被线程 1 预占。
线程 1 在它停止的地方启动，并执行 //2 代码行，这导致创建另一个 Singleton 对象。
线程 1 在 //3 处返回这个对象。
结果是 getInstance() 方法创建了两个 Singleton 对象。
解决方法一：不用延迟初始化

复制代码

public class Singleton{  
    private static final Singleton instance = new Singleton();  
    private Singleton(){  
    }  
    public static Singleton getInstance(){           
        return instance;  
   }  
    ...  
}

复制代码
解决方法二：同步getInstance

复制代码

public class Singleton{  
    private static final Singleton instance;  
    private Singleton(){  
    }  
    //同步getInstance  
    public static synchronized Singleton getInstance(){      
        if(instance == null){          //1  
            instance = new Singleton();//2  
        }  
        return instance;               //3  
   }  
    ...  
}

复制代码
但是synchronized方法会降低性能，尤其这里仅当第一次调用getInstance时才需要同步，只有执行//2代码行时才需要同步。

你可能想到只同步方法块，即只对//2进行同步：

复制代码

public static Singleton getInstance(){      
       if(instance == null){            
           synchronized(Singleton.class) {    
               instance = new Singleton();  
           }  
       }   
       return instance;  
}

复制代码
但这样做并不能解决问题：
当 instance 为 null 时，两个线程可以并发地进入if 语句内部。
然后，一个线程进入 synchronized 块来初始化 instance，而另一个线程则被阻断。

当第一个线程退出 synchronized 块时，等待着的线程进入并创建另一个Singleton 对象。

注意：当第二个线程进入 synchronized 块时，它并没有检查 instance 是否非 null。
还是会创建2个对象。

解决方法三：双重检查加锁

针对上述方法的缺点，我们在//2代码行时 再检查一次null，就能保证只创建一个对象：

复制代码
//注意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;
}

复制代码
假设有下列事件序列：

线程 1 进入 getInstance() 方法。
由于 instance 为 null，线程 1 在 //1 处进入synchronized 块。
线程 1 被线程 2 预占。
线程 2 进入 getInstance() 方法。
由于 instance 仍旧为 null，线程 2 试图获取 //1 处的锁。然而，由于线程 1 持有该锁，线程 2 在 //1 处阻塞。
线程 2 被线程 1 预占。
线程 1 执行，由于在 //2 处实例仍旧为 null，线程 1 还创建一个Singleton 对象并将其引用赋值给instance(由于java执行的无序性，可能赋值时只是占用内存空间（此时instance已经为非null，锁松开，由于无序性，还没有来得及初始化，线程2已经取得instance对象），还没有根据构造函数初始化)。
线程 1 退出 synchronized 块并从 getInstance() 方法返回实例。
线程 1 被线程 2 预占。
线程 2 获取 //1 处的锁并检查 instance 是否为 null。
由于 instance 是非 null 的，并没有创建第二个Singleton 对象，由线程 1 创建的对象被返回，此时返回对象可能是是一个构造完整却没有完全初始化的对象。
线程1继续执行完成对象的初始化，由于instance是volatile类型的，所以instance变量对所有线程共享可见，所以线程2可以得到一个完整初始化的对象。
对于上面解说的赋值，却没有初始化的原因，是由于java变量重新赋值时有3个步骤的（读取，修改，回写）

代码行 instance =new Singleton(); 执行了下列伪代码

1. mem = allocate();             //Allocate memory for Singleton object.
2. instance = mem;               //Note that instance is now non-null, but
                                 //has not been initialized.
3. ctorSingleton(instance);      //Invoke constructor for Singleton passing
                                 //instance.