JVM內存的調優

一.JVM內存的設置的原理

默認的java虛擬機的大小比較小，在對大數據進行處理時java就會報錯：java.lang.OutOfMemoryError。設置jvm內存的方法，對於單獨的.class，能夠用下面的方法對Test運行時的jvm內存進行設置。
java -Xms64m -Xmx256m Test
-Xms是設置內存初始化的大小
-Xmx是設置最大可以使用內存的大小（最好不要超過物理內存大小）
在weblogic中，能夠在startweblogic.cmd中對每一個domain虛擬內存的大小進行設置，默認的設置是在commEnv.cmd裏面。

-vmargs
-Xms128M
-Xmx512M
-XX:PermSize=64M
-XX:MaxPermSize=128M

下面是這幾個設置的一些背景知識：

• 堆(Heap)和非堆(Non-heap)內存
  按照官 方的說法：「Java 虛擬機具備一個堆，堆是運行時數據區域，全部類實例和數組的內存均今後處分配。堆是在 Java 虛擬機啓動時建立的。」「在JVM中堆以外的內存稱爲非堆內存(Non-heap memory)」。能夠看出JVM主要管理兩種類型的內存：堆和非堆。簡單來講堆就是Java代碼可及的內存，是留給開發人員使用的；非堆就是JVM留給 本身用的，因此方法區、JVM內部處理或優化所需的內存(如JIT編譯後的代碼緩存)、每一個類結構(如運行時常數池、字段和方法數據)以及方法和構造方法 的代碼都在非堆內存中。
• 堆內存分配
  JVM初始分配的內存由-Xms 指定，默認是物理內存的1/64；JVM最 大分配的內存由-Xmx指定，默認是物理內存的1/4。默認空餘堆內存小於40%時，JVM就會增大堆直到-Xmx的最大限制；空餘堆內存大於70%時， JVM會減小堆直到-Xms的最小限制。所以服務器通常設置-Xms、-Xmx相等以免在每次GC 後調整堆的大小。
• 非堆內存分配
  JVM使用-XX:PermSize設置非堆內存初始值，默認是物理內存的1/64；由XX:MaxPermSize設置最大非堆內存的大小，默認是物理內存的1/4。
• JVM內存限制(最大值)
  首先JVM內存首 先受限於實際的最大物理內存，假設物理內存無限 大的話，JVM內存的最大值跟操做系統有很大的關係。簡單的說就32位處理器雖然可控內存空間有4GB,可是具體的操做系統會給一個限制，這個限制通常是 2GB-3GB（通常來講Windows系統下爲1.5G-2G，Linux系統下爲2G-3G），而64bit以上的處理器就不會有限制了

JVM內存的調優

1. Heap設定與垃圾回收Java Heap分爲3個區，Young，Old和Permanent。Young保存剛實例化的對象。當該區被填滿時，GC會將對象移到Old區。Permanent區則負責保存反射對象，本文不討論該區。JVM的Heap分配可使用-X參數設定，

-Xms	初始Heap大小
-Xmx	java heap最大值
-Xmn	young generation的heap大小

JVM有2個GC線程。第一個線程負責回收Heap的Young區。第二個線程在Heap不足時，遍歷Heap，將Young 區升級爲Older區。Older區的大小等於-Xmx減去-Xmn，不能將-Xms的值設的過大，由於第二個線程被迫運行會下降JVM的性能。

爲何一些程序頻繁發生GC？有以下緣由：

l         程序內調用了System.gc()或Runtime.gc()。

l         一些中間件軟件調用本身的GC方法，此時須要設置參數禁止這些GC。

l         Java的Heap過小，通常默認的Heap值都很小。

l         頻繁實例化對象，Release對象。此時儘可能保存並重用對象，例如使用StringBuffer()和String()。

         若是你發現每次GC後，Heap的剩餘空間會是總空間的50%，這表示你的Heap處於健康狀態。許多Server端的Java程序每次GC後最好能有65%的剩餘空間。經驗之談：

1．Server端JVM最好將-Xms和-Xmx設爲相同值。爲了優化GC，最好讓-Xmn值約等於-Xmx的1/3[2]。

2．一個GUI程序最好是每10到20秒間運行一次GC，每次在半秒以內完成[2]。

注意：

1．增長Heap的大小雖然會下降GC的頻率，但也增長了每次GC的時間。而且GC運行時，全部的用戶線程將暫停，也就是GC期間，Java應用程序不作任何工做。

2．Heap大小並不決定進程的內存使用量。進程的內存使用量要大於-Xmx定義的值，由於Java爲其餘任務分配內存，例如每一個線程的Stack等。

2．Stack的設定

每一個線程都有他本身的Stack。

-Xss	每一個線程的Stack大小

Stack的大小限制着線程的數量。若是Stack過大就好致使內存溢漏。-Xss參數決定Stack大小，例如-Xss1024K。若是Stack過小，也會致使Stack溢漏。

3．硬件環境

硬件環境也影響GC的效率，例如機器的種類，內存，swap空間，和CPU的數量。

若是你的程序須要頻繁建立不少transient對象，會致使JVM頻繁GC。這種狀況你能夠增長機器的內存，來減小Swap空間的使用[2]。

4．4種GC

第一種爲單線程GC，也是默認的GC。，該GC適用於單CPU機器。

