JVM實用參數（一）JVM類型以及編譯器模式

JVM實用參數（一）JVM類型以及編譯器模式

原文地址：https://blog.codecentric.de/en/2012/07/useful-jvm-flags-part-1-jvm-types-and-compiler-modes/

譯者：趙峯，iDestiny    校對：郭蕾

如今的JVM運行Java程序（和其它的兼容性語言）時在高效性和穩定性方面作的很是出色。自適應內存管理、垃圾收集、及時編譯、動態類加載、鎖優化——這裏僅僅列舉了某些場景下會發生的神奇的事情，但他們幾乎不會直接與普通的程序員相關。在運行時，JVM會不斷的計算並優化應用或者應用的某些部分。

雖然有了這種程度的自動化（或者說有這麼多自動化），可是JVM仍然提供了足夠多的外部監控和手動調優工具。在有錯誤或低性能的狀況下，JVM必須可以讓專家調試。順便說一句，除了這些隱藏在引擎中的神奇功能，容許大範圍的手動調優也是現代JVM的優點之一。有趣的是，一些命令行參數能夠在JVM啓動時傳入到JVM中。一些JVM提供了幾百個這樣的參數，因此若是沒有這方面的知識很容易迷失。這系列博客的目標是着重講解平常相關的一些參數以及他們的適用場合。咱們將專一於Java6的Sun/Oracle HotSpot JVM，大多數狀況下，這些參數也會適用於其餘一些流行的JVM裏。

-server and -client

有兩種類型的 HotSpot JVM，即」server」和」client」。服務端的VM中的默認爲堆提供了一個更大的空間以及一個並行的垃圾收集器，而且在運行時能夠更大程度地優化代碼。客戶端的VM更加保守一些（校對注：這裏做者指客戶端虛擬機有較小的默認堆大小），這樣能夠縮短JVM的啓動時間和佔用更少的內存。有一個叫」JVM功效學」的概念，它會在JVM啓動的時候根據可用的硬件和操做系統來自動的選擇JVM的類型。具體的標準能夠在這裏找到。從標準表中，咱們能夠看到客戶端的VM只在32位系統中可用。

若是咱們不喜歡預選（校對注：指JVM自動選擇的JVM類型）的JVM，咱們可使用-server和-client參數來設置使用服務端或客戶端的VM。雖然當初服務端VM的目標是長時間運行的服務進程，可是如今看來，在運行獨立應用程序時它比客戶端VM有更出色的性能。當應用的性能很是重要時，我推薦使用-server參數來選擇服務端VM。一個常見的問題：在一個32位的系統上，HotSpot JDK能夠運行服務端VM，可是32位的JRE只能運行客戶端VM。

-version and -showversion

當咱們調用「java」命令時，咱們如何才能知道咱們安裝的是哪一個版本的Java和JVM類型呢？在同一個系統中安裝多個Java，若是不注意的話有運行錯誤JVM的風險。在不一樣的Linux版本上預裝JVM這方面，我認可如今已經變的比之前好不少了。幸運的是，咱們如今可使用-version參數，它能夠打印出正在使用的JVM的信息。例如：

1 $ java -version
2 java version "1.6.0_24"
3 Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
4 Java HotSpot(TM) Client VM (build 19.1-b02, mixed mode, sharing)

-version參數在打印完上述信息後當即終止JVM。還有一個相似的參數-showversion能夠用來輸出相同的信息，可是-showversion緊接着會處理並執行Java程序。所以，-showversion對幾乎全部Java應用的命令行都是一個有效的補充。你永遠不知道你何時，忽然須要瞭解一個特定的Java應用（崩潰時）使用的JVM的一些信息。在啓動時添加-showversion，咱們就能保證當咱們須要時能夠獲得這些信息。輸出顯示的是Java版本號(1.6.0_24)和JRE確切的build號(1.6.0_24-b07)。咱們也能夠看到JVM的名字(HotSpot)、類型(client)和build ID（19.1-b02) ）。除此以外，咱們還知道JVM以混合模式(mixed mode)在運行，這是HotSpot默認的運行模式，意味着JVM在運行時能夠動態的把字節碼編譯爲本地代碼。咱們也能夠看到類數據共享（class data sharing）是開啓的，類數據共享（class data sharing）是一種在只讀緩存（在jsa文件中，」Java Shared Archive」）中存儲JRE的系統類，被全部Java進程的類加載器用來當作共享資源。類數據共享(Class data sharing)可能在常常從jar文檔中讀全部的類數據的狀況下顯示出性能優點。

-Xint, -Xcomp, 和 -Xmixed

-Xint和-Xcomp參數和咱們的平常工做不是很相關，可是我很是有興趣經過它來了解下JVM。在解釋模式(interpreted mode)下，-Xint標記會強制JVM執行全部的字節碼，固然這會下降運行速度，一般低10倍或更多。-Xcomp參數與它（-Xint）正好相反，JVM在第一次使用時會把全部的字節碼編譯成本地代碼，從而帶來最大程度的優化。這聽起來不錯，由於這徹底繞開了緩慢的解釋器。然而，不少應用在使用-Xcomp也會有一些性能損失，固然這比使用-Xint損失的少，緣由是-xcomp沒有讓JVM啓用JIT編譯器的所有功能。JIT編譯器在運行時建立方法使用文件，而後一步一步的優化每個方法，有時候會主動的優化應用的行爲。這些優化技術，好比，積極的分支預測（optimistic branch prediction），若是不先分析應用就不能有效的使用。另外一方面方法只有證實它們與此相關時纔會被編譯，也就是，在應用中構建某種熱點。被調用不多（甚至只有一次）的方法在解釋模式下會繼續執行，從而減小編譯和優化成本。

注意混合模式也有他本身的參數，-Xmixed。最新版本的HotSpot的默認模式是混合模式，因此咱們不須要特別指定這個標記。咱們來用對象填充HashMap而後檢索它的結果作一個簡單的用例。每個例子，它的運行時間都是不少次運行的平均時間。

1 $ java -server -showversion Benchmark
2 java version "1.6.0_24"
3 Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
4 Java HotSpot(TM) Server VM (build 19.1-b02, mixed mode)
5  
6 Average time: 0.856449 seconds

 

1 $ java -server -showversion -Xcomp Benchmark
2 java version "1.6.0_24"
3 Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
4 Java HotSpot(TM) Server VM (build 19.1-b02, compiled mode)
5  
6 Average time: 0.950892 seconds

 

1 $ java -server -showversion -Xint Benchmark
2 java version "1.6.0_24"
3 Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
4 Java HotSpot(TM) Server VM (build 19.1-b02, interpreted mode)
5  
6 Average time: 7.622285 seconds

 

固然也有不少使-Xcomp表現很好的例子。特別是運行時間長的應用，我強烈建議你們使用JVM的默認設置,讓JIT編譯器充分發揮其動態潛力，畢竟JIT編譯器是組成JVM最重要的組件之一。事實上，正是由於JVM在這方面的進展才讓Java再也不那麼慢。

原創文章，轉載請註明： 轉載自併發編程網 – ifeve.com本文連接地址: JVM實用參數（一）JVM類型以及編譯器模式