可见性：
一个线程对共享变量值的修改，能够及时地被其他线程看到。
共享变量：
如果一个变量在多个线程的工作内存中都存在副本，那么这个变量就是这几个线程的共享变量。
Java内存模型（JMM）
Java内存模型（Java Memory Model）描述了Java程序中各种变量（线程共享变量）的访问规则，以及在JVM中将变量存储到内存和从内存中读取出变量这样的底层细节。
这里的变量指的是：共享变量
1、所有的变量都存储在主内存中
2、每个线程都有自己独立的工作内存，里面保存该线程使用到的变量的副本（主内存中该变量的一份拷贝）
X 变量就是共享变量：
可见性的两条规定：
1、线程对共享变量的所有操作都必须在自己的工作内存中进行，不能直接从主内存中读写
2、不同线程之间无法直接访问其他线程工作内存中的变量，线程间变量值的传递需要通过主内存来完成。
共享变量可见性实现的原理
线程1对共享变量的修改要想被线程2及时看到，必须要经过如下2个步骤：
1、把工作内存1中更新过的共享变量刷新到主内存中
2、将主内存中最新的共享变量的值更新到工作内存2中
示例：
1、首先主内存和工作内存中 X 的值都为0
2、线程1将自己工作内存中 X 的值修改为1，如图：
3、为了将线程1修改的值更新到线程2的工作内存中，需要经过两个步骤：首先是将线程1的工作内存中的值更新到主内存当中。
4、最后将主内存中 X 的值更新到线程2的工作内存当中。这就可以说线程1对 X 的修改被线程2及时的看到了。
要实现共享变量的可见性，必须保证两点：
1、线程修改后的共享变量值能够及时从工作内存刷新到主内存中
2、其他线程能够及时把共享变量的最新值从主内存更新到自己的工作内存中
可见性的实现方式
Java语言层面支持的可见性实现方式：
synchronized
volatile
synchronized实现可见性
synchronized能够实现：
- 原子性（同步）
- 可见性
JMM关于synchronized的两条规定：
1、线程解锁前，必须把共享变量的最新值刷新到主内存中
2、线程加锁时，将清空工作内存中共享变量的值，从而使用共享变量时需要从主内存中重新读取最新的值（注意：加锁与解锁需要是同一把锁）
从而就实现了线程解锁前对共享变量的修改在下次加锁时对其他线程可见
线程执行互斥代码的过程：
1.获得互斥锁
2.清空工作内存
3.从主内存拷贝变量的最新副本到工作内存
4.执行代码
5.将更改后的共享变量的值刷新到主内存
6.释放互斥锁
重排序
重排序：代码书写的顺序与实际执行的顺序不同，指令重排序是编译器或处理器为了提高程序性能而做的优化
1.编译器优化的重排序（编译器优化）
在单线程中，保证执行结果正确的情况下，改变代码的执行顺序。
2.指令级并行重排序（处理器优化）
3.内存系统的重排序（处理器优化）
指的是对读写缓存进行的优化
示例：重排序就是有可能出现下面的情况：
as-if-serial 语义
as-if-serial：无论如何重排序，程序执行的结果应该与代码顺序执行的结果一致（Java编译器、运行时和处理器都会保证Java在单线程下遵循as-if-serial语义）
单线程：第1、2行的顺序可以重排，但第3行不能
重排序不会给单线程带来内存可见性问题
但多线程中程序交错执行时，重排序可能会造成内存可见性问题
可见性分析(多线程的情况)：
执行顺序:
1.1->2.1->2.2—>1.2（线程的交叉执行）
result的值为：3
1.2->2.1->2.2—>1.1（重排序结合线程交叉执行）
result的值为：0
2.1和2.2之间也可以进行重排序，因为只要不是数据相互依存，都是不影响操作流程进行重排序的。如图：
导致共享变量在线程间不可见的原因：
1.线程的交叉执行
2.重排序结合线程交叉执行
3.共享变量更新后的值没有在工作内存与主内存间及时更新
安全的代码:（添加了sychronized）
synchronized解决方案：
1.线程的交叉执行 ——> 原子性，获得锁对象，每次只能让一个线程执行锁里面的代码。
2.重排序结合线程交叉执行 ——> 原子性。因为获得了锁对象，并且在单线程中，无论如何进行重排序，都不会影响最后的执行结果。
3.共享变量未及时更新 ——> 可见性 通过synchronized的可见性规范的规定来保证的：1、加锁前，清空工作内存中的共享变量，与主内存中的共享变量进行同步。2、释放锁前：将工作内存中的共享变量刷新到主内存当中。
上面的代码通过synchronized以及它的两条规范可以保证写操作和读操作或按照预期情况进行执行，保证共享变量的可见性。
但反过来说，不加synchronized也并不是一定会导致共享变量不可见。
因为不加synchronized，共享变量也可能可以在工作内存和主内存中进行同步。
这是因为编译器做了一些优化。它会去揣摩程序的意图，试图去给出一个正确的结果。因此可能程序运行很多次才会出现一次共享变量在工作内存和主内存中更新不及时的情况，但可能就是因为这样一次的情况，导致一些严重的后果。
volatile实现可见性
volatile关键字：
能够保证volatile变量的可见性
不能保证volatile变量复合操作的原子性
volatile如何实现内存可见性：
深入来说：通过加入内存屏障和禁止重排序优化来实现的。
- 对volatile变量执行写操作时，会在写操作后加入一条store屏障指令
强制的将写缓存中的内容强制刷新到主内存当中。并且还能防止将volatile之前的变量重排序到volatile写操作之后。
- 对volatile变量执行读操作时，会在读操作前加入一条load屏障指令
强制使缓冲区的缓存失效，使得读取volatile变量的时候，必须从主内存中进行读取，同样也能起到禁止指令重排序的效果。
通俗地讲：volatile变量在每次被线程访问时，都强迫从主内存中重读该变量的值。
而当该变量发生变化时，又会强迫线程将最新的值刷新到主内存。这样任何时刻，不同的线程总能看到该变量的最新值。
线程写volatile变量的过程：
1.改变线程工作内存中volatile变量副本的值
2.将改变后的副本的值从工作内存刷新到主内存
线程读volatile变量的过程：
1.从主内存中读取volatile变量的最新值到线程的工作内存中
2.从工作内存中读取volatile变量的副本
volatile不能保证volatile变量复合操作的原子性：
private int number=0；
number++；
上面的操作不是原子操作，因为number++可以分为三个步骤：
1.读取number的值
2.将number的值加1
3.写入最新的number的值
加入synchronized，变为原子操作
synchronized（this）{
number++；
}
这是因为synchronized会让number++的分解出来的三个步骤被一个线程执行完成以后，才会被另外一个线程去执行。而不会产生有几个线程同时交叉去执行这个三个步骤。
而把number变为volatile变量，无法保证原子性
private volatile int number=0；
假设此时number=5，线程 A 读取number的值，当线程 A 读取完毕以后，它的 CPU 使用权被剥夺了，从而导致 A 线程在读取 number 的过程被阻塞在这里了。
当 A 线程被阻塞的时候，B 线程得到了执行的机会，它从主内存中读取 number 的值，并且对 numebr 的值进行加1，并且将改变的值刷新到主内存当中。此时 B 线程的工作内存和主内存中 number 的值均为 6。
而线程 A 的工作内存中 number 的值还是5，然后它也再经过：对 numebr 的值进行加1，并且将改变的值刷新到主内存当中的操作。
此时经过两次 number++ 的操作，但线程 A 和线程 B 还有主内存中 number 的值还是为 6，从而导致实际输出与预想输出不一致的问题。
这个问题产生的原因是因为 volatile 不能保证操作的原子性。
解决方案：保证 number 自增操作的原子性：
使用synchronized关键字
使用ReentrantLock
（java.until.concurrent.locks包下）使用AtomicInterger
（vava.util.concurrent.atomic包下）
volatile适用场合
要在多线程中安全的使用volatile变量，必须同时满足：
1.对变量的写入操作不依赖其当前值
不满足：number++、count=count*5等
满足：boolean变量、记录温度变化的变量等
2.该变量没有包含在具有其他变量的不变式中
不满足：不变式 low
synchronized和volatile比较·
volatile不需要加锁，比synchronized更轻量级，不会阻塞线程，volatile 执行效率会更高。
从内存可见性角度将，volatile读相当于加锁（会将工作内存和主内存中的共享变量进行同步），volatile写相当于解锁（会将工作内存中的共享变量同步主内存当中）。
synchronized既能保证可见性，又能保证原子性，而volatile只能保证可见性，无法保证原子性。
总结
什么是内存可见性
Java内存模型（JMM）
实现可见性的方式：
synchronized 和 volatile
final也可以保证内存可见性，因为变量被定义为 final 以后是不能被修改的
synchronized和volatile实现内存可见性的原理
synchronized实现可见性
指令重排序
as-if-serial语义
- volatile实现可见性（通过 number++ 来举例）
volatile能够保证可见性
volatile不能保证原子性
- 问：即使没有保证可见性的措施，很多时候共享变量依然能够在主内存和工作内存见得到及时的更新？
答：一般只有在短时间内高并发的情况下（线程之间相互交错执行）才会出现变量得不到及时更新的情况，因为CPU在执行时会很快地刷新缓存，所以一般情况下很难看到这种问题。这种情况的出现是随机、不可预测的。
- 对64位（long、double）变量的读写可能不是原子操作：
Java内存模型允许JVM将没有被volatile修饰的64位数据类型的读写操作划分为两次32位的读写操作来进行
导致问题：有可能会出现读取到“半个变量”的情况
解决方法：加volatile关键字
- synchronized和volatile比较
volatile比synchronized更轻量级
volatile没有synchronized使用的广泛