在并发编程中，我们通常要处理两个问题： 线程之前如何通信 与 线程之间如何同步 。
通信是指线程之间如何交换信息，通常的通信手段有：共享内存与消息传递（语言不同，通信机制不同，java使用的是共享内存的并发模型）
在共享内存的并发模型中，线程之间共享信息的公共状态，通过对信息公共状态的读 - 写来隐使地进行线程通信；而在消息传递的并发模型中，由于线程直接没有信息的公共状态，所以只能传递明确消息来显式地进行通信
同步是指控制不同线程的操作发生相对顺序的机制，在共享内存并发模型里，同步是显式进行的，程序员必须显式指定某个方法或某段代码需要在线程之间互斥执行。在消息传递的并发模型里，由于消息的发送必须在消息的接收之前，因此同步是隐式进行的。
由于java使用的是共享内存的并发模型，线程之间的通信总是隐式进行，整个通信过程对程序员完全透明，如果不理解隐式进行的线程之间通信的工作机制，很可能会遇到各种奇怪的内存可见性问题。
Java 内存模型的抽象
上面已经给出来了Java使用的是共享内存的并发模型，在前一篇JVM的内存结构中，只有两块内存是被线程之间共享的，堆和方法区，所以这两块区域也是作为共享内存的信息存储区，包括实例域、静态域和数组元素（本文使用“共享变量”这个术语代指实例域，静态域和数组元素）
Java 线程之间的通信由 Java内存模型（本文简称为JMM）控制，JMM决定一个线程对共享变量的写入何时对另一个线程可见。从抽象的角度来看，JMM定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存（main memory）中，每个线程都有一个私有的本地内存（localmemory），本地内存中存储了该线程以读 / 写共享变量的副本。本地内存是JMM的一个抽象概念，并不真实存在。它涵盖了缓存，写缓冲区，寄存器以及其他的硬件和编译器优化。Java 内存模型的抽象示意图如下：
线程 A 与线程 B 之间如要通信的话，必须要经历下面 2 个步骤（假设共享变量为X）：
1.线程 A 先更新本地内存X，然后把更新过的共享变量刷到主内存中去。
2.线程 B 到主内存中去读取线程 A 已更新过的共享变量X，同时更新本地内存中的共享变量（若已存在该共享变量）。
这个通信过程必须要经过主内存。JMM 通过控制主内存与每个线程的本地内存之间的交互，来为 java 程序员提供内存可见性保证。
重排序
在执行程序时为了提高性能，编译器和处理器常常会对指令做重排序。重排序分三种类型：
1.编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
2.指令级并行的重排序。现代处理器采用了指令级并行技术（Instruction-Level Parallelism， ILP）来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
3.内存系统的重排序。由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。
从 java 源代码到最终实际执行的指令序列，会分别经历下面三种重排序：
上述的 1 属于编译器重排序，2和3属于处理器重排序。这些重排序都可能会导致多线程程序出现内存可见性问题。对于编译器，JMM的编译器重排序规则会禁止特定类型的编译器重排序（不是所有的编译器重排序都要禁止）。对于处理器重排序，JMM 的处理器重排序规则会要求 java 编译器在生成指令序列时，插入特定类型的内存屏障（memory barriers，intel 称之为 memory fence）指令，通过内存屏障指令来禁止特定类型的处理器重排序（不是所有的处理器重排序都要禁止）。
说了这么多，举个例子：
int a = 1; // step 1
boolean b = true; // step 2
复制代码
正常情况下，step2不依赖step1的执行，所以step1跟step2会发生重排序。但是如果后面有这么一段代码：
if (b) {
int c = a; //step 3
System.out.println(c);
}
复制代码
假设一种情况，在编译器重排序下，线程1中，如果step2在step1之前执行，线程2走到了step3,并且step1还没有把a的值1刷新到主内存，此时C的值并不会是1，这就是编译器重排序引来的问题，前面也讲到处理器重排序插入特定类型的内存屏障，这就是来解决编译器重排序带来的问题。
内存屏障
现代的处理器使用写缓冲区来临时保存向内存写入的数据。写缓冲区可以保证指令流水线持续运行，它可以避免由于处理器停顿下来等待向内存写入数据而产生的延迟。但是对内存的读/写操作的执行顺序，不一定与内存实际发生的读 / 写操作顺序一致！
为了保证内存可见性，java编译器在生成指令序列的适当位置会插入内存屏障指令来禁止特定类型的处理器重排序。JMM 把内存屏障指令分为下列四类：
StoreLoad Barriers 是一个“全能型”的屏障，它同时具有其他三个屏障的效果。现代的多处理器大都支持该屏障（其他类型的屏障不一定被所有处理器支持）。执行该屏障开销会很昂贵，因为当前处理器通常要把写缓冲区中的数据全部刷新到内存中（buffer fully flush）。同时这个屏障也解决了上面的问题，给c赋值前必须要先去a，那么在取a之前插入LoadStore，就可以保证读取到最新的a值了！
需要java学习路线图的私信笔者“java”领取哦！另外喜欢这篇文章的可以给笔者点个赞同，关注一下，每天都会分享Java相关文章！还有不定时的福利赠送，包括整理的学习资料，面试题，源码等~~