Java後臺開發(2)——JVM參數設置和分析

前言

有時候程序會碰到java.lang.OutOfMemoryError，這個主要是JVM參數沒有配好引發的。

OutOfMemoryError分兩種：java.lang.OutOfMemoryError: Java heap space和java.lang.OutOfMemoryError: PermGen space。

前者是有關堆內存的內存溢出，能夠經過配置-Xms和-Xmx參數來解決。

後者是有關非堆內存的內存溢出，能夠經過配置-XX:PermSize和-XX:MaxPermSize來設置。

參數的含義

打開eclipse的eclipse.ini會看到以下參數：

-vmargs

-Xms128M

-Xmx512M

-XX:PermSize=64M

-XX:MaxPermSize=128M

-vmargs：用來講明後面的就是JVM的參數了

-Xms：JVM初始分配的堆內存

-Xmx：JVM最大容許分配的堆內存，按需分配

-XX:PermSize：JVM初始分配的非堆內存

-XX:MaxPermSize：JVM最大容許分配的非堆內存，按需分配

堆（Heap）內存和非堆（Non-Heap）內存

堆內存：

JVM留給開發者用的內存。通常存放對象以及數組。

JVM初始分配的堆內存由-Xms指定，默認是物理內存的1/64；JVM最大分配的堆內存由-Xmx指定，默認是物理內存的1/4。

空餘堆內存小於40%時，JVM就會增大堆內存直到-Xmx的最大限制；空餘堆內存大於70%時，JVM會減小堆內存直到-Xms的最小限制。所以服務器通常設置-Xms、-Xmx相等以免在每次GC後調整堆內存的大小。

若是-Xmx不指定或者指定偏小，應用可能會致使java.lang.OutOfMemory錯誤，此錯誤來自JVM，不是Throwable的，沒法用try...catch捕捉。

非堆內存： 

JVM留給本身用的內存。方法區、JVM內部處理或優化所需的內存(如JIT編譯後的代碼緩存)、每一個類結構(如運行時常數池、字段和方法數據)以及方法和構造方法的代碼都在非堆內存中。

JVM初始分配的非堆內存由-XX:PermSize指定，默認是物理內存的1/64；JVM最大分配的非堆內存由-XX:MaxPermSize 指定，默認是物理內存的1/4。（還有一說：MaxPermSize缺省值和-server -client選項相關，-server選項下默認MaxPermSize爲64m，-client選項下默認MaxPermSize爲32m）

-XX:MaxPermSize設置太小會致使java.lang.OutOfMemoryError: PermGen space，緣由以下：

PermGen space用於存放Class和Meta的信息，GC不會對PermGen space進行處理，因此若是Load不少Class的話，就會出現上述Error。這種Error在web服務器對JSP進行pre compile的時候比較常見

-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再也不那麼慢。

參考連接：

1. JVM啓動參數設置：http://blog.csdn.net/tianjf0514/article/details/20793523
2. Non-standard JVM HotSpot VM Option：http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
3. Standard JVM HotSpot VM Option：http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/java.html
4. JVM類型及編譯器模式：http://ifeve.com/useful-jvm-flags-part-1-jvm-types-and-compiler-modes-2/
5. JVM內存調優：http://ifeve.com/useful-jvm-flags-part-4-heap-tuning/