【四】不要问我JVM ！—— 逃逸分析

太过爱你忘了你带给我的痛 2022-09-01 14:59 20阅读 0赞

> # 一、堆是分配对象的唯一选择吗？ #

在JVM中，对象是在Java堆中分配内存的，这是一个普遍的常识。但是，有一种特殊情况，那就是如果经过`逃逸分析(Escape Analysis)` 后发现，一个对象并没有逃逸出方法的话，那么就可能被优化成栈上分配。这样就无需在堆上分配内存，也无须进行垃圾回收了。这也是最常见的堆外存储技术。

如何将堆上的对象分配到栈，需要使用逃逸分析手段。

> # 二、逃逸分析 #

## 2.1 什么是逃逸分析？ ##

这是一种可以有效减少Java程序中同步负载和`内存堆分配压力`的跨函数全局数据流分析算法。

通过逃逸分析，Java Hotspot `编译器`能够分析出一个新的对象的引用的使用范围从而决定是否要将这个对象分配到堆上。若在栈上分配，栈内存中一个方法对应一个栈帧，这个方法执行完了，栈帧就出栈了，这个分配到该栈帧的对象也就消失了，不用像堆内存那样需要GC。

在JDK6版本之后，HotSpot中默认就已经开启了逃逸分析。如果使用的是较早的版本，可以通过:

*  `-XX:+DoEscapeAnalysis`显式开启逃逸分析
 *  `-XX:+PrintEscapeAnalysis`查看逃逸分析的筛选结果

## 2.2 怎么判断有没有逃逸？ ##

逃逸分析的基本行为就是分析对象动态作用域：

1.  当一个对象在方法中被定义后，对象只在方法内部使用，则认为没有发生逃逸。
2.  当一个对象在方法中被定义后，它被外部方法所引用，则认为发生逃逸。例如作为调用参数传递到其他地方中。

比如下面的V类型的对象，就没有发生逃逸：

public void method(){ 
            V v = new V();
            //dosomething
            v = null;
        }

没有发生逃逸的对象，则可以分配到栈上，随着方法执行的结束，栈空间就被移除。

如何快速的判断是否发生了逃逸分析：**就看 new 的对象实体是否在方法外被调用**。  
接着看：

public class EscapeAnalysis { 
        public EscapeAnalysis obj;
        /** * 方法返回 EscapeAnalysis 对象，发生逃逸 */
        public EscapeAnalysis getInstance() { 
            return obj == null ? new EscapeAnalysis() : obj;
        }
    
        /** * 为成员属性赋值，发生逃逸 * 如果声明 static 的方法也会发生逃逸 */
        public void setObj(){ 
            this.obj = new EscapeAnalysis();
        }
    
        /** * 对象的作用域仅在当前方法中有效，没有发生逃逸 */
        public void useEscapeAnalysis(){ 
            EscapeAnalysis e = new EscapeAnalysis();
        }
    
        /** * 引用成员变量的值，发生逃逸 */
        public void useEscapeAnalysis1(){ 
            EscapeAnalysis e = getInstance();
        }
    
        /** * 返回的StringBuffer 可能会在外部被使用，所以发生逃逸 */
        public static StringBuffer createStringBuffer1(String s1,String s2){ 
            StringBuffer sb = new StringBuffer();
            sb.append(s1);
            sb.append(s2);
            return sb;
        }
    
        /** * StringBuffer 调用 toString 方法，返回了String，所以没有发生逃逸 */
        public static String createStringBuffer2(String s1,String s2){ 
            StringBuffer sb = new StringBuffer();
            sb.append(s1);
            sb.append(s2);
            return sb.toString();
        }
    }

通过上面的分析，开发中能使用局部变量的，就不要使用在方法外定义。这样就不会有逃逸。

## 2.2 编译器怎么优化？ ##

前面说了使用逃逸分析，编译器可以对代码进行优化，具体的：

1.  `栈上分配` 将堆分配转化为栈分配。
2.  `同步省略` 如果一个对象被发现只能从一个线程被访问到，那么对于该对象的操作可以不考虑同步。
3.  `分离对象或标量替换` 有的对象可能不需要作为一个连续的内存结构存在也可以被访问到，那么对象的部分(或全部)可以不存储在内存，而是存储在CPU寄存器中。

### 2.2.1 关于栈上分配 ###

