Java中的逃逸分析&标量替换&栈上分配

Java_JVM_逃逸分析技术_栈上分配_标量替换

什么是逃逸分析(Escape Analysis)?

在编程语言的编译优化原理中，分析指针动态范围的方法称之为逃逸分析。它跟静态代码分析技术中的指针分析和外形分析类似。

通俗一点讲，当一个对象的指针被多个方法或线程引用时，我们称这个指针发生了逃逸。

而用来分析这种逃逸现象的方法，就称之为逃逸分析。

在这个例子中，一共举了3种常见的指针逃逸场景。分别是 全局变量赋值，方法返回值，实例引用传递。

逃逸分析优化JVM原理

**我们知道java对象是在堆里分配的，在调用栈中，只保存了对象的指针。
当对象不再使用后，需要依靠GC来遍历引用树并回收内存，如果对象数量较多，将给GC带来较大压力，也间接影响了应用的性能。减少临时对象在堆内分配的数量，无疑是最有效的优化方法。

怎么减少临时对象在堆内的分配数量呢？不可能不实例化对象吧！
场景介绍
其实，在java应用里普遍存在一种场景。一般是在方法体内，声明了一个局部变量，且该变量在方法执行生命周期内未发生逃逸（在方法体内，未将引用暴露给外面）。
按照JVM内存分配机制，首先会在堆里创建变量类的实例，然后将返回的对象指针压入调用栈，继续执行。
这是优化前，JVM的处理方式。

逃逸分析优化 - 栈上分配
优化原理：分析找到未逃逸的变量，将变量类的实例化内存直接在栈里分配(无需进入堆)，分配完成后，继续在调用栈内执行，最后线程结束，栈空间被回收，局部变量对象也被回收。

这是优化后的处理方式，对比可以看出，主要区别在栈空间直接作为临时对象的存储介质。从而减少了临时对象在堆内的分配数量。

逃逸分析的原理很简单，但JVM在应用过程中，还是有诸多考虑。
比如，逃逸分析不能在静态编译时进行，必须在JIT里完成。原因是，与java的动态性有冲突。因为你可以在运行时，通过动态代理改变一个类的行为，此时，逃逸分析是无法得知类已经变化了。**

然而我们也应该了解：

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

JVM中启用逃逸分析 DoEscapeAnalysis

安装jdk1.6.0_14，运行java时传递jvm参数 -XX:+DoEscapeAnalysis
（这里要说明一下，在JDK7以后逃逸分析已经是默认开启了。）