tomcat OutOfMemoryError出現的三種情況解決辦法

 Tomcat記憶體溢出的原因

在生産環境中tomcat記憶體設定不好很容易出現記憶體溢出。造成記憶體原因是不一樣的，當然處理方式也不一樣。

這裡根據平時遇到的情況和相關資料進行一個總結。常見的一般會有下面三種情況：

1.OutOfMemoryError： Java heap space

2.OutOfMemoryError： PermGen space

3.OutOfMemoryError： unable to create new native thread.

  Tomcat記憶體溢出解決方案

對于前兩種情況，在應用本身沒有記憶體洩露的情況下可以用設定tomcat jvm參數來解決。（-Xms -Xmx -XX：PermSize  -XX：MaxPermSize）

最後一種可能需要調整作業系統和tomcat jvm參數同時調整才能達到目的。

第一種：是堆溢出。

在JVM中如果98％的時間是用于GC且可用的 Heap size 不足2％的時候将抛出此異常資訊。

沒有記憶體洩露的情況下，調整-Xms -Xmx參數可以解決。

-Xms：初始堆大小

-Xmx：最大堆大小

但堆的大小受下面三方面影響：

1.相關作業系統的資料模型（32-bt還是64-bit）限制；（32位系統下，一般限制在1.5G~2G；我在2003 server 系統下（實體記憶體：4G和6G，jdk：1.6）測試 1612M，64為作業系統對記憶體無限制。）

2.系統的可用虛拟記憶體限制；

3.系統的可用實體記憶體限制。

堆的大小可以使用 java -Xmx***M  version 指令來測試 。支援的話會出現jdk的 版本号，不支援會報錯。

-Xms -Xmx一般配置成一樣比較好比如set JAVA_OPTS= -Xms1024m -Xmx1024m

第二種：永久儲存區域溢出

PermGen space的全稱是Permanent Generation space，是指記憶體的永久儲存區域。這一部分用于存放Class和Meta的資訊，Class在被 Load的時候被放入PermGen space區域，它和和存放Instance的Heap區域不同，GC（Garbage Collection）不會在主程式運作期對PermGen space進行清理，是以如果你的APP會LOAD很多CLASS的話，就很可能出現PermGen space錯誤。這種錯誤常見在web伺服器 對JSP進行pre compile的時候。但目前的hibernate和spring項目中也很容易出現這樣的問題。http://www.javaeye.com/topic/80620 ?page=1 的文章有讨論的這個問題。可能是由于這些架構會動态class，而且jvm的gc是不會清理PemGen space的，導緻記憶體溢出。

這一個一般是加大-XX：PermSize  -XX：MaxPermSize 來解決問題。

-XX：PermSize 永久儲存區域初始大小

-XX：PermSize 永久儲存區域初始最大值

這一般結合第一條使用，比如 set JAVA_OPTS= -Xms1024m -Xmx1024m  -XX：PermSize=128M -XX：PermSize=256M

有一點需要注意：java -Xmx***M  version 指令來測試的最大堆記憶體是 -Xmx與 -XX：PermSize的 和 比如系統支援最大的jvm堆大小事1.5G，那  -Xmx1024m  -XX：PermSize=768M 是無法運作的。

原因： 

      PermGen space的全稱是Permanent Generation space,是指記憶體的永久儲存區域，這塊記憶體主要是被JVM存放Class和Meta資訊的,Class在被Loader時就會被放到PermGen space中，它和存放類執行個體(Instance)的Heap區域不同,GC(Garbage Collection)不會在主程式運作期對PermGen space進行清理，是以如果你的應用中有很CLASS的話,就很可能出現PermGen space錯誤，這種錯誤常見在web伺服器對JSP進行pre compile的時候。如果你的WEB APP下都用了大量的第三方jar, 其大小超過了jvm預設的大小(4M)那麼就會産生此錯誤資訊了。

解決方法：

1. 手動設定MaxPermSize大小

      修改TOMCAT_HOME/bin/catalina.bat（Linux下為catalina.sh），在“echo "Using CATALINA_BASE:   $CATALINA_BASE"”上面加入以下行：

set JAVA_OPTS=%JAVA_OPTS% -server -XX:PermSize=128M -XX:MaxPermSize=512m

catalina.sh下為：

JAVA_OPTS="$JAVA_OPTS -server -XX:PermSize=128M -XX:MaxPermSize=512m"

2. 将相同的第三方jar檔案移置到tomcat/shared/lib目錄下，這樣可以達到減少jar 文檔重複占用記憶體的目的。

如果遇到這個異常：java.lang.OutOfMemoryError: Java heap space 是什麼原因呢？

解釋： 

Heap size 設定

JVM堆的設定是指java程式運作過程中JVM可以調配使用的記憶體空間的設定.JVM在啟動的時候會自動設定Heap size的值，其初始空間(即-Xms)是實體記憶體的1/64，最大空間(-Xmx)是實體記憶體的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等選項可進行設定。Heap size 的大小是Young Generation 和Tenured Generaion 之和。

提示：在JVM中如果98％的時間是用于GC且可用的Heap size 不足2％的時候将抛出此異常資訊。