`JIT` 编译器在编译期间根据逃逸分析的结果，发现如果一个对象并没有逃逸出方法的话，就可能被优化成栈上分配。分配完成后，继续在调用栈内执行，最后线程结束，栈空间被回收，局部变量对象也被回收。这样就无须进行垃圾回收了。

常见的栈上分配的场景：就是上面说明的`给成员变量赋值`、`方法返回值`、`实例引用传递`。

现在来看下分别在栈上及堆上分配时的内存情况及运行效率情况：

/** * 栈上分配测试 * 参数设置 * -Xms1G -Xmx1G -XX:-DoEscapeAnalysis -XX:+PrintGCDetails (未开启栈上分配) * -Xms1G -Xmx1G -XX:+DoEscapeAnalysis -XX:+PrintGCDetails (开启栈上分配) */
    public class StackAllocation { 
        public static void main(String[] args) { 
            long start = System.currentTimeMillis();
            for (int i = 0; i < 10000000; i++) { 
                alloc();
            }
            //查看执行时间
            long end = System.currentTimeMillis();
            System.out.println("花费的时间为：" + (end - start) + "ms");
            //为了查看堆内存中对象的个数，线程 sleep
            try { 
                Thread.sleep(100000000);
            } catch (InterruptedException e) { 
                e.printStackTrace();
            }
        }
    
        public static void alloc() { 
            //此时，这个对象未发生逃逸，所以这个对象会分配到栈空间上
            User user = new User();
        }
    }
    
    class User {  }

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 1]  
![在这里插入图片描述][9d50a0a57c0445b6929109647cd22347.png]  
若减少堆内存，不开启逃逸分析的时候，堆内存就会发生GC  
![在这里插入图片描述][23218b17e53a427daa1cb1b66878d009.png]  
![在这里插入图片描述][b960e28149734e80a3fe1c56da55d4f8.png]  
若减少堆内存，开启逃逸分析的时候，堆内存不会发生GC，因为有很多对象在栈上创建  
![在这里插入图片描述][0e34d372bc094c0f9d21a44a6fbf4cd8.png]  
![在这里插入图片描述][3e6e96dc2cfd43beb022cd18cb298a30.png]

### 2.2.2 关于同步省略 ###

线程同步的代价是相当高的，同步的后果是降低并发性和性能。

在动态编译同步块的时候，`JIT`编译器可以借助`逃逸分析`来判断同步块所使用的锁对象是否只能够被一个线程访问而没有被发布到其他线程，即该对象没有发生逃逸。如果没有逃逸，那么`JIT`编译器在编译这个同步块的时候就会取消对这部分代码的同步。这样就能大大提高并发性和性能。这个取消同步的过程就叫`同步省略`，也叫`锁消除`。

public void method(){ 
            Object obj = new Object();
            synchronized (obj){ 
                System.out.println(obj);
            }
        }

上面代码中对 obj 这个对象进行加锁，但是 obj 对象的生命周期只在 method() 方法中，并不会被其他线程所访问到，所以在JIT编译阶段就会被优化掉。优化成:

public void method(){ 
            Object obj = new Object();
          	System.out.println(obj);
        }

### 2.2.3 关于分离对象（标量替换） ###

标量(Scalar)是指一个无法再分解成更小的数据的数据。Java中的原始数据类型就是标量。

相对的，那些还可以分解的数据叫做聚合量(Aggregate)，Java中的对象就是聚合量，因为他可以分解成其他聚合量和标量。

在`JIT`阶段，如果经过逃逸分析，发现一个对象不会被外界访问的话，那么经过`JIT`优化，就会把这个对象拆解成若干个其中包含的若干个成员变量来代替。这个过程就是`表量替换`。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 2]  
上面经过标量替换之后：  
![在这里插入图片描述][5d6a5f3584ff45d98edc4bcab5b7accb.png]  
可以看到，Point这个聚合量经过套印分析后发现并没有逃逸，那么就可以替换成两个标量了。标量替换后的好处就是可以大大减少堆内存的占用。因为一旦不需要创建对象了，就不需要分配堆内存了。

参数`-XX:+EliminateAllocations`：开启了标量替换(默认打开)，允许将对象打散分配在栈上。

