如果说造成线程不安全的情况是来源有时序性(代码优化)，可见性(缓存一致性)，原子性(线程切换)。
那么最简单的优化方式就是禁用缓存和编译优化。这样可以直接解决问题，就是代码的性能会相对的下降。合理的方案应该是按需禁用缓存以及编译优化。
这样的话就可以分治不同的代码，有并发的代码进行调整，没有并发的代码则可以继续之前的。
Java模型中规范的三个解决这类问题的关键字是 volatile，synchronized和final，以及Happens-Before规则。
volatile在C语言里面也有，本质是禁用高速缓存(强制刷新)。
class VolatileExample {
int x = 0;
volatile boolean v = false;
public void writer() {
x = 42;
v = true;
}
public void reader() {
if (v == true) {
// 这里x会是多少呢？
}
}
}
这个代码在Java1.5之前可能为0，问题在于x可能被缓存了，导致另外一个线程虽然看到了v=true，但是x依然是0；
在java1.5成功解决了这个问题，Happens-Before规则的含义就是前面的操作对后面的操作是可见的，也就是做线程A进行了读写操作，那么B肯定能看到A读写之后的最新的变量的值。
Happens-Before的6大规则就是：
1.程序的顺序性规则：程序前面对某个变量的修改对后续的程序是可见的，例如volatile修改了v，v对后面的线程二是可见的
2.volatile变量规则：在新的内存模型中，volatile周围的普通字段不能随便重排；编译器生成字节码时，会在volatile写操作的前面和后面分别插入内存屏障（StoreStore屏障｜volatile写｜StoreLoad屏障），其中StoreStore屏障：禁止上面的普通写和下面的volatile写重排序；StoreLoad屏障：防止上面的volatile写与下面可能有的volatile读/写重排序。
3.传递性：这条规则是指如果 A Happens-Before B，且 B Happens-Before C，那么 A Happens-Before C。
花里胡哨的，其实就是如果你用了volatile，volatile会导致x的可见性需要保障，那么后面线程读的时候（线程读的时候需要对volatile进行判断），就会从主存中进行读取。边界就是只要给volatile赋值成功，那么这个赋值语句之前所有代码的执行结果都对其他线程可见 所以应该是将有volitile执行结果的cpu全部缓存强制刷新到内存，然后强制将其它cpu中的全部缓存和内存同步。
4.管程中锁的规则：管程(monitor)只是保证了同一时刻只有一个进程在管程内活动,即管程内定义的操作在同一时刻只被一个进程调用(由编译器实现).
管程(monitor)只是保证了同一时刻只有一个进程在管程内活动,即管程内定义的操作在同一时刻只被一个进程调用(由编译器实现).管程中的锁在 Java 里是隐式实现的，例如下面的代码，在进入同步块之前，会自动加锁，而在代码块执行完会自动释放锁，加锁以及释放锁都是编译器帮我们实现的。
synchronized (this) { //此处自动加锁
// x是共享变量,初始值=10
if (this.x < 12) {
this.x = 12;
}
} //此处自动解锁
5. 线程 start() 规则：指主线程 A 启动子线程 B 后，子线程 B 能够看到主线程在启动子线程 B 前的操作。
Thread B = new Thread(()->{
// 主线程调用B.start()之前
// 所有对共享变量的修改，此处皆可见
// 此例中，var==77
});
// 此处对共享变量var修改
var = 77;
// 主线程启动子线程
B.start();
6. 线程 join() 规则:这条是关于线程等待的。它是指主线程 A 等待子线程 B 完成（主线程 A 通过调用子线程 B 的 join() 方法实现），当子线程 B 完成后（主线程 A 中 join() 方法返回），主线程能够看到子线程的操作。当然所谓的“看到”，指的是对共享变量的操作。
Thread B = new Thread(()->{
// 此处对共享变量var修改
var = 66;
});
// 例如此处对共享变量修改，
// 则这个修改结果对线程B可见
// 主线程启动子线程
B.start();
B.join()
// 子线程所有对共享变量的修改
// 在主线程调用B.join()之后皆可见
// 此例中，var==66
Java 的内存模型是并发编程领域的一次重要创新，之后 C++、C#、Golang 等高级语言都开始支持内存模型。Java 内存模型里面，最晦涩的部分就是 Happens-Before 规则了，Happens-Before 规则最初是在一篇叫做 Time, Clocks, and the Ordering of Events in a Distributed System 的论文中提出来的，在这篇论文中，Happens-Before 的语义是一种因果关系。在现实世界里，如果 A 事件是导致 B 事件的起因，那么 A 事件一定是先于（Happens-Before）B 事件发生的，这个就是 Happens-Before 语义的现实理解。在 Java 语言里面，Happens-Before 的语义本质上是一种可见性，A Happens-Before B 意味着 A 事件对 B 事件来说是可见的，无论 A 事件和 B 事件是否发生在同一个线程里。例如 A 事件发生在线程 1 上，B 事件发生在线程 2 上，Happens-Before 规则保证线程 2 上也能看到 A 事件的发生。Java 内存模型主要分为两部分，一部分面向你我这种编写并发程序的应用开发人员，另一部分是面向 JVM 的实现人员的，我们可以重点关注前者，也就是和编写并发程序相关的部分，这部分内容的核心就是 Happens-Before 规则。
有一个共享变量 abc，在一个线程里设置了 abc 的值 abc=3，你思考一下，有哪些办法可以让其他线程能够看到abc==3？
1.join 2.volatile 3.synchronized
happend-before 规则理论上还有两个
线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测到是否有中断发生。
对象终结规则：一个对象的初始化完成(构造函数执行结束)先行发生于它的finalize()方法的开始。
Java内存模型底层怎么实现的？主要是通过内存屏障(memory barrier)禁止重排序的，即时编译器根据具体的底层体系架构，将这些内存屏障替换成具体的 CPU 指令。对于编译器而言，内存屏障将限制它所能做的重排序优化。而对于处理器而言，内存屏障将会导致缓存的刷新操作。比如，对于volatile，编译器将在volatile字段的读写操作前后各插入一些内存屏障。
为什么定义Java内存模型？现代计算机体系大部是采用的对称多处理器的体系架构。每个处理器均有独立的寄存器组和缓存，多个处理器可同时执行同一进程中的不同线程，这里称为处理器的乱序执行。在Java中，不同的线程可能访问同一个共享或共享变量。如果任由编译器或处理器对这些访问进行优化的话，很有可能出现无法想象的问题，这里称为编译器的重排序。除了处理器的乱序执行、编译器的重排序，还有内存系统的重排序。因此Java语言规范引入了Java内存模型，通过定义多项规则对编译器和处理器进行限制，主要是针对可见性和有序性。