内存模型*
☁️ JMM即为 JAVA 内存模型（java memory model）;
☁️ 不同的硬件生产商和不同的操作系统下，内存的访问逻辑有一定的差异，假如在某个系统环境下编写的代码运行良好，并且线程安全，但是换了个系统就可能出现各种问题；
☁️ Java内存模型的主要目标是定义程序中各个变量的访问规则，即在JVM中将变量存储到内存和从内存中取出变量这样的底层细节；
☁️ 此处的变量包括实例字段、静态字段和构成数组对象的元素，但不包括局部变量和方法参数，因为后两者是线程私有的，不会被线程共享；
主内存和工作内存
☁️ Java内存模型规定了所有的变量都存储在主内存中；
☁️ 每条线程还有自己的工作内存，线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作(读取、赋值等)都必须在工作内存进行，而不能直接读写主内存中的变量；
☁️ 不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成；线程、主内存、工作内存三者的交互关系如下所示 :
内存交互操作
☁️ 内存交互操作有8种，虚拟机实现必须保证每一个操作都是不可再分的；
- lock（锁定）：作用于主内存的变量，把一个变量标识为线程独占状态；
- unlock （解锁）：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定；
- read（读取）：作用于主内存变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的 load 动作使用；
- load（载入）：作用于工作内存的变量，它把 read 操作从主存中变量放入工作内存中；
- use（使用）：作用于工作内存中的变量，它把工作内存中的变量传输给执行引擎，每当虚拟机遇到一个需要使用到变量的值，就会使用到这个指令；
- assign（赋值）：作用于工作内存中的变量，它把一个从执行引擎中接受到的值放入工作内存的变量副本中；
- store（存储）：作用于主内存中的变量，它把一个从工作内存中一个变量的值传送到主内存中，以便后续的 write 使用；
- write（写入）：作用于主内存中的变量，它把 store 操作从工作内存中得到的变量的值放入主内存的变量中；
☁️ Java内存模型的三大特性：
⚡️ 原子性 : 由Java内存模型来直接保证的原子性变量操作包括 read、load、assign、use、store和 read；大致可以认为，基本数据类型的访问读写是具备原子性的；如若需要更大范围的原子性，需 要 synchronized 关键字约束；(即一个操作或者多个操作 要么全部执行并且执行的过程不会被任何 因素打断，要么就都不执行)；
⚡️ 可见性 : 可见性是指当一个线程修改了共享变量的值，其他线程能够立即得知这个修改；volatile、 synchronized、final三个关键字可以实现可见性；
⚡️ 有序性 : 如果在本线程内观察，所有的操作都是有序的；如果在线程中观察另外一个线程，所有的操作都是无序的；前半句是指 " 线程内表现为串行 " ，后半句是指 " 指令重排序 " 和 " 工作内存与主内存同步延迟 " 现象；
☁️ JMM具备一些先天的 “有序性” ，即不需要通过任何手段就能够得到保证的有序性，这个通常也称为happens-before 原则；如果两个操作的执行次序无法从happens-before原则推导出来，那么那么就证明他们的有序性无法得到保证：
- 程序次序规则：一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作
- 锁定规则：一个unLock操作先行发生于后面对同一个锁的lock操作
- volatile变量规则：对一个变量的写操作先行发生于后面对这个变量的读操作
- 传递规则：如果操作A先行发生于操作B，而操作B又先行发生于操作C，则可以得出操作A先行发生 于操作C
- 线程启动规则：Thread对象的start()方法先行发生于此线程的每个一个动作
- 线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生
- 线程终结规则：线程中所有的操作都先行发生于线程的终止检测，我们可以通过Thread.join()方法 结束、Thread.isAlive()的返回值手段检测到线程已经终止执行
- 对象终结规则：一个对象的初始化完成先行发生于他的finalize()方法的开始
☁️ 也就是说，要想并发程序正确地执行，必须要保证原子性、可见性以及有序性，只要有一个没有被保证，就有可能会导致程序运行不正确；
volatile型变量的特殊规则
☁️ 被 volatile 定义的变量，具备两种特性：
⚡️ 保证此变量对所有线程的可见性：当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的；而普通变量做不到这一点，普通变量的值在线程间传递均需要通过主内存来完成；
volatile变量在各个线程中是一致的，但是 volatile变量的运算在并发下一样是不安全的 ，原因在于Java里面的运算并非原子操作，例如：
package com.company;
public class Main {
public static volatile int num = 0;
public static void increase() {
num++;
}
public static void main(String[] args) {
Thread[] threads = new Thread[10];
for (int i = 0; i < 10; i++) {
threads[i] = new Thread(new Runnable() {
@Override
public void run() {
for (int j = 0; j < 100; j++) {
increase();
}
}
});
threads[i].start();
}
while (Thread.activeCount() > 2) {
Thread.yield();
}
System.out.println(num);
}
}
⚡️ volatile关键字保证了num的值在取值时是正确的，但是在执行num+1的时候，其他线程可能已经把num值增大了，这样在+1后会把较小的数值同步回主内存之中；
⚡️ 由于volatile关键字只保证可见性，在不符合以下两条规则的运算场景中，我们仍然需要通过加锁 (synchronized或者lock)来保证原子性：
1、 运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值；
2、变量不需要与其他的状态变量共同参与不变约束；
⚡️ 如下代码这类场景就特别适合使用volatile来控制并发，当shutdown()方法被调用时，能保证所有线程中 执行的doWork()方法都立即停下来:
volatile boolean shutdownRequested;
public void shutdown() {
shutdownRequested = true;
}
public void work() {
while(!shutdownRequested) {
//do stuff
}
}
⚡️ 使用volatile变量的语义是禁止指令重排序，普通的变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序和程序代码中执行的顺序一致；
⚡️ volatile关键字禁止指令重排序有两层意思：
1、当程序执行到volatile变量的读操作或者写操作时，在其前面的操作的更改肯定全部已经进行， 且结果已经对后面的操作可见；在其后面的操作肯定还没有进行；
2、在进行指令优化时，不能将在对volatile变量访问的语句放在其后面执行，也不能把volatile变量 后面的语句放到其前面执行；
⚡️ 如：
//x、y为非volatile变量
//flag为volatile变量
x = 2; //语句1
y = 0; //语句2
flag = true; //语句3
x = 4; //语句4
y = -1; //语句5
⚡️ 由于flag变量为volatile变量，那么在进行指令重排序的过程的时候，不会将语句3放到语句1、语句2 前面，也不会将语句3放到语句4、语句5后面。但是要注意语句1和语句2的顺序、语句4和语句5的顺序 是不作任何保证的；
⚡️ 并且volatile关键字能保证，执行到语句3时，语句1和语句2必定是执行完毕了的，且语句1和语句2的 执行结果对语句3、语句4、语句5是可见的；
⚡️ 指令重排序：
Map configOptions;
char[] configText;
volatile boolean initialized = false;
//假设以下代码在线程A执行
//模拟读取配置文件信息，当读取完成后将initialized设置为true以通知其他线程配置可用
configOptions = new HashMap();
configText = readConfigFile(fileName);
processConfigOptions(configText,configOptions);
initialized = true;
//假设以下代码在线程B执行
//等待initialized为true，代表线程A已经把配置信息初始化完成
while(!initialized) {
sleep();
}
//使用线程A初始化好的配置信息
doSomethingWithConfig();
单例模式中的Double Check
☁️ 双重检验锁模式（double checked locking pattern），是一种使用同步块加锁的方法。程序员称其为双 重检查锁，因为会有两次检查 instance == null，一次是在同步块外，一次是在同步块内。为什么在同步 块内还要再检验一次？因为可能会有多个线程一起进入同步块外的 if，如果在同步块内不进行二次检验 的话就会生成多个实例了；
public static Singleton getSingleton(){
if(instance==null){
//Single Checked
synchronized (Singleton.class){
if(instance==null){
//Double Checked
instance=new Singleton();
}
}
}
return instance;
}
☁️ 以上代码在instance = new Singleton()处， 这并非是一 个原子操作，事实上在 JVM 中这句话大概做了下面 3 件事情。 给 instance 分配内存 调用 Singleton 的构造函数来初始化成员变量 将instance对象指向分配的内存空间（执行完这步 instance 就为非 null 了） 但是在 JVM 的即时编译器中存在指令重排序的优化。也就是说上面的第二步和第三步的顺序是不能 保证的，最终的执行顺序可能是 1-2-3 也可能是 1-3-2。如果是后者，则在 3 执行完毕、2 未执行之前， 被线程二抢占了，这时 instance 已经是非 null 了（但却没有初始化），所以线程二会直接返回 instance，然后使用，然后顺理成章地报错。 我们只需要将 instance 变量声明成 volatile 就可以了；
class Singleton{
// 确保产生的对象完整性
private volatile static Singleton instance = null;
private Singleton() {
}
public static Singleton getInstance() {
if(instance==null) {
// 检查对象是否初始化
synchronized (Singleton.class) {
if(instance==null) // 确保多线程情况下对象只有一个
instance = new Singleton();
}
}
return instance;
}
}