关于jvm:一个-println-竟然比-volatile-还好使

34次阅读

共计 5466 个字符，预计需要花费 14 分钟才能阅读完成。

先点赞再看，养成好习惯

前两天一个小伙伴忽然找我求助，说筹备换个坑，最近在零碎学习多线程常识，但遇到了一个刷新认知的问题……

小伙伴：Effective JAVA 里的并发章节里，有一段对于可见性的形容。上面这段代码会呈现死循环，这个我能了解，JMM 内存模型嘛，JMM 不保障 stopRequested 的批改能被及时的观测到。

static boolean stopRequested = false;

public static void main(String[] args) throws InterruptedException {Thread backgroundThread = new Thread(() -> {
        int i = 0;
        while (!stopRequested) {i++;}
    }) ;
    backgroundThread.start();
    TimeUnit.MICROSECONDS.sleep(10);
    stopRequested = true ;
}

但奇怪的是在我加了一行打印之后，就不会呈现死循环了！难道我一行 println 能比 volatile 还好使啊？这俩也没关系啊

static boolean stopRequested = false;

public static void main(String[] args) throws InterruptedException {Thread backgroundThread = new Thread(() -> {
        int i = 0;
        while (!stopRequested) {
            
            // 加上一行打印，循环就能退出了！System.out.println(i++);
        }
    }) ;
    backgroundThread.start();
    TimeUnit.MICROSECONDS.sleep(10);
    stopRequested = true ;
}

我：小伙子八股文背的挺熟啊，JMM 张口就来。
​

我：这个……其实是 JIT 干的坏事，导致你的循环无奈退出。JMM 只是一个逻辑上的内存模型，外部有些机制是和 JIT 无关的

比方你第一个例子里，你用 -Xint 禁用 JIT，就能够退出死循环了，不信你试试？

小伙伴：卧槽，真的能够，加上 -Xint 循环就退出了，好神奇！JIT 是个啥啊？还能有这种效用？

JIT（Just-in-Time）的优化

家喻户晓，JAVA 为了实现跨平台，减少了一层 JVM，不同平台的 JVM 负责解释执行字节码文件。尽管有一层解释会影响效率，但益处是跨平台，字节码文件是平台无关的。

在 JAVA 1.2 之后，减少了 即时编译（Just-in-Time Compilation，简称 JIT）的机制，在运行时能够将执行次数较多的热点代码编译为机器码，这样就不须要 JVM 再解释一遍了，能够间接执行，减少运行效率。


​

但 JIT 编译器在编译字节码时，可不仅仅是简略的间接将字节码翻译成机器码，它在编译的同时还会做很多优化，比方循环展开、办法内联等等……
​

这个问题呈现的起因，就是因为 JIT 编译器的优化技术之一 – 表达式晋升（expression hoisting）导致的。

表达式晋升（expression hoisting）

先来看个例子，在这个 hoisting 办法中，for 循环里每次都会定义一个变量 y，而后通过将 x*y 的后果存储在一个 result 变量中，而后应用这个变量进行各种操作

public void hoisting(int x) {for (int i = 0; i < 1000; i = i + 1) {
        // 循环不变的计算 
        int y = 654;
        int result = x * y;
        
        // ...... 基于这个 result 变量的各种操作
    }
}

然而这个例子里，result 的后果是固定的，并不会跟着循环而更新。所以齐全能够将 result 的计算提取到循环之外，这样就不必每次计算了。JIT 剖析后会对这段代码进行优化，进行表达式晋升的操作：