提示：Heap Size 最大不要超過可用實體記憶體的80％，一般的要将-Xms和-Xmx選項設定為相同，而-Xmn為1/4的-Xmx值。

解決方法： 

      手動設定Heap size

      修改TOMCAT_HOME/bin/catalina.bat，在“echo "Using CATALINA_BASE:   $CATALINA_BASE"”上面加入以下行：

set JAVA_OPTS=%JAVA_OPTS% -server -Xms800m -Xmx800m   -XX:MaxNewSize=256m

或修改catalina.sh

在“echo "Using CATALINA_BASE:   $CATALINA_BASE"”上面加入以下行：

JAVA_OPTS="$JAVA_OPTS  -server -Xms800m -Xmx800m   -XX:MaxNewSize=256m"

另外看到了另外一個文章，覺得挺好，摘抄如下：

 主題: 分析java.lang.OutOfMemoryError: PermGen space

SUN JDK+Tomcat 5.5.20運作服務的時候遇到問題，伺服器跑幾天後就會挂掉，并報java.lang.OutOfMemoryError: PermGen space異常。

發現很多人把問題歸因于： spring,hibernate,tomcat，因為他們動态産生類,導緻JVM中的permanent heap溢出 。然後解決方法衆說紛纭，有人說更新 tomcat版本到最新甚至幹脆不用tomcat。還有人懷疑spring的問題，在spring論壇上讨論很激烈，因為spring在AOP時使用CBLIB會動态産生很多類。

但問題是為什麼這些王牌的開源會出現同一個問題呢，那麼是不是更基礎的原因呢？tomcat在Q&A很隐晦的回答了這一點，我們知道這個問題，但這個問題是由一個更基礎的問題産生。

于是有人對更基礎的JVM做了檢查，發現了問題的關鍵。原來SUN 的JVM把記憶體分了不同的區，其中一個就是permenter區用來存放用得非常多的類和類描述。本來SUN設計的時候認為這個區域在JVM啟動的時候就固定了，但他沒有想到現在動态會用得這麼廣泛。而且這個區域有特殊的垃圾收回機制，現在的問題是動态加載類到這個區域後，gc根本沒辦法回收！

2003年的時候就有一個bug報告給sun，但是到現在，這個bug還沒有close！有人在這個bug加了句評語：“A bug this critical is open since 2003? Absolutely shameful.” 我覺得SUN在這個BUG上确實有些丢臉。

對這個bug最徹底的解決辦法就是不要用SUN的JDK，而改用BEA的 JRokit.

打不過，還逃不過嗎？ 有衆多的選擇，這就是開源的好。 ：）

第三種：無法建立新的線程。

這種現象比較少見，也比較奇怪，主要是和jvm與系統記憶體的比例有關。

這種怪事是因為JVM已經被系統配置設定了大量的記憶體（比如1.5G），并且它至少要占用可用記憶體的一半。有人發現，線上程個數很多的情況下，你配置設定給JVM 的記憶體越多，那麼，上述錯誤發生的可能性就越大。

産生這種現象的原因如下（從這個blog中了解到原因：http://hi.baidu.com/hexiong/blog/item/16dc9e518fb10c2542a75b3c.html ）：

每一個32位的程序最多可以使用2G的可用記憶體，因為另外2G被作業系統保留。這裡假設使用1.5G給JVM，那麼還餘下500M可用記憶體。這500M内 存中的一部分必須用于系統dll的加載，那麼真正剩下的也許隻有400M，現在關鍵的地方出現了：當你使用Java 建立一個線程，在JVM的記憶體裡也會建立一個Thread對象，但是同時也會在作業系統裡建立一個真正 的實體線程（參考JVM規範），作業系統會在餘下的400兆記憶體裡建立這個實體線程，而不是在JVM的1500M的記憶體堆裡建立。在jdk1.4裡頭，默 認的棧大小是256KB，但是在jdk1.5裡頭，預設的棧大小為1M每線程，是以，在餘下400M的可用記憶體裡邊我們最多也隻能建立400個可用線程。

這樣結論就出來了，要想建立更多的線程，你必須減少配置設定給JVM的最大記憶體。還有一種做法是讓JVM宿主在你的JNI代碼裡邊。

給出一個有關能夠建立線程的最大個數的估算公式：

（MaxProcessMemory - JVMMemory - ReservedOsMemory） / （ThreadStackSize） = Number of threads

對于jdk1.5而言，假設作業系統保留120M記憶體：

1.5GB JVM： （2GB-1.5Gb-120MB）/（1MB） = ~380 threads

1.0GB JVM： （2GB-1.0Gb-120MB）/（1MB） = ~880 threads

在2000/XP/2003的boot.ini裡頭有一個啟動選項，好像是：/PAE /3G ，可以讓使用者程序最大記憶體擴充至3G，這時作業系統隻能占用最多1G的虛存。那樣應該可以讓JVM建立更多的線程。

是以這種情況需要結合作業系統進行相關調整。

是以：我們需要結合不同情況對tomcat記憶體配置設定進行不同的診斷才能從根本上解決問題。