JVM逃逸分析

堆是分配对象存储的唯一选择吗?

否，在《深入理解Java虚拟机》中关于Java堆内存有这样一段描述: .
随着JIT编译期的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化，所有的对象都分配到堆上也渐渐变得不那么“绝对”了。

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

此外，前面提到的基于openJDK深度定制的TaoBaoVM，其中创新的GCIH (GC invisible heap)技术实现off-heap,将生命周期较长的Java对象从heap中移至heap外，并且Gc不能管理GCIH内部的Java对象，以此达到降低GC的回收频率和提升GC的回收效率的目的。

逃逸分析概述

如何将堆上的对象分配到栈，需要使用逃逸分析手段。
这是一种可以有效减少Java程序中同步负载和内存堆分配压力的跨函数全局数据流分析算法。
通过逃逸分析，Java Hotspot编译器能够分析出一个新的对象的引用的使用范围从而决定是否要将这个对象分配到堆上。
逃逸分析的基本行为就是分析对象动态作用域：①：当一个对象在方法中被定义后，对象只在方法内部使用，则认为没有发生逃逸，将堆上的对象分配到栈上，随方法执行结束，栈空间就被移除。②：当一个对象在方法中被定义后，它被外部方法所引用，则认为发生逃逸。例如作为调用参数传递到其他地方中。

如何快速判断对象是否发生逃逸，就看new的对象是否有可能会在方法外被使用。
结论：开发中能使用局部变量的，就不要使用在方法外定义。

参数设置：
在JDK 6u23版本之后，Hotspot中默认就已经开启了逃逸分析。如果使用的是较早的版本，开发人员则可以通过:

选项“-XX: +DlpEscapeAnalysis”显式开启逃逸分析
通过选项“-XX: +PrintEscapeAnalysis”查看逃逸分析的筛选结果。

/**
 * 逃逸分析
 * <p>
 * 如何快速的判断是否发生了逃逸分析，大家就看new的对象实体是否有可能在方法外被调用。
 */
public class EscapeAnalysis {

    public EscapeAnalysis obj;

    /*
    方法返回EscapeAnalysis对象，发生逃逸
     */
    public EscapeAnalysis getInstance() {
        return obj == null ? new EscapeAnalysis() : obj;
    }

    /*
    为成员属性赋值，发生逃逸
     */
    public void setObj() {
        this.obj = new EscapeAnalysis();
    }
    //思考：如果当前的obj引用声明为static的？仍然会发生逃逸。

    /*
    对象的作用域仅在当前方法中有效，没有发生逃逸
     */
    public void useEscapeAnalysis() {
        EscapeAnalysis e = new EscapeAnalysis();
    }

    /*
    引用成员变量的值，发生逃逸
     */
    public void useEscapeAnalysis1() {
        EscapeAnalysis e = getInstance();
        //getInstance().xxx()同样会发生逃逸
    }
}

常见的发生逃逸场景

给成员变量赋值
方法返回值
实例引用传递

代码优化

使用逃逸分析，编译器可以对代码做如下优化

栈上分配。将堆分配转化为栈分配。如果-一个对象在子程序中被分配，要使指向该对象的指针永远不会逃逸，对象可能是栈分配的候选，而不是堆分配。
同步省略，如果一个对象被发现只能从一个线程被访问到，那么对于这个对象的操作可以不考虑同步。
分离对象或标量替换。有的对象可能不需要作为–个连续的内存结构存在也可以被访问到，那么对象的部分(或全部)可以不存储在内存，而是存储在CPU寄存器中。

栈上分配

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

-Xmx1G -Xms1G -XX:-DoEscapeAnalysis -XX:+PrintGCDetails配置参数，此时为开启逃逸分析。

创建10000000个对象，耗时179ms

修改参数开启逃逸分析-Xmx1G -Xms1G -XX:+DoEscapeAnalysis -XX:+PrintGCDetails

耗时6ms

此时我们的堆空间是不会维护10000000个对象，而是被优化成栈上分配

-Xmx256m -Xms256m -XX:-DoEscapeAnalysis -XX:+PrintGCDetails当我们把堆空间设置为256M，关闭逃逸分析后，运行结果

由于堆空间不足，而发生了两次GC。

此时在开启逃逸分析-Xmx256m -Xms256m -XX:+DoEscapeAnalysis -XX:+PrintGCDetails

由运行结果可得是没有发生过GC的，这是因为栈是不存在GC的，也就验证了当前使用了栈上分配优化。

同步省略

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

如果一个对象被发现只能从一个线程被访问到，那么对于这个对象的操作可以不考虑同步。

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

上图中的代码使用了synchronized对hollis 对象加锁，但是hollis对象每个线程使用该方法都创建了一个该对象，每个线程使用的不是同一个hollis对象，所以是没有必要加锁的。所以在JIT编译阶段就会被优化成

标量替换

有的对象可能不需要作为–个连续的内存结构存在也可以被访问到，那么对象的部分(或全部)可以不存储在内存，而是存储在CPU寄存器中。

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

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

在JIT阶段，如果经过逃逸分析，发现一个对象不会被外界访问的话，那么经过JIT优化，就会把这个对象拆解成若干个其中包含的若干个成员变量来代替。这个过程就是标量替换。

可以看到，Point这个聚合量经过逃逸分析后，发现他并没有逃逸，就被替换成两个聚合量了。那么标量替换有什么好处呢?就是可以大大减少堆内存的占用。因为一旦不需要创建对象了，那么就不再需要分配堆内存了，而是存放在虚拟机栈的局部变量表。

标量替换为栈上分配提供了很好的基础。

-XX:EliminateAllocations 开启标量替换

使用参数-Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:-EliminateAllocations未开启标量替换

开启标量替换-Xmx100m -Xms100m -XX:-DoEscapeAnalysis -XX:+PrintGC -XX:+EliminateAllocations

耗时更少，并且没有发生GC（不在堆上）

只有在Server模式下才能开启逃逸分析（默认开启），HotSpot默认以Server模式启动。

逃逸分析总结

关于逃逸分析的论文在1999年就已经发表了，但直到JDK1.6才有实现，而且这项技术到如今也并不是十分成熟的。
其根本原因就是无法保证逃逸分析的性能消耗一定能高于他的消耗。虽然经过逃逸分析可以做标量替换、栈上分配、和锁消除。但是逃逸分析自身也是需要进行一系列复杂的分析的，这其实也是一个相对耗时的过程。
一个极端的例子，就是经过逃逸分析之后，发现没有一个对象是不逃逸的。那这个逃逸分析的过程就白白浪费掉了。
虽然这项技术并不十分成熟，但是它也是即时编译器优化技术中一个十分重要的手段。
注意到有一些观点，认为通过逃逸分析，JVM会在栈上分配那些不会逃逸的对象，这在理论上是可行的，但是取决于JVM设计者的选择。据我(康师傅)所知，Oracle HotspotJVM中并未这么做，这一点在逃逸分析相关的文档里已经说明，所以可以明确所有的对象实例都是创建在堆上。 (标量替换可行)
目前很多书籍还是基于JDK7以前的版本，JDK已经发生了很大变化，intern字符串的缓存和静态变量曾经都被分配在永久代上，而永久代已经被元数据区取代。但是，intern字符串缓存和静态变量并不是被转移到元数据区，而是直接在堆上分配，所以这一点同样符合前面一点的结论：对象实例都是分配在堆上。