今天是2018年9月25日09:51:48，上次寫完Java NIO的一些總結之後，馬上將要開啟新的博文欄。關於jvm引數調整的。本篇博文即是第一篇關於jvm引數介紹的文章。

現在的JVM執行Java程式（和其它的相容性語言）時在高效性和穩定性方面做的非常出色。自適應記憶體管理、垃圾收集、及時編譯、動態類載入、鎖優化——這裡僅僅列舉了某些場景下會發生的神奇的事情，但他們幾乎不會直接與普通的程式設計師相關。在執行時，JVM會不斷的計算並優化應用或者應用的某些部分。

雖然有了這種程度的自動化（或者說有這麼多自動化），但是JVM仍然提供了足夠多的外部監控和手動調優工具。在有錯誤或低效能的情況下，JVM必須能夠讓專家除錯。順便說一句，除了這些隱藏在引擎中的神奇功能，允許大範圍的手動調優也是現代JVM的優勢之一

-server and -client

有兩種型別的 HotSpot JVM，即”server”和”client”。服務端的VM中的預設為堆提供了一個更大的空間以及一個並行的垃圾收集器，並且在執行時可以更大程度地優化程式碼。客戶端的VM更加保守一些（校對注：這裡作者指客戶端虛擬機器有較小的預設堆大小），這樣可以縮短JVM的啟動時間和佔用更少的記憶體

如果我們不喜歡預選（校對注：指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不再那麼慢。