jvm gc阻塞时长 占比

这篇文章着眼于转义分析，特别是jvm在运行的程序中执行转义分析需要多长时间。 我做了一些观察，但目前还没有全部解释。

作为介绍，让我们绕道看看jvm -Xcomp中一个鲜为人知且使用更少的标志（我们将看到这是一件好事）。

该标志的行为在jvm 文档中定义为：

-Xcomp首次调用时强制编译方法。 默认情况下，客户端VM（ -client ）执行1,000个解释方法调用，服务器VM（ -server ）执行10,000个解释方法调用，以收集信息以进行有效的编译。 指定-Xcomp选项会禁用解释的方法调用，从而以提高效率为代价来提高编译性能。

乍一看，这似乎是一个极好的选择。 在10,000个周期内预热jvm的快捷方式–我们可以直接编译代码。 我们是否应该始终默认启用此选项？

但是文档确实警告这将“以效率为代价”。

jvm在10,000个预热周期中了解代码行为，以便在编译时以最有效的方式进行编译。 立即编译代码意味着可以编译代码，但是编译后的代码可能不是最有效的。 您可以在此博文中阅读有关它的更多信息-但这并不是本文的主题。

如果使用-Xcomp，则不会发生的其他事情是转义分析。 这实际上是相当令人惊讶的，因为jvm不需要通过运行程序来了解是否可以进行转义分析。 这应该通过对代码的静态分析来证明。

看看这个代码（我被思想的启发本博客）：

import java.io.IOException;
import java.util.Optional;/*** Created by daniel on 17/12/2015.*/
public class Test {private static String NAME;public static void main(String[] args)throws IOException {new Test().test();}public void test() throws IOException {Name name = new Name("Steven");int iterations = 1_000_000;for(;;){countOptional(name, iterations);System.out.println("Press any key to continue");System.in.read();}}private static void countOptional(Name name, int iterations) {for (int i = 0; i < iterations; i++) {NAME = name.getOptionalName().get();}System.out.println(iterations + " optional iterations " + NAME);}class Name {private final String name;public Name(String name) {this.name = name;}public Optional<String> getOptionalName() {return Optional.ofNullable(name);}}
}

我们需要确保程序在没有gc的情况下运行（我建议使用这些标志）：

-verbosegc -Xmx4g -Xms4g

当程序等待输入时，请执行堆转储以查看已创建了多少个Optional对象。 然后按任意键以恢复程序。

要执行堆转储，请先运行jps以确定程序的pid，然后运行：

jmap -histo pid | head

一次不使用-Xcomp标志，一次使用-Xcomp标志。

没有-Xcomp标志

第一次迭代后：

在第二次迭代之后：

所有后续迭代都是相同的，不再创建其他对象：

234k迭代后显然有转义分析开始了-不知道为什么要花这么长时间，通常（例如使用编译代码）10k迭代就足够了吗？ 同样在第二次迭代中，它在逃逸分析开始之前又创建了约40万个对象，这也有些神秘。

使用-Xcomp标志

第一次迭代后：

在第二次迭代之后：

每次迭代后， Optional对象的数量增加1m。

摘要

• -Xcomp是几乎绝对不应在生产中使用的开关。 我可以想象某些情况下您可能想禁用解释器，但是这些情况非常特殊。
• 逃脱分析似乎至少需要进行20万次迭代才能有效。 因此，您需要允许超过10k的迭代时间以进行完全预热。
• 还有另一个阶段，在逃避对象之后，似乎需要再次执行此操作。 这需要进一步的理解。
• 如果通过在两次调用Optional之间进行一些工作来减慢程序速度，则对象数量会减少。 例如，我发现对Math.sin的调用将Optional对象减少了约50％。

翻译自: https://www.javacodegeeks.com/2015/12/long-take-jvm-effect-escape-analysis-maybe-longer-think.html

jvm gc阻塞时长 占比