JMM(Java内存模型)

首先我们看下执行a+b这个操作需要几步：
1.从内存中取出a
2.从内存中取出b
3.执行a+b
CPU读取一次内存的响应时间大概为100纳秒，执行一条指令的时间大概为0.X(零点几)纳秒，也就是说我们上面执行a+b操作百分之99.99%的时间都是在读取内存，为了提高速度，所以出现了JMM。

JMM就是每个线程存在自己的工作内存(抽象概念，并没有实际的硬件存储)，分为了很多级别L1、L2、L3等。级别越小，读取速度越快，空间越小。

线程不可以直接操作主内存(或叫堆内存，可以看成内存条)，需要将数据读取到自己的工作内存中进行操作，然后写回主内存。

volatile（可见性）

可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。

由于线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存中的变量，那么对于共享变量V，它们首先是在自己的工作内存，之后再同步到主内存。可是并不会及时的刷到主存中，而是会有一定时间差。很明显，这个时候线程 A 对变量 V 的操作对于线程 B 而言就不具备可见性了 。

volatile关键字当对变量进行操作的时候，会强制从内存中重新获取一次最新值，操作完成后会第一时间写入到主内存中，这样就保证了共享对象的可见性。

示例一：
我们创建两个线程A和B执行count = count + 1这个操作。

1. 线程A从主内存中获取count=0到工作内存。
2. 这时发生上下文切换，线程B执行，从主内存中获取count=0到工作内存，执行count+1，然后写入主内存。
   3.这时再次发生上下文切换，注意线程A的count的值是0，执行count+1操作，将count = 1写入主内存。
   这时问题就出现了，虽然count进行了两次累加操作，值应该是2，但是值却是1。

我们给count加上volatile关键字，这时在步骤3进行count+1操作的时候会重新从主内存中获取值，这时获取到的值就是1了，看起来上面的问题就解决了，可是真的解决吗？答案是否定的，为什么？我们继续看

示例二

1. 线程A从主内存中获取count=0到工作内存，然后进行count + 1操作，注意这里可能count+1操作没执行完，或者还没写入主内存。
2. 这时发生上下文切换，线程B执行，因为步骤1count + 1的操作还没有写入到主内存，所以线程B从主内存中获取到的count值还是0，执行count+1后count=1，然后写入主内存。
   3.这时再切换到线程A，注线程A继续执行，将count = 1写入主内存。

我们发现问题还是继续存在的，这是为什么，因为count + 1不具备原子性，也就是说这个操作是可以被打断的，所以要解决这个问题，我们可以采用加锁的方式，或者AtomicInteger，前面的文章有介绍。

volatile变量自身具有下列特性：

可见性。对一个volatile变量的读，总是能看到（任意线程）对这个volatile变量最后的写入。
原子性：对任意单个volatile变量的读/写具有原子性，但类似于volatile++这种复合操作不具有原子性。

可见性可以认为是jdk提供的最轻量级的原子性 没有符合累加操作的时候可以用 例如
1、一个线程写 多个线程读
2、无关联写操作 和原值无关联 例如 conut = 6 conut = 5 而count = count + 1 则不行

volatile的实现原理

有volatile变量修饰的共享变量进行写操作的时候会使用CPU提供的Lock前缀指令

1. 将当前处理器缓存行的数据写回到系统内存。 (就是说强制将工作线程的缓存数据刷新到主内存中)
2. 这个写回内存的操作会使在其他CPU里缓存了该内存地址的数据无效。（就是使其它缓存的数据地址失效，然后重新从主内存中获取）