JMM之指令重排以及案例分析

指令重排可能发生在三个地方:

1. 编译器编译时
2. CPU执行时¹
3. 内存级别

首先，我们需要简单了解一下什么是JMM

什么是MESI？
答：MESI是解决多核CPU下的缓存一致性的一个规范

然后我们通过一段代码来了解一下为什么会发生内存级别的指令重排，代码如下：

/**
 * 一共有两个线程，t1跑完再跑t2
 */
int a=0;
int b=0;
//t1跑这个方法
public void m1(){
	a=2;
	b=1;
}
//t2跑这个方法
public void m2(){
	while(b==1){
		break;
	}
	assert a==2;
}

接下来我们说一下业务场景

假定

1. t1执行m1()
2. t2执行m2()
3. t1跑在core1上，t2跑在core2上，a的缓存是在core2的cache上，b的缓存在core1的cache上

1. t1执行完了m1()
2. 因为a的缓存在core2的cache上，所以core1需要通知core2修改缓存，一般来说这里的通知是异步的，可能会有一个叫storebuffer的东西先存储要修改的东西
3. t2执行m2方法，由于b的缓存在core1的cache上，而且当前core2没有关于b的缓存，所以这个时候，core2会从core1的cache中读取到b的值，在某种程度上说，t1对b的修改对t2可见了。但是因为a的缓存是在core2的cache上的，此时core1对a的修改还没有同步到core2导致core2的缓存中a的值还是0，最终assert失败
4. 从结论上看，这就是一种内存级的指令重排

感觉好像表达的不太清晰，在晚上找了一个别的帖子，大家也可以参考：知乎：曹大谈内存重排
引申一个问题，既然有了MESI，为什么还会有可见性问题？²

案例分析

这是一个由于发生了指令重排而导致诡异问题的代码：

@SpringBootTest
class DemoApplicationTests12 {

    private static final Logger logger = LoggerFactory.getLogger(DemoApplicationTests12.class);
    int a = 0, b = 0;
    int x = 0, y = 0;

    /**
     * 指令重排
     */
    @Test
    public void test() throws InterruptedException {
        int count = 0;
        while (true) {
            a = 0;
            b = 0;
            x = 0;
            y = 0;
            Thread t1 = new Thread(() -> {
                a = 1;
                x = b;
            }, "t1");

            Thread t2 = new Thread(() -> {
                b = 1;
                y = a;
            }, "t2");

            t1.start();
            t2.start();

            t1.join();
            t2.join();
            
            logger.info("count=[{}],x=[{}],y=[{}]", count++, x, y);

            if (x == 0 && y == 0) {
                break;
            }
        }
    }
}

学习完并发编程之后，按照正常的思路看，上面的x/y一共有三种可能x=0&y=1、x=1&y=1、x=1&y=0。但是，实际上也可能出现x=0&y=0的情况。我们先看结果：

在跑了119360次之后，出现了x=0&y=0的情况。这种情况的出现证明了Java中确实存在指令重排。如果希望禁止指令重排，那么在abxy上需要加上关键字volatile。指令重排在Java的一种优化技术，目的是为了提高代码的执行效率。

案例一懒汉单例：

private static Object INSTANCE;
/**
 * 单例测试
 */
@Test
public Object getInstance(){
    if (INSTANCE == null) {
        synchronized (DemoApplicationTests12.class){
            if (INSTANCE == null) {
                INSTANCE = new Object();
            }
        }
    }
    return INSTANCE;
}

在懒汉单例中，如果INSTANCE没有被volatile修饰，那么通过getInstance就可能会获取到一个还没有初始化的对象。原因是在我们看来new是一个指令，但是对于jvm来说，new是需要很多步骤的。我们通常说的对象是一个被实例化之后的对象，而上面的INSTANCE=new Object之后，INSTANCE的值其实只是new出来的Object的地址而已，当我们判断INSTANCE是否为空时，也只是判断new Object是否已经被分配了地址，并不能确保Object已经被实例化完毕，所以为了保证先实例化再将地址赋值给INSTANCE，INSTANCE一定要用volatile修饰。

案例二死循环监听变量修改

public class Test2 {
    private static boolean FLAG = false;

    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(()->{
            while (!FLAG){
            //这行注释开启之后，t1线程就可以正常结束了
//                System.out.println(FLAG);
            }
            System.out.println(FLAG);
        },"t1");
        t1.start();
        TimeUnit.SECONDS.sleep(1);
        FLAG = true;
    }
}

上面的问题也经常是被说成是可见性的问题，通过给FLAG添加volatile修饰可以解决，但是需要注意的是，仅仅是System.out.print也可以解决这个问题，所以是这个的问题的本质不是可见性的问题，而是指令重排的问题，因为System.out.print中有synchronized从而阻止了指令重排，所以这个问题才被修复。 这个经典的问题可以参考R大的解释

---

1. CPU为了减少与缓存的交互，它会调整指令的执行顺序，从而发生指令重排比如a=1;b=2;a++;这样的代码在CPU执行时就可能发生指令重排 ↩︎

2. 答案是：MESI有一般是借助storeBuffer实现的，这种实现机制属于异步通知，感觉上像是最终一致性，而不是强一致性，所以在某个时刻还是会有可见性的问题。 ↩︎