關於 JVM 的類型和模式
JVM client 模式和Server模式的區別
JVM兩種類型的區別：
曾幾何時，我也敲打過無數次這樣的命令：
然而之前的我都只關心過版本號，也就是第一行的內容。今天，我們就來看看第3行輸出的內容：JVM的類型和工作模式。
其實說Server和Client是JVM的兩種工作模式是不準確的，因爲它們就是不同的虛擬機，因此應該說有兩種類型的JVM。
第三行的輸出中可以看到： JVM的名字(HotSpot)、類型(Client)和 build ID(24.79-b02) 。除此之外，我們還知道 JVM以混合模式(mixed mode) 在運行，這是HotSpot默認的運行模式， 意味着JVM在運行時可以動態的把 字節碼 編譯 爲本地 代碼 。 我們也可以看到類 數據 共享（class data sharing）是開啓(即第三行最後的sharing)的。類數據共享（class data sharing）是一種在只讀緩存（在 js a文件中，”Java Shared Archive”）中存儲JRE的系統類，被所有Java 進程 的類加載器用來當做共享資源，它可能在經常從jar文檔中讀所有的類數據的情況下顯示出性能優勢。
-Server VM啓動時，速度較慢，但是一旦運行起來後，性能將會有很大的提升 。
當虛擬機運行在-client模式的時候,使用的是一個代號爲C1的輕量級編譯器, 而-server模式啓動的虛擬機採用相對重量級,代號爲C2的編譯器. C2比C1編譯器編譯的相對徹底,,服務起來之後,性能更高.
前段 時間 有個同事給我發了個 java 跟c++性能比較的 文章 ，其中有個對比圖引起了我的興趣，意外的是，我感興趣的不是java和c++的對比，而是java -Server模式和java -client模式的對比。從來沒想到兩者間的性能有如此巨大的差別。而在後來自己的親身 測試 中發現確實如此。
下面是我看到的那個對比圖：
圖中最顯著的就是JVM client模式和Server模式關於method call的對比，那個差別不是一般的大，在後來的測試中發現，相差至少有10倍。
如果想要在 windows 平臺下從Client JVM切換到Server JVM，需要 下載 JDK 而非JRE。打開JDK 安裝 目錄（即%JAVA_HOME%）：我們可以看到 %JAVA_HOME%/jre/bin下有一個server和client文件夾，這裏面各有一個jvm.dll ，但是大小不同，這就說明了它們是不同的JVM的文件
打開 %JAVA_HOME%/jre/ lib /i386/jvm.cfg 文件 （正如第一幅圖所見，我這裏安裝的是32JDK，其他版本的JDK可能不是i386文件夾）（注意是JDK文件夾下的jre，而非和JDK同級的jre6/7/8），會注意到以下內容（灰色選中部分）：
再看看下方的 配置 ， 第一行就配置了使用client方式，因此首選使用client模式的JVM ，這就是爲什麼一開始的java -version命令會輸出Java HotSpot(TM) Client VM的原因了。現在將第33、34行配置交換一下，再在命令行中輸入java -version，則會得到以下結果：
JVM工作在Server模式可以大大提高性能，但應用的啓動會比client模式慢大概10%。當該 參數 不指定時，虛擬機啓動檢測 主機是否爲 服務器 ，如果是，則以Server模式啓動，否則以client模式啓動，J2SE5.0檢測的根據是至少2個CPU和最低2GB內存。
當JVM用於啓動G UI 界面的交互應用時適合於使用client模式，當JVM用於運行服務器後臺程序時建議用Server模式。
JVM在client模式默認-Xms是1M，-Xmx是64M；JVM在Server模式默認-Xms是128M，-Xmx是1024M。我們可以通過運行:java -version來查看jvm默認工作在什麼模式。
JVM工作模式：
其實這兩個是JVM工作的模式。JVM有以下幾種模式：-Xint, -Xcomp, 和 -Xmixed。從上圖的輸出結果中也可以看到，mixed是JVM的默認模式，其實在文章一開始的時候就提到了
-Xmixed代表混合模式(mixed mode) ，前面也提到了， 混合模式是JVM的默認工作模式 。它會同時使用編譯模式和解釋模式。 對於字節碼中多次被調用的部分，JVM會將其編譯成 本地代碼 以提高執行效率；而被調用很少（甚至只有一次）的方法在解釋模式下會繼續執行，從而 減少編譯和優化成本 。JIT編譯器在運行時創建方法使用文件，然後一步一步的優化每一個方法，有時候會主動的優化應用的行爲。這些優化技術，比如積極的分支預測（optimistic branch prediction），如果不先分析應用就不能有效的使用。這樣將頻繁調用的部分提取出來，編譯成本地代碼，也就是在應用中構建某種熱點（即HotSpot，這也是HotSpot JVM名字的由來）。使用混合模式可以獲得最好的執行效率。
-Xint代表解釋模式(interpreted mode) ，-Xint標記會 強制JVM以解釋方式執行所有的字節碼 ，當然這 會降低運行速度 ，通常低10倍或更多。
-Xcomp代表編譯模式(compiled mode) ，與它（-Xint）正好相反， JVM在第一次使用時會把所有的字節碼編譯成本地代碼，從而帶來最大程度的優化 。這聽起來不錯，因爲這 完全繞開了緩慢的解釋器 。然而，很多應用在使用-Xcomp也會有一些性能損失，但是這比使用-Xint損失的少，原因是-Xcomp沒有讓JVM啓用JIT編譯器的全部功能。因此在上圖中，我們並沒有看到-Xcomp比-Xmixed快多少。
在都使用Client JVM的前提下，混合模式下，平均耗時150ms，然而在解釋模式下，平均耗時超過1600ms，這基本上是10倍以上的差距。
原文
http ://uule.iteye.com/blog/2420000
本站部分文章源於互聯網，本着傳播知識、有益學習和研究的目的進行的轉載，爲網友免費提供。如有著作權人或出版方提出異議，本站將立即刪除。如果您對文章轉載有任何疑問請告之我們，以便我們及時糾正。 PS：推薦一個微信公衆號: askHarries 或者qq羣：474807195，裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多