在并发编程中，需要解决两个问题：线程间如何通信&线程间如何同步
线程同步：控制不同线程操作顺序的机制
解决这两个问题的方案有两种：共享内存&消息传递
共享内存：通过使用共享内存，隐式通信和同步；这里程序员必须显式的指定某个方法或代码块要在线程间互斥执行
消息传递：通过发消息来通信和同步；由于接收消息必须在发送消息之后，因此算是隐式的设置了同步
而JAVA采用的是共享内存模型。
JMM（Java内存模型）如下
如上图所示，JMM定义了线程和主内存之间的关系：线程之间的共享内存都存储在共享内存中，每个线程有自己的本地内存，本地内存存储了该线程以读/写共享变量的副本。
JMM是通过控制主内存与每个线程的本地内存之间的交互，来为java程序员提供内存可见性保证（例如有共享变量x=1，线程A和线程B都要修改这个共享变量，那么线程A将x设置为2，同时将x回写到共享内存，那么线程2拿到的就是x=2）
一、概念
说到JMM，就不得不提重排序、happends-before、as-if-serial
1、重排序
处理器对代码的执行顺序并非按照程序编写的源代码顺序执行，而是编译器和处理器会对源代码做重排序，处理器按照重排序后的结果执行，从而提高性能。
重排序分为三类：
编译器优化的重排序：编译器在不改变单线程程序语义的情况下重排序
指令并行重排序：如果不存在数据依赖，处理器可以重排序
内存系统重排序：处理器使用缓存和读写缓存区，这使得加载和存储操作看起来乱序。
从JAVA源代码到最终执行的指令序列所经历的重排序如下：
其中1是属于编译器的重排序，2和3属于处理器的重排序。
上述重排序中，对于内存系统的重排序，由于读写缓存只对当前线程可见，因此会造成多线程运行时的结果异常，因此处理器一般都只会允许对读写进行重排序。
2、happends-before
如果A happends-before于B，那么A的执行一定在B之前
3、as-if-serial
不管怎么重排序，单线程的执行结果不能被改变。所有的重排序都要遵循这个原则。
二、内存语义
但是如果要是多线程运行，那么由于指令重排和线程的读写缓存问题，会造成执行结果异常，因此就需要使用volatile、锁、final来处理
1、volatile的内存语义
可见性：对一个volatile修饰的变量的读，总能看到任意线程对这个volatile修饰的变量最后的写入
原子性：对于任意由volatile修饰的变量的读和写操作都是原子操作；但是对于volatile++这样的操作是非原子性的。
当写一个volatile修饰的变量时，JMM会把该线程对应的本地内存中的共享变量值刷新到内存中（只要有一个共享变量是volatile修饰，所有的共享变量都会被刷新到主内存中）
当读一个volatile修饰的变量时，JMM会把该线程对应的内存置为无效，线程将从主内存读取共享变量。
2、锁的内存语义
当锁释放时，JMM会把该线程对应的共享内存刷新到主内存中
当获取锁时，JMM会把该线程对应的本地内存置为无效
由以上两点可见，释放锁的内存语义和volatile的写拥有相同的内存语义，获取锁的内存语义和volatile的读有相同的内存语义。
3、final的内存语义
写final重排序：禁止把final域的写重排序到构造函数之外。这样可以确保在每次引用为任意线程可见之前，对象的final域已经正确初始化。
读final重排序：在一个线程中，初次读对象的引用和读该对象中的fianl域之间禁止重排序。
为什么要将fianl的写限制在构造方法之内：比如一个线程看到一个整形的final域为0（还未初始化，默认值），过一段时间去读取时，发现已经变为1（被初始化完成后的值），因此会造成获取final修饰的值不一致的问题，为了修复该问题，限制了final修饰的写必须在构造方法之内。
三、happends-before
happends-before是JMM最核心的概念，JMM为了平衡程序员（要求强内存模型，保证内存可见性）和处理器（要求若内存模型，处理器可以自行优化）的需求，设计了happends-before。
1、happends-before定义：
a、如果一个操作happends-before另一个操作，那么第一个操作的结果将对第二个操作结果可见，且第一个操作必须在第二个操作之前。
b、两个操作之间存在happend-before关系，并不意味着java平台具体的实现必须按照happends-before的顺序来执行。如果重排序的结果与happends-before的执行结果一致，那么重排序并不非法。
上述a是对程序员做出的承诺：如果A happends-before B，那么A的操作必须对B可见，且A的操作在B之前。
b是对处理器的约束原则：只要不改变程序运行结果，编译器和处理器可以自行优化（这里的程序指的是单线程程序或正确同步的多线程程序）
2、happends-before规则
a、程序顺序规则：一个线程中的每个操作，happends-before于该线程任意的后续操作
b、监视器锁规则：对于一个锁的解锁操作，happends-before于后续对该锁的加锁操作
c、volatile规则：对于一个volatile修饰的写，hanppends-before于对这个volatile修饰的读
d、传递性：如果A happends-before B，B happends-before C，那么A hanppends-before C
e、start()规则：如果线程A中调用了线程B的start方法，那么线程A中调用B线程的start方法的操作happends-before于线程B的任何操作
f、join()规则：如果线程A调用线程B的join方法，那么线程B中的任意操作happend-before于线程A从B.join()操作返回成功
四、双重检查锁定与延迟初始化
对于很多场景，都会延迟加载类，来降低初始化类和创建对象的开销，待使用时在延迟加载。
其实这里就是我们常说的单例模式。
public class InitDemo {
private static InitDemo instance; public static InitDemo getInstance(){
if(instance == null){
instance = new InitDemo();
}
return instance;
} public static InitDemo getInstance1(){
synchronized (InitDemo.class){
if(instance == null){
instance = new InitDemo();
}
}
return instance;
} public static InitDemo getInstance2(){
if(instance == null){
synchronized (InitDemo.class){
if(instance == null){
instance = new InitDemo();//有问题
}
}
}
return instance;
}
}
以上写法都是有问题的：
getInstance方法的问题：非线程安全，可能会创建多个实例（俗称：懒汉式）
getInstance1方法的问题：每次使用都加锁，性能消耗大
getInstance2方法的问题：同样是非线程安全的
解决方案：
解决方案一：使用volatile
public class InitDemo {
private volatile static InitDemo instance; public static InitDemo getInstance(){
if(instance == null){
synchronized (InitDemo.class){
if(instance == null){
instance = new InitDemo();//有问题
}
}
}
return instance;
}
}
由于使用了volatile，因此多线程（都是第一次访问）创建对象时，就可以保证线程安全。
解决方案二：基于类初始化方式
public class InitDemo {
private static class InitDemoFactory{
public static InitDemo instance = new InitDemo();
} public static InitDemo getInstance(){
return InitDemoFactory.instance;
}
}
优缺点对比：
基于类加载模式的方案，代码更简洁；但是只能对静态字段实现延迟加载
使用volatile，除了可以对静态字段做延迟加载外，还可以对实例字段实现延迟加载。
