現在的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不再那么慢。