這篇文章著眼于轉(zhuǎn)義分析，特別是jvm在運行的程序中執(zhí)行轉(zhuǎn)義分析需要多長時間。 我做了一些觀察，但目前還沒有全部解釋。

作為介紹，讓我們繞道看看jvm -Xcomp中一個鮮為人知且使用更少的標(biāo)志（這將是一件好事）。

該標(biāo)志的行為在jvm 文檔中定義為：

-Xcomp在第一次調(diào)用時強制編譯方法。 默認(rèn)情況下，客戶端VM（ -client ）執(zhí)行1,000個解釋方法調(diào)用，服務(wù)器VM（ -server ）執(zhí)行10,000個解釋方法調(diào)用，以收集信息以進行有效的編譯。 指定-Xcomp選項會禁用解釋的方法調(diào)用，從而以提高效率為代價來提高編譯性能。

乍一看，這似乎是一個極好的選擇。 在10,000個周期內(nèi)預(yù)熱jvm的快捷方式–我們可以直接編譯代碼。 我們是否應(yīng)該始終默認(rèn)啟用此選項？

但是文檔確實警告說，這將“以犧牲效率為代價”。

jvm在10,000個預(yù)熱周期中了解代碼行為，以便在編譯時以最有效的方式進行編譯。 立即編譯代碼意味著可以，確實可以編譯代碼，但是編譯后的代碼可能不是最有效的。 您可以在此博文中閱讀有關(guān)它的更多信息-但這并不是本文的主題。

如果使用-Xcomp，則不會發(fā)生的其他事情是轉(zhuǎn)義分析。 實際上，這非常令人驚訝，因為jvm不需要通過運行程序來了解是否可以進行轉(zhuǎn)義分析。 這應(yīng)該通過對代碼的靜態(tài)分析來證明。

看看這個代碼（我被思想的啟發(fā)本博客）：

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);}} }

我們需要確保程序在沒有g(shù)c的情況下運行（我建議使用這些標(biāo)志）：

-verbosegc -Xmx4g -Xms4g

當(dāng)程序等待輸入時，請執(zhí)行堆轉(zhuǎn)儲以查看已創(chuàng)建了多少個Optional對象。 然后按任意鍵以恢復(fù)程序。

要執(zhí)行堆轉(zhuǎn)儲，請先運行jps以確定程序的pid，然后運行：

jmap -histo pid | head

一次不使用-Xcomp標(biāo)志，一次使用-Xcomp標(biāo)志。

沒有-Xcomp標(biāo)志

第一次迭代后：

在第二次迭代之后：

所有后續(xù)迭代都是相同的，不再創(chuàng)建其他對象：

在234k次迭代之后，顯然有轉(zhuǎn)義分析開始了-不知道為什么要花這么長時間，通常（例如，使用編譯代碼）10k次迭代就足夠了嗎？ 同樣在第二次迭代中，它在逃逸分析開始之前又創(chuàng)建了約40萬個對象，這也有些神秘。

使用-Xcomp標(biāo)志

第一次迭代后：

在第二次迭代之后：

每次迭代后， Optional對象的數(shù)量增加1m。

摘要

• -Xcomp是幾乎絕對不應(yīng)在生產(chǎn)中使用的開關(guān)。 我可以想象在某些情況下您可能想禁用解釋器，但是這些情況非常特殊。
• 逃脫分析似乎至少需要進行20萬次迭代才能有效。 因此，您需要允許超過10k的迭代時間以進行完全預(yù)熱。
• 還有另一個階段，在逃避對象之后，似乎需要再次執(zhí)行此操作。 這需要進一步的理解。
• 如果通過在兩次調(diào)用Optional之間進行一些工作來減慢程序速度，則對象數(shù)量會減少。 例如，我發(fā)現(xiàn)對Math.sin的調(diào)用將Optional對象減少了約50％。

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

總結(jié)

以上是生活随笔為你收集整理的jvm需要多长时间进行转义分析？ 可能比您想象的要长。的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。