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阻塞時長 占比

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。