JVM 逃逸分析优化

“Java 中的对象是否都分配在堆内存中？” ——“不尽然”

Java 中对象的创建一般会由堆内存去分配内存空间来进行存储，在堆内存空间不足的时候，GC 便会对堆内存进行垃圾回收，如果 GC 运行的次数过多，便会影响程序的性能,并且堆内存为所有线程共享，存再同步问题；所以 “逃逸分析” 由此诞生，它的目的就是判断哪些对象是可以存储在栈内存中而不用存储在堆内存中的，从而让其随着线程的消逝而消逝，进而减少了 GC 发生的频率，这也是常见的 JVM 优化技巧之一。

什么是逃逸分析

逃逸分析（Escape Analysis）简单来讲就是，Java Hotspot 虚拟机可以分析新创建对象的使用范围，并决定是否在 Java 堆上分配内存的一项技术。

在方法中创建对象之后，如果这个对象实例除了在方法体中还在其它地方被引用了，此时如果方法执行完毕，由于该对象有被引用，所以 GC 有可能是无法立即回收的，此时便成为 内存逃逸现象。

如何使用逃逸分析

开启逃逸分析：-XX:+DoEscapeAnalysis
关闭逃逸分析：-XX:-DoEscapeAnalysis
显示分析结果：-XX:+PrintEscapeAnalysis

逃逸分析的作用，就是筛选出没有发生逃逸的对象，从而对它们进行以下三方面的优化：

同步消除（锁消除）

因为同步锁是非常消耗性能的，所以当编译器确定一个对象没有发生逃逸时，它便会移除该对象的同步锁。

在 JDK1.8 中是默认开启的，但是要建立在已开启逃逸分析的基础之上。

开启锁消除：-XX:+EliminateLocks（JDK8默认开启）
关闭锁消除：-XX:-EliminateLocks

标量替换

首先要明白标量和聚合量，基础类型和对象的引用可以理解为标量，它们不能被进一步分解。而能被进一步分解的量就是聚合量，比如：对象。

对象是聚合量，它又可以被进一步分解成标量，将其成员变量分解为分散的变量，这就叫做标量替换。

这样，如果一个对象没有发生逃逸，那压根就不用创建它，只会在栈或者寄存器上创建它用到的成员标量，节省了内存空间，也提升了应用程序性能。

标量替换在 JDK1.8 中也是默认开启的，但是同样也要建立在已开启逃逸分析的基础之上。

开启标量替换：-XX:+EliminateAllocations
关闭标量替换：-XX:-EliminateAllocations
显示标量替换详情：-XX:+PrintEliminateAllocations

栈内存分配

栈内存分配很好理解，在上文中提过，就是将原本分配在堆内存上的对象转而分配在栈内存上，这样就可以减少堆内存的占用，从而减少 GC 的频次。

逃逸分析的优势

我们通过如下代码测试：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


/**
 * @author shanyutou.github.io
 * @ClassName: EscapeAnalysisTest
 * @Description: https://shanyutou.github.io 逸出分析测试
 * @date 2021/09/07
 * @Version: 1.0.0
 */


public class EscapeAnalysisTest {

    public static void main(String[] args) throws InterruptedException {
        long t1 = System.currentTimeMillis();
        for (int i = 0; i < 100000000; i++) {
            allot();
        }
        long t2 = System.currentTimeMillis();
        System.out.println(t2-t1);

        Thread.sleep(Integer.MAX_VALUE);
    }

    private static void allot() {
        Jet jet = new Jet();
//        synchronized (jet) {
//            jet.name = "jet Chen";
//        }
    }

    static class Jet {
        public String name;
    }

}

Step 1：测试开启逃逸

环境是 jdk1.8，默认开启了逃逸分析，所以直接运行，得到结果如下，程序耗时 3 毫秒，没有发生GC。

运行结果

Step 2：测试关闭逃逸

-XX:-DoEscapeAnalysis

得到结果如下，程序耗时 312 毫秒产生一次GC。

运行结果

所以，从代码的执行时间（3 毫秒 VS 400 毫秒），还是从GC分析，在上述场景下，开启逃逸分析是有正向益的。

Step 3：测试标量替换

-XX:+DoEscapeAnalysis -XX:+EliminateAllocations //耗时4 -XX:+DoEscapeAnalysis -XX:-EliminateAllocations //耗时306 -XX:-DoEscapeAnalysis -XX:+EliminateAllocations //耗时310 -XX:-DoEscapeAnalysis -XX:-EliminateAllocations //耗时310

在上述极端场景下，开启和关闭标量替换对于性能的影响也是满巨大的，另外，同时也验证了标量替换功能生效的前提是逃逸分析已经开启，否则没有意义。

Step 4：测试锁消除

测试锁消除，我们需要简单调整下代码，即给 allot() 方法中的内容加锁处理，如下：

1
2
3
4
5
6


private static void allot() {
    Jet jet = new Jet();
    synchronized (jet) {
        jet.name = "jet Chen";
    }
}

-XX:+DoEscapeAnalysis -XX:+EliminateLocks //耗时4 -XX:+DoEscapeAnalysis -XX:-EliminateLocks //耗时308 -XX:-DoEscapeAnalysis -XX:+EliminateLocks //耗时1492 -XX:-DoEscapeAnalysis -XX:-EliminateLocks //耗时1493 然后我们运行测试代码，测试结果也很明显，在上述场景下，开启和关闭锁消除对程序性能的影响也是巨大的。同时也验证了标量替换功能生效的前提是逃逸分析已经开启，否则没有意义。

总结

逃逸分析的原理理解起来其实很简单，但 JVM 在实际应用过程中，还是有诸多因素需要考虑的。

比如，逃逸分析不能在静态编译时进行，必须在 JIT 里完成。原因大致是：与 Java 的动态性有冲突。因为你可以在运行时，通过动态代理改变一个类的行为，此时，逃逸分析是无法得知类已经变化了。总之就是：因为只有当收集到足够的运行数据时，JVM 才可以更好地判断对象是否发生了逃逸。（参考大佬的解释：https://www.zhihu.com/ques….）

当然，逃逸分析并不是没有劣势的，因为逃逸分析是需要消耗一定的性能去执行分析的，所以说如果方法中的对象全都是处于逃逸状态，那么就没有起到优化的作用，从而就白白损失了这部分的性能消耗。