Java 中的转义分析
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/771430/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Escape analysis in Java
提问by Denis Bazhenov
As far as I know the JVM uses escape analysis for some performance optimisationslike lock coarsening and lock elision. I'm interested if there is a possibility for the JVM to decide that any particular object can be allocated on stack using escape analysis.
据我所知，JVM 使用逃逸分析来进行一些性能优化，比如锁粗化和锁省略。我感兴趣的是 JVM 是否有可能决定使用转义分析在堆栈上分配任何特定对象。
Some resourcesmake me think that I am right. Is there JVMs that actually do it?
有些资源让我觉得我是对的。是否有真正做到这一点的 JVM？
采纳答案by benmmurphy
I don't think it does escape analysis for stack allocation. example:
我认为它不会对堆栈分配进行转义分析。例子：
public class EscapeAnalysis {
private static class Foo {
private int x;
private static int counter;
public Foo() {
x = (++counter);
}
}
public static void main(String[] args) {
System.out.println("start");
for (int i = 0; i < 10000000; ++i) {
Foo foo = new Foo();
}
System.out.println(Foo.counter);
}
}
with -server -verbose:gc -XX+DoEscapeAnalysis:
与-server -verbose:gc -XX+DoEscapeAnalysis：
start [GC 3072K->285K(32640K), 0.0065187 secs] [GC 3357K->285K(35712K), 0.0053043 secs] [GC 6429K->301K(35712K), 0.0030797 secs] [GC 6445K->285K(41856K), 0.0033648 secs] [GC 12573K->285K(41856K), 0.0050432 secs] [GC 12573K->301K(53952K), 0.0043682 secs] [GC 24877K->277K(53952K), 0.0031890 secs] [GC 24853K->277K(78528K), 0.0005293 secs] [GC 49365K->277K(78592K), 0.0006699 secs] 10000000
Allegedly JDK 7 supports stack allocation.
据称JDK 7 支持堆栈分配。
回答by Janek Bogucki
With this version of java -XX:+DoEscapeAnalysis results in far less gc activity and 14x faster execution.
使用此版本的 java -XX:+DoEscapeAnalysis 可大大减少 gc 活动和 14 倍的执行速度。
$ java -version
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing)
$ uname -a
Linux xxx 2.6.18-4-686 #1 SMP Mon Mar 26 17:17:36 UTC 2007 i686 GNU/Linux
Without escape analysis,
没有逃逸分析，
$ java -server -verbose:gc EscapeAnalysis|cat -n
1 start
2 [GC 896K->102K(5056K), 0.0053480 secs]
3 [GC 998K->102K(5056K), 0.0012930 secs]
4 [GC 998K->102K(5056K), 0.0006930 secs]
--snip--
174 [GC 998K->102K(5056K), 0.0001960 secs]
175 [GC 998K->102K(5056K), 0.0002150 secs]
176 10000000
With escape analysis,
通过逃逸分析，
$ java -server -verbose:gc -XX:+DoEscapeAnalysis EscapeAnalysis
start
[GC 896K->102K(5056K), 0.0055600 secs]
10000000
The execution time reduces significantly with escape analysis. For this the loop was changed to 10e9 iterations,
通过逃逸分析，执行时间显着减少。为此，循环更改为 10e9 次迭代，
public static void main(String [] args){
System.out.println("start");
for(int i = 0; i < 1000*1000*1000; ++i){
Foo foo = new Foo();
}
System.out.println(Foo.counter);
}
Without escape analysis,
没有逃逸分析，
$ time java -server EscapeAnalysis
start
1000000000
real 0m27.386s
user 0m24.950s
sys 0m1.076s
With escape analysis,
通过逃逸分析，
$ time java -server -XX:+DoEscapeAnalysis EscapeAnalysis
start
1000000000
real 0m2.018s
user 0m2.004s
sys 0m0.012s
So with escape analysis the example ran about 14x faster than the non-escape analysis run.
因此，使用逃逸分析，该示例的运行速度比非逃逸分析运行快 14 倍。
回答by Mike Ceruti
Escape analysis is really nice, but it is not a complete get of jail free card. if you have a dynamically sized collection inside of an object, the escape analysis will NOT switch from heap to stack. For example:
逃生分析真的很好，但它并不是一张完全免于监狱的卡。如果对象内部有一个动态大小的集合，则转义分析不会从堆切换到堆栈。例如：
public class toEscape {
public long l;
public List<Long> longList = new ArrayList<Long>();
}
Even if this object is created in a method and absolutely does NOT escape from a syntactic point of view, the compiler will not mark this for escape. I suspect because that longList is not really bounded in size from a pure syntactic perspective and it could blow your stack potentially. Thus I believe it takes a pass on this case. I experimented with this where the longList was empty and still it caused collections in a simple micro benchmark.?
即使这个对象是在一个方法中创建的并且从语法的角度来看绝对不会转义，编译器也不会将此标记为转义。我怀疑是因为从纯粹的语法角度来看，longList 的大小并没有真正的限制，它可能会破坏你的堆栈。因此，我相信这需要通过这个案例。我在 longList 为空的情况下尝试了这个，但它仍然在一个简单的微基准测试中引起了集合。？