/** * 标量替换测试 * 参数设置 * -Xms100m -Xmx100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:-EliminateAllocations (关闭标量替换) * -Xms100m -Xmx100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:+EliminateAllocations (开启标量替换) */
    public class ScalarReplace { 
        public static class User{ 
            public int id;
            public String name;
        }
        public static void alloc(){ 
            User user = new User();//未发生逃逸
            user.id = 1;
            user.name = "Lemon";
        }
    
        public static void main(String[] args) { 
            long start = System.currentTimeMillis();
            for (int i = 0;i < 100000000;i++){ 
                alloc();
            }
            long end = System.currentTimeMillis();
            System.out.println("花费的时间为：" + (end - start) + "ms");
        }
    }

![在这里插入图片描述][29b194694e7e41bcb8c5b4d6fe439a0e.png]  
![在这里插入图片描述][f5bd4b3cd7ac4c789573e6aea6054496.png]  
`-server -Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:+EliminateAllocations`

参数说明：  
`-server`：启动Server模式，因为在Server模式下，才可以启用逃逸分析。  
`-XX:+DoEscapeAnalysis`：启用逃逸分析  
`-Xmx10m`：指定了堆空间最大为10MB  
`-XX:+PrintGC`：将打印GC日志。  
`-XX:+EliminateAllocations`：开启了标量替换(默认打开)，允许将对象打散分配在栈上，比 如对象拥有id和name两个字段，那么这两个字段将会被视为两个独立的局部变量进行分配。

## 2.3 逃逸分析小结 ##

关于逃逸分析的论文在1999年就已经发表了，但直到JDK 1.6才有实现，而且这项技术到如今也并不是十分成熟的。

其根本原因就是无法保证逃逸分析的性能消耗一定能高于他的消耗。虽然经过逃逸分析可以做`标量替换`、`栈上分配`和`锁消除`。但是逃逸分析自身也是需要进行一系列复杂的分析的，这其实也是一个相对耗时的过程。

一个极端的例子，就是经过逃逸分析之后，发现全是逃逸的。那这个逃逸分析的过程就白白浪费了。

虽然这项技术并不十分成熟，但是它也是即时编译器优化技术中一个十分重要的手段。注意到有一些观点，认为通过逃逸分析，JVM会在栈上分配那些不会逃逸的对象，这在理论上是可行的，但是取决于JVM设计者的选择。据我所知，Oracle HotspotJVM中并未这么做，这一点在逃逸分析相关的文档里已经说明，所以可以明确所有的对象实例都是创建在堆上。

目前很多书籍还是基于JDK 7以前的版本，JDK已经发生了很大变化，intern字符串的缓存和静态变量曾经都被分配在永久代上，而永久代已经被元数据区取代。但是，intern字符串缓存和静态变量并不是被转移到元数据区，而是直接在堆上分配，所以这一点同样符合前面一点的结论:对象实例都是分配在堆上。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70]: /images/20220829/9ad5ef51a9fd4c99a05fd2e2eaf82d60.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 1]: /images/20220829/fac0f0d4d188433789b28460c8915597.png
[9d50a0a57c0445b6929109647cd22347.png]: /images/20220829/19b8a5f0ceb8478eaaef7fbfe2b9bcb5.png
[23218b17e53a427daa1cb1b66878d009.png]: /images/20220829/9ddfbeef1ed74e129684d97dac9df546.png
[b960e28149734e80a3fe1c56da55d4f8.png]: /images/20220829/90d453d0bd4a452a8c71a660f8a2fecf.png
[0e34d372bc094c0f9d21a44a6fbf4cd8.png]: /images/20220829/0abcc1b716f44910a52a3584e377e0a6.png
[3e6e96dc2cfd43beb022cd18cb298a30.png]: /images/20220829/d725b85e807f473f9ac21335e7550278.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIzMTkyOA_size_16_color_FFFFFF_t_70 2]: /images/20220829/f27ec674663945b2b815c04da7208ca5.png
[5d6a5f3584ff45d98edc4bcab5b7accb.png]: /images/20220829/845f762c9b80446cb30924d794bb8f0b.png
[29b194694e7e41bcb8c5b4d6fe439a0e.png]: /images/20220829/23fa77221b5c4a2f80edffd319017ec1.png
[f5bd4b3cd7ac4c789573e6aea6054496.png]: /images/20220829/93b0a632b579411d995ac637de9956db.png