第二種爲Throughput GC，是多線程的GC，適用於多CPU，使用大量線程的程序。第二種GC與第一種GC類似，不一樣在於GC在收集Young區是多線程的，但在Old區和第一種同樣，仍然採用單線程。-XX:+UseParallelGC參數啓動該GC。

第三種爲Concurrent Low Pause GC，相似於第一種，適用於多CPU，並要求縮短因GC形成程序停滯的時間。這種GC能夠在Old區的回收同時，運行應用程序。-XX:+UseConcMarkSweepGC參數啓動該GC。

第四種爲Incremental Low Pause GC，適用於要求縮短因GC形成程序停滯的時間。這種GC能夠在Young區回收的同時，回收一部分Old區對象。-Xincgc參數啓動該GC。

4種GC的具體描述參見[3]。

 

參考文章：

1. JVM Tuning. http://www.caucho.com/resin-3.0/performance/jvm-tuning.xtp#garbage-collection

2. Performance tuning Java: Tuning steps

http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,1604,00.html

3. Tuning Garbage Collection with the 1.4.2 JavaTM Virtual Machine .

http://java.sun.com/docs/hotspot/gc1.4.2/

 

二．Tomcat配置

問題分析：

　　　因爲TOMCAT內存溢出而引起的問題，主要緣由是JVM的虛擬內存默認爲128M，當超過這個值時就把先前佔用的內存釋放，而致使好象TCP/IP丟包的假象，出現HTTP500的錯誤。解決方法主要是加大TOMCAT可利用內存，並在程序當中加大內存使用。

 

解決方法：

方法：加大TOMCAT可利用內存：

　　在TOMCAT的目錄下，也就是在TOMCAT41/bin/catalina.bat文件最前面加入

　　set JAVA_OPTS=-Xms800m -Xmx800m

　　表現效果是當你啓動TOMCAT時，系統內存會增長近800M使用

操做方法：

　　1）、先關掉WINDOWS服務當中的TOMCAT4服務。

　　2）、再找到TOMCAT/BIN目錄下startup.bat，雙擊打開它，你會發現現WINDOWS內存佔用會增長近800M。

　　3）、執行程序，由於是TOMCAT從新編譯程序，因此第一次會比較慢。

結論：

通過測試，咱們得出以下數據：

當系統傳輸約2000條數據時，大約近12M的淨數據（不壓縮時），系統輔助運行的內存大約佔用150M左右的空間，也就是近200M的內存佔用，而咱們擴大了近800M的JAVA內存使用，這對於業務自己來講是足夠了。因此大家不用擔憂大數據量的傳遞問題。

基於JAVA虛擬機的原理，JAVA自動有垃圾回收機制，也就是在你對一些內存長時間不使用時（近2分鐘，取決於使用頻度和優先級等），就會自動垃圾回收，從而釋放不用的內存佔用。

 

三.WebLogic配置：

 因爲WebLogic的配置問題，咱們的測試出現了失敗狀況。緣由是爲WebLogic分配的內存太少了。經過修改commom/bin/commEnv.cmd文件來增長內存分配。

 修改的部分以下：

:bea

if "%PRODUCTION_MODE%" == "true" goto bea_prod_mode

set JAVA_VM=-jrockit

set MEM_ARGS=-Xms768m -Xmx1024m

set JAVA_OPTIONS=%JAVA_OPTIONS% -Xverify:none

goto continue

:bea_prod_mode

set JAVA_VM=-jrockit

set MEM_ARGS=-Xms768m -Xmx1024m//原來是128M~256M，過小了，數據太大

goto continue

 結果修改後，沒有效果。仍是有失敗的狀況。

 發現，原來，在：bea下面還有一段配置信息以下：

:sun

if "%PRODUCTION_MODE%" == "true" goto sun_prod_mode

set JAVA_VM=-client

set MEM_ARGS=-Xms768m -Xmx1024m -XX:MaxPermSize=256m

set JAVA_OPTIONS=%JAVA_OPTIONS% -Xverify:none

goto continue

:sun_prod_mode

set JAVA_VM=-server

set MEM_ARGS=-Xms768m -Xmx1024m -XX:MaxPermSize=256m

goto continue

 將這裏的內存分配修改後見效。

 緣由是，上面對第一段代碼是爲bea本身的JVM設置的，下面的是爲Sun的設置的。而WebLogic默認的是Sun的，因此出了毛病。在JDK的選擇上，weblogic有兩種JDK供選擇，一種是Sun的JDK，另一種是Bea的jrockit。按照bea的網站的說明，sun jdk提供更好的兼容性，而使用jrockit能夠提供更好的性能。做爲weblogic集羣我所有采用jrockit做爲JDK環境，以達到更高的性能。

 

在默認啓動狀況下，jrockit啓動時爲其窗口配置的內存大小比較小。注意weblogic的啓動內存配置-Xms32m -Xmx256m，經過修改commEnv.sh能夠修改這個參數，Xms表示啓動開始分配的內存，Xmx表示最大能分配的內存，這裏咱們根據應用狀況調整爲-Xms1536m -Xmx1536m，這點須要根據自身測試狀況和系統配置進行調整，通過週一晚的調試，咱們目前應用比較合理的窗口內存大小爲1536M（2G× 75％），經過top能夠觀察到測試中的內存反應，最合理的應該是剛好把物理內存用完。