public void hoisting(int x) {
    int y = 654;
    int result = x * y;
    
    for (int i = 0; i < 1000; i = i + 1) {// ...... 基于这个 result 变量的各种操作}
}

这样一来，result 不必每次计算了，而且也齐全不影响执行后果，大大晋升了执行效率。

留神，编译器更喜爱局部变量，而不是动态变量或者成员变量；因为动态变量是“逃逸在外的”，多个线程都能够拜访到，而局部变量是线程公有的，不会被其余线程拜访和批改。
​

编译器在解决动态变量 / 成员变量时，会比拟激进，不会轻易优化。
​

像你问题里的这个例子中，stopRequested就是个动态变量，编译器本不应该对其进行优化解决；

static boolean stopRequested = false;// 动态变量

public static void main(String[] args) throws InterruptedException {Thread backgroundThread = new Thread(() -> {
        int i = 0;
        while (!stopRequested) {
            // leaf method
            i++;
        }
    }) ;
    backgroundThread.start();
    TimeUnit.MICROSECONDS.sleep(10);
    stopRequested = true ;
}

但因为你这个循环是个 leaf method，即没有调用任何办法，所以在循环之中不会有其余线程会观测到 stopRequested 值的变动。那么编译器就冒进的进行了 表达式晋升 的操作，将 stopRequested 晋升到表达式之外，作为循环不变量（loop invariant）解决：

int i = 0;

boolean hoistedStopRequested = stopRequested;// 将 stopRequested 晋升为局部变量
while (!hoistedStopRequested) {i++;}

这样一来，最初将 stopRequested赋值为 true 的操作，影响不了晋升的 hoistedStopRequested 的值，天然就无奈影响循环的执行了，最终导致无奈退出。
​

至于你减少了 println 之后，循环就能够退出的问题。是因为你这行 println 代码影响了编译器的优化。println 办法因为最终会调用 FileOutputStream.writeBytes 这个 native 办法，所以无奈被内联优化（inling）。而未被内敛的办法调用从编译器的角度看是一个“full memory kill”，也就是说 副作用不明 、必须对内存的读写操作做 激进解决。
​

在这个例子里，下一轮循环的 stopRequested 读取操作按程序要产生在上一轮循环的 println 之后。这里“激进解决”为：就算上一轮我曾经读取了 stopRequested 的值，因为通过了一个 ** 副作用不明 ** 的中央，再到下一次拜访就必须从新读取了。
​

所以在你减少了 prinltln 之后，JIT 因为要激进解决，从新读取，天然就不能做下面的 表达式晋升 优化了。
​

以上对 表达式晋升 的解释，总结摘抄自 R 大 的知乎答复。R 大，行走的 JVM Wiki！
​

我：“这下明确了吧，这都是 JIT 干的坏事，你要是禁用 JIT 就没这问题了”

小伙伴：“卧槽🐂🍺，一个简略的 for 循环也太多机制了，没想到 JIT 这么智能，也没想到 R 大这么🐂🍺”

小伙伴：“那 JIT 肯定很多优化机制吧，除了这个表达式晋升还有啥？”

我：我也不是搞编译器的……哪理解这么多，就晓得一些罕用的，简略给你说说吧

表达式下沉（expression sinking）

和表达式晋升相似的，还有个表达式下沉的优化，比方上面这段代码：

public void sinking(int i) {
    int result = 543 * i;

    if (i % 2 == 0) {// 应用 result 值的一些逻辑代码} else {// 一些不应用 result 的值的逻辑代码}
}

因为在 else 分支里，并没有应用 result 的值，可每次不论什么分支都会先计算 result，这就没必要了。JIT 会把 result 的计算表达式挪动到 if 分支里，这样就防止了每次对 result 的计算，这个操作就叫表达式下沉：

public void sinking(int i) {if (i % 2 == 0) {
        int result = 543 * i;
        // 应用 result 值的一些逻辑代码
    } else {// 一些不应用 result 的值的逻辑代码}
}

JIT 还有那些常见优化？

除了下面介绍的表达式晋升 / 表达式下沉以外，还有一些常见的编译器优化机制。

循环展开（Loop unwinding/loop unrolling）

上面这个 for 循环，一共要循环 10w 次，每次都须要查看条件。

for (int i = 0; i < 100000; i++) {delete(i);
}

在编译器的优化后，会删除肯定的循环次数，从而升高索引递增和条件查看操作而引起的开销：

for (int i = 0; i < 20000; i+=5) {delete(i);
    delete(i + 1);
    delete(i + 2);
    delete(i + 3);
    delete(i + 4);
}

除了循环展开，循环还有一些优化机制，比方循环剥离、循环替换、循环决裂、循环合并……

内联优化（Inling）

JVM 的办法调用是个栈的模型，每次办法调用都须要一个压栈（push）和出栈（pop）的操作，编译器也会对调用模型进行优化，将一些办法的调用进行内联。
​

内联就是抽取要调用的办法体代码，到以后办法中间接执行，这样就能够防止一次压栈出栈的操作，晋升执行效率。比方上面这个办法：

public  void inline(){
    int a = 5;
    int b = 10;
    int c = calculate(a, b);
    
    // 应用 c 解决……
}

public int calculate(int a, int b){return a + b;}

在编译器内联优化后，会将 calculate 的办法体抽取到 inline 办法中，间接执行，而不必进行办法调用：

public  void inline(){
    int a = 5;
    int b = 10;
    int c = a + b;
    
    // 应用 c 解决……
}

不过这个内联优化是有一些限度的，比方 native 的办法就不能内联优化

提前置空

来先看一个例子，在这个例子中 was finalized! 会在 done.之前输入，这个也是因为 JIT 的优化导致的。

class A {
    // 对象被回收前，会触发 finalize
    @Override protected void finalize() {System.out.println(this + "was finalized!");
    }

    public static void main(String[] args) throws InterruptedException {A a = new A();
        System.out.println("Created" + a);
        for (int i = 0; i < 1_000_000_000; i++) {if (i % 1_000_00 == 0)
                System.gc();}
        System.out.println("done.");
    }
}

// 打印后果
Created A@1be6f5c3
A@1be6f5c3 was finalized!//finalize 办法输入
done.

从例子中能够看到，如果 a 在循环实现后曾经不再应用了，则会呈现先执行 finalize 的状况；尽管从对象作用域来说，办法没有执行完，栈帧并没有出栈，然而还是会被提前执行。
​

这就是因为 JIT 认为 a 对象在循环内和循环后都不会在应用，所以提前给它置空了，帮忙 GC 回收；如果禁用 JIT，那就不会呈现这个问题……
​

这个提前回收的机制，还是有点危险的，在某些场景下会引起 BUG，比方《一个 JDK 线程池 BUG 引发的 GC 机制思考》

HotSpot VM JIT 的各种优化项

下面只是介绍了几个简略罕用的编译优化机制，JVM JIT 更多的优化机制能够参考上面这个图。这是 OpenJDK 文档中提供的一个 pdf 资料，外面列出了 HotSpot JVM 的各种优化机制，相当多……

如何防止因 JIT 导致的问题？

小伙伴：“JIT 这么多优化机制，很容易出问题啊，我平时写代码要怎么避开这些呢”
​

平时在编码的时候，不必刻意的去关怀 JIT 的优化，就比方下面那个 println 问题，JMM 原本就不保障批改对其余线程可见，如果依照标准去加锁或者用 volatile 润饰，基本就不会有这种问题。
​

而那个提前置空导致的问题，呈现的几率也很低，只有你标准写代码根本不会遇到的。

我：所以，这不是 JIT 的锅，是你的……

小伙伴：“懂了，你这是说我菜，说我代码写的屎啊”

总结

在日常编码过程中，不必刻意的猜想 JIT 的优化机制，JVM 也不会残缺的通知你所有的优化。而且这种货色不同版本成果不一样，就算搞明确了一个机制，可能到下个版本就齐全不一样了。
​

所以，如果不是搞编译器开发的话，JIT 相干的编译常识，作为一个常识储备就好。
​

也不必去猜想 JIT 到底会怎么优化你的代码，你（可能）猜不准……

参考

  • JSR-133 Java Memory Model and Thread Specification 1.0 Proposed Final Draft
  • Oracle JVM Just-in-Time Compiler (JIT)
  • JVM JIT-compiler overview – Vladimir Ivanov HotSpot JVM Compiler Oracle Corp.
  • JVM JIT optimization techniques – part 2
  • The Java platform – WikiBook
  • R 大的知乎百科

原创不易，禁止未受权的转载。如果我的文章对您有帮忙，就请点

正文完
jvm
发表至： jvm
2021-06-01
 0
关于jvm:JVM-调优流程
关于jvm:JVM7线上图形化工具
关于JVM:面试知识点学习4反射机制类加载时的内存布局
关于jvm:JVM-运行时数据区域