譯者：趙峰，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的資訊。例如：

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

輸出顯示的是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文件中讀所有的類資料的情況下顯示出效能優勢。

-version引數在列印完上述資訊後立即終止JVM。還有一個類似的引數-showversion可以用來輸出相同的資訊，但是-showversion緊接著會處理並執行Java程式。因此，-showversion對幾乎所有Java應用的命令列都是一個有效的補充。你永遠不知道你什麼時候，突然需要了解一個特定的Java應用（崩潰時）使用的JVM的一些資訊。在啟動時新增-showversion，我們就能保證當我們需要時可以得到這些資訊。

-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然後檢索它的結果做一個簡單的用例。每一個例子，它的執行時間都是很多次執行的平均時間。

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

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

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

當然也有很多使-Xcomp表現很好的例子。特別是執行時間長的應用，我強烈建議大家使用JVM的預設設定,讓JIT編譯器充分發揮其動態潛力，畢竟JIT編譯器是組成JVM最重要的元件之一。事實上，正是因為JVM在這方面的進展才讓Java不再那麼慢。