JVM内存模型(JMM)

JMM描述了Java多线程对共享变量的访问规则，以及在JVM中将变量存储到内存和从内存中读取变量这样的底层细节。

image.png

java内存模型如上图所示，每个线程都有自己独立的工作内存，当线程要访问内存中的变量时，会先将内存中的变量值复制到自己的工作内存，然后再访问；当线程要改变内存中的变量值时，也是先改变自己工作内存中副本的变量值，然后再刷新到内存中。当线程一改变了某个变量的值，而线程二想要访问该值时，可能会存在以下情况，即线程一的改变还没刷到内存，或者线程二里面缓存了老值，没有去内存中拿最新的值，这时就相当于线程一的改变对线程二不可见了。

Java通过以下几种方式来保证变量在线程之间的可见性：

• synchronized 当线程调用synchronized修饰的方法（代码块）时，会清空自己工作内存中所有的共享变量，并从内存中重新读取，这样就保证了可以看到别的线程做的改动；当退出synchronzied函数时，会将工作内存中所有更新过的共享变量的值回写到内存中，保证其他线程可以读到该线程更改的值。

• volatile volatile变量也能保证可见性，每次对volatile的读操作都会导致工作内存中的变量被内存中的最新值覆盖，对volatile的写操作，也会马上更新到主内存中去，这样就保证了每个线程对变量的改变对其他线程都是可见的。
  synchronized 和volatile的不同：
  既然synchronized可以实现可见性了为啥还引入volatile呢？两者虽然都能实现可见性，还是有不同之处的，synchronized需要对程序加锁，比较耗费资源；synchronized修饰的代码块，在一个线程退出去之前，其他线程是不能访问的，这样就提供了对某地代码的原子性操作。volatile则比较轻便，不需要加锁，但是不能保证操作的原子性，像i++，这种操作，它是无法保证结果正确的。

• final final修饰的变量不会在构造函数返回前被访问到，这样就可以保证final变量的不可变性。因为如果因为指令重排序，其他线程在final对象还没初始化完之前拿到了该变量的引用，有可能读到一个初始化之前的值，然后后面再读又读到一个初始化之后的值，造成的现象就是final修饰的变量值可变了。

• cocurrent包 java concurrent jar包提供了大量同步代码块的工具，方便我们正确的同步各个线程的执行。