背景

public class TestThread {
    static int i = 0;

    public static void main(String[] args) throws Exception {
        new Thread(() -> {
            System.out.println("exec");
            while (true) {
                if (i == 2) {
                    break;
                }
            }
            System.out.println("thread done");
        }).start();
        Thread.sleep(1000);
        new Thread(() -> {
            while (true){
                i = 2;
            }
        }).start();

    }
}

这段代码中过，thread done，是一定不会输出的，第一反应应该是原因是cpu缓存，增加volatile就可以输出，原因真的是cpu缓存吗？那么单核CPU会有这个问题吗？实际上单核CPU也会又这个问题，thread done也不会输出

这个问题是由于java内存模型导致的，和CPU内存无关，只不过两者有相似的地方

什么是JMM

image.png

JMM是java内存模型，与JVM没有关系，JMM三大特性，原子性，可见性，有序性，每个线程会把共享变量的副本拷贝到每个线程的本地内存中，所以不一致是JMM上的不一致，在执行i = 2是，CPU其实已经把缓存进行了更新，不过由于Java内存模型的原因更新的只是每个线程的本地变量，并没有更新主内存的变量，同时没有通知其他线程失效缓存而

CPU缓存模型及一致性解决方式

image.png

目前基本上服务器为了提高运算能力，都会使用多核CPU，同时由于CPU处理和内存读取的速度相差太大，所以在内存和CPU中间加了3层缓存，这样的话就会存在缓存一致性的问题，比如，cpu1和cpu2同时读取了变量a的值，如果这个时候cpu1把变量a的值修改了，其他cpu下次读取a的时候由于还是从3层缓存中读取，所以还会读取到老的值

为了解决这个问题，通过MESI模型来进行解决，大致的思路是，共享的时候为share状态，当某个cpu要修改的时候改为Exclusive状态即独享状态，同时将通知其他cpu将这个地址的内存信息改为Invalid状态，Invalid状态的时候cpu就会从内存中读取数据，修改后改为Modified状态即修改状态，当某个cpu再次读取的时候，另一个cpu会把Modified状态的内存信息刷到磁盘，同时告诉此cpu的修改后的值（由于cpu之间通信是同步的会严重影响cpu的性能，所以一般会采用MESI的变种模型，增加异步，为了解决异步的问题，这样就有了内存屏障等措施来保证cpu的可以见和重排序的问题）

所以，cpu进行值修改时，对于其他cpu是可见的，上述的问题并不是cpu缓存导致的

JMM

JMM和cpu内存类似，都是有各自的缓存，但是他是CPU上层的模型，即不管是单核还是多核，他就是他，与谁都没有关系，所以导致CPU在修改完成后虽然已经同步给其他cpu同时刷新的内存（线程的本地内存），但是由于JMM的特性导致其他线程读到的还是旧数据，所以为了解决JMM的可见性问题，以及重排序问题，就需要使用volatile或者synchronized来解决，所以也就有了happen-before原则来保证JMM的有序性

分析

JMM中本地内存并不是真实存在的（存在的话回收，内存占用都不好管理）CPU有一致性协议，各个CPU上的缓存都是一致的，为什么上面的代码循环不会退出？
因为即时编译器的原因，可以使用HSDIS查看汇编代码，会发现加volatile和不加volatile的汇编代码不一样

带有volatile的汇编代码：

image.png

不带volatile的汇编代码：

image.png

所以可以看到，带有volatile的每次比较会从内存中取值，不带的会就回死循环