别让Java对象逃逸（Object Escape）

翻译：吴嘉俊，叩丁狼高级讲师 

关于逃逸分析

我在开源项目Speedment的开发过程中，我和项目的贡献者都意识到我们的代码不仅要良好并易懂，同时还要有较高的性能，否则他们很容易转向使用其他的解决方案。

逃逸分析（Escape Analysis）允许我们在写出性能较好的代码的同时，能通过恰当的抽象，保证良好的代码风格。

逃逸分析（简写为“EA”）允许java编译器在多种情况下优化我们的代码。请考虑一下代码：

public class Point {  

    private final int x, y;  

    public Point(int x, int y) {  
        this.x = x;  
        this.y = y;  
    }  

    @Override  
    public String toString() {  
        final StringBuilder sb = new StringBuilder()  
                .append("(")  
                .append(x)  
                .append(", ")  
                .append(y)  
                .append(")");  
        return sb.toString();  
    }  

}
           

每一次我们调用Point::toString方法的时候，都会创建一个新的StringBuilder对象。这个创建出来的对象，对于外面的方法或者运行当前代码的其他线程都是不可见的（因为其他线程只能看到自己的StringBuilder版本）。

所以，当我们大量的调用了这个方法之后，会出现大量的StringBuilder对象么？不会。因为逃逸分析的作用，编译器会可以在栈上为StringBuilder分配空间。所以，当我们的方法返回的时候，对象会自动的被删除，栈上的指针会自动的回退到这个方法调用之前的值。

逃逸分析在Java中已经存在了很久了。在最开始的时候，我们需要在命令行选项中手动开启逃逸分析（通过-XX:+DoEscapeAnalysis开启），现在它已经作为默认开启的选项了。Java8在以前的Java基础上，对于逃逸分析，又有了新的增强。

逃逸分析如何工作

基于逃逸分析，一个对象会可能会被用三种逃逸状态标记：

• 全局级别逃逸：一个对象可能从一个方法或者当前线程中逃逸。再明确一点，如果一个对象被作为一个方法的返回值，那么对象被标记为全局逃逸状态。如果一个对象作为类静态字段(static field)或者类字段(field)，同样会被标记为全局逃逸状态。另外，如果我们复写了一个方法的finalize()方法，那么这个类的对象都会被标记为全局逃逸状态并且一定会放在堆内存中，这也符合情理，因为这些对象需要对于JVM的finalizer必须是可见的（所以发生逃逸了）。当然，还有其他的一些情况也会让对象标记为全局逃逸状态。
• 参数级别逃逸：如果一个对象被作为参数传递给一个方法，但是在这个方法之外无法访问或者对其他线程不可见，这个对象标记为参数级别逃逸。
• 无逃逸状态：一个对象不会产生逃逸

标记为全局级别逃逸或者参数级别逃逸的对象必须在堆中分配空间，但是参数级别逃逸是可能在内存中去掉对象同步锁的，因为上面已经解释，参数级别逃逸对象不会被其他线程访问。

无逃逸状态的对象的内存分配会更加自由，可能会在栈上分配，也可能会在堆上分配。事实上，在某些情况下，甚至根本不会去创建一个对象，而直接使用该对象的标量值代替，比如仅仅在栈上创建一个int，去代替一个Integer对象。因为只有一个线程可以访问该对象，所以对象上的同步锁自然会被去掉。例如，我们使用无逃逸状态的StringBuffer（较之StringBuilder，StringBuffer是线程安全的，所有方法都是synchronized），那么这种情况下，所有方法的同步锁都会被去掉，提高执行效率。

EA目前只在C2 HotSpot编译器下有用，所以请确保我们运行在-server模式下。

为什么它很重要

理论上来说，无逃逸状态对象可以直接在栈上分配内存，甚至直接在CPU寄存器中分配空间，以提供非常快速的执行。

当我们在堆上分配空间的时候，因为对象可能会被分配在不连续的彼此远离的堆地址上，这种地址分配方式会非常快的耗尽我们L1 CPU缓存，性能会受到影响。而当使用EA通过栈来分配空间，在大部分情况下，使用的都是L1缓存中已经分配的空间。所以，EA在栈上分配空间，会在数据存储位置分配上面更加优化。这对于性能是有益的。

当我们使用EA在栈上分配空间，垃圾回收器的工作量会极大减低，这可能是EA带来的一个最大的性能提升点。因为每一次在垃圾回收执行的时候，会对堆进行一次完整的扫描，这对于我们的CPU性能，和CPU缓存的消耗是非常大的。更不用说，如果服务器部分虚拟内存在独立的存储设备上，过于频繁的GC带来的绝对是灾难性的影响。

EA带来的最重要的提升不仅仅体现在性能上。EA允许我们使用本地抽象（local abstractions），比如Lambdas, Functions, Streams, Iterators等等。依赖于EA，我们能轻松的写出既易读，性能又高的代码，让代码专注于我们在做的事情。

一个例子

public class Main {  

    public static void main(String[] args) throws IOException {  
        Point p = new Point(100, 200);  

        sum(p);  
        System.gc();  
        System.out.println("Press any key to continue");  
        System.in.read();  
        long sum = sum(p);  

        System.out.println(sum);  
        System.out.println("Press any key to continue2");  
        System.in.read();  

        sum = sum(p);  

        System.out.println(sum);  
        System.out.println("Press any key to exit");  
        System.in.read();  

    }  

    private static long sum(Point p) {  
        long sumLen = 0;  
        for (int i = 0; i < 1_000_000; i++) {  
            sumLen += p.toString().length();  
        }  
        return sumLen;  

    }  

}
           

上面的代码中，创建了一个Point实例，并且通过调用sum方法，大量的调用Point对象的toString()方法。我们分了三个阶段，首先，执行一次sum，然后立刻GC掉所有创建的对象，接下来两次我们又调用两次sum方法，但没有从堆中删除任何东西，我们来验证一下每一步执行之后堆的状态。

我们使用如下的参数来执行应用，我们就可以看到在JVM中发生了什么：

-server
-XX:BCEATraceLevel=3
-XX:+PrintCompilation
-XX:+UnlockDiagnosticVMOptions
-XX:+PrintInlining
-verbose:gc
-XX:MaxInlineSize=256
-XX:FreqInlineSize=1024
-XX:MaxBCEAEstimateSize=1024
-XX:MaxInlineLevel=22
-XX:CompileThreshold=10
-Xmx4g
-Xms4g
           

大量的运行参数来更清楚的让我们看到到底发生了什么。

当第一步调用完成，我们来看看堆的使用（在System.gc()执行之后）

pemi$ jps | grep Main
50903 Main
pemi$ jps | grep Main
50903 Main
pemi$ jmap -histo 50903 | head
 num     #instances         #bytes  class name

----------------------------------------------
   1:            95       42952184  [I
   2:          1079         101120  [C
   3:           485          55272  java.lang.Class
   4:           526          25936  [Ljava.lang.Object;
   5:            13          25664  [B
   6:          1057          25368  java.lang.String
   7:            74           5328  java.lang.reflect.Field
           

后面两次调用完成之后：

pemi$ jmap -histo 50903 | head
 num     #instances         #bytes  class name
----------------------------------------------
   1:       2001080       88101152  [C
   2:           100       36777992  [I
   3:       1001058       24025392  java.lang.String
   4:         64513        1548312  java.lang.StringBuilder
   5:           485          55272  java.lang.Class
   6:           526          25936  [Ljava.lang.Object;
   7:            13          25664  [B


pemi$ jmap -histo 50903 | head
 num     #instances         #bytes  class name
----------------------------------------------
   1:       4001081      176101184  [C
   2:       2001059       48025416  java.lang.String
   3:           105       32152064  [I
   4:         64513        1548312  java.lang.StringBuilder
   5:           485          55272  java.lang.Class
   6:           526          25936  [Ljava.lang.Object;
   7:            13          25664  [B
           

可以看到，EA最终能删掉在堆上创建的StringBuilder实例。两个操作对比，一个只需要63K空间，另一个需要2M。确实是一个很大的进步。

原文地址：https://minborgsjavapot.blogspot.com/2015/12/do-not-let-your-java-objects-escape.html