java.lang.OutOfMemoryError異常解決方法

java.lang.OutOfMemoryError異常解決方法

 

 

 

緣由：
常見的有如下幾種：

 

1.內存中加載的數據量過於龐大，如一次從數據庫取出過多數據；

 

2.集合類中有對對象的引用，使用完後未清空，使得JVM不能回收；

 

3.代碼中存在死循環或循環產生過多重複的對象實體；

 

4.使用的第三方軟件中的BUG；

 

5.啓動參數內存值設定的太小；

6.加載太多資源到內存，致使GC耗時較多

 

常見錯誤提示：
1.tomcat:java.lang.OutOfMemoryError: PermGen space

 

2.tomcat:java.lang.OutOfMemoryError: Java heap space

 

3.weblogic:Root cause of ServletException java.lang.OutOfMemoryError

 

4.resin:java.lang.OutOfMemoryError

 

5.java:java.lang.OutOfMemoryError

6.java.lang.OutOfMemoryError：GC overhead limit exceeded

解決；

1.應用服務器提示錯誤的解決：
把啓動參數內存值設置足夠大。

2.Java代碼致使錯誤的解決：

重點排查如下幾點：

1)檢查代碼中是否有死循環或遞歸調用。

2)檢查是否有大循環重複產生新對象實體。

3)檢查對數據庫查詢中，是否有一次得到所有數據的查詢。通常來講，若是一次取十萬條記錄到內存，就可能引發內存溢出。這個問題比較隱蔽，在上線前，數據庫中數據較少，不容易出問題，上線後，數據庫中數據多了，一次查詢就有可能引發內存溢出。所以對於數據庫查詢儘可能採用分頁的方式查詢。

4 )檢查List、MAP等集合對象是否有使用完後，未清除的問題。List、MAP等集合對象會始終存有對對象的引用，使得這些對象不能被GC回收。

 

案例：
1.hibernate查詢數據時，一次查詢過多的數據，後來調整了該部分的代碼，每次只取出指定量的數據，成功的解決該問題。
2.在作壓力測試時，出現OutOfMemoryError，發現session的資源一直沒有被釋放產生的，最好經過session的invalidate()方法將session的資源釋放。
3.程序中出現死循環。
4.tomcat部署、運行出現OutOfMemoryError，加大內存參數值，解決此問題。

 

tomcat中java.lang.OutOfMemoryError: Java heap space異常處理

 

1、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值。

2、解決：手動設置Heap size

修改TOMCAT_HOME/bin/catalina.sh
在「echo "Using CATALINA_BASE:   $CATALINA_BASE"」上面加入如下行：
JAVA_OPTS="-server -Xms800m -Xmx800m   -XX:MaxNewSize=256m"

tomcat中java.lang.OutOfMemoryError: PermGen space異常處理

 

1、PermGen space
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)那麼就會產生此錯誤信息了。

 

解決方法： 手動設置MaxPermSize大小
修改TOMCAT_HOME/bin/catalina.sh
在「echo "Using CATALINA_BASE:   $CATALINA_BASE"」上面加入如下行：
JAVA_OPTS="-server -XX:PermSize=64M -XX:MaxPermSize=128m
建議：將相同的第三方jar文件移置到tomcat/shared/lib目錄下，這樣能夠達到減小jar 文檔重複佔用內存的目的。

weblogic中java.lang.OutOfMemoryError異常處理

 

錯誤提示：
"Root cause of ervletException java.lang.OutOfMemoryError"

 

解決：
調整bea/weblogic/common中CommEnv中參數
　　 :sun
　　if "%PRODUCTION_MODE%" == "true" goto sun_prod_mode
　　set JAVA_VM=-client
　　set MEM_ARGS=-Xms256m -Xmx512m -XX:MaxPermSize=256m
　　set JAVA_OPTIONS=%JAVA_OPTIONS% -Xverify:none
　　goto continue
　　:sun_prod_mode
　　set JAVA_VM=-server
　　set MEM_ARGS=-Xms256m -Xmx512m -XX:MaxPermSize=256m
　　goto continue

 

Eclipse運行Jboss時java.lang.OutOfMemoryError：PermGen space異常處理

在Eclipse中運行Jboss時，時間太長可能有時候會出現java.lang.OutOfMemoryError：PermGen space的錯誤，這裏給介紹你們一種解決方法：

1)點擊debug圖標旁邊的小箭頭；

2)點擊」Debug Configurations…」菜單項；

3)選左邊的「Generic Server」樹下面的「JBoss v4.2 at localhost」；

4)點擊右邊的「Arguments」Tab頁籤，在「VM arguments」中添加：

-Dprogram.name=run.bat -Djava.endorsed.dirs="D:/JBoss405/bin/../lib/endorsed" -Xms128m -Xmx512m -XX:PermSize=64m -XX:MaxPermSize=256m

5)若是你是以命令行模式或者直接點擊「run.bat」來運行JBoss，那你就要在 bin/run.conf 文件中對JVM選項做修改了，找到 JAVA_OPTS="-Xms128m -Xmx512m…」 這一段，而後在後面加上 「 -XX:PermSize=64m -XX:MaxPermSize=256m」。保存就OK了。

6)注意：其中12八、5十二、64和256等數字能夠根據本身機器的配置來作一些相應的調整，而後點擊「Apply」就能夠了。

 

Resin下java.lang.OutOfMemoryError異常處理

緣由：
出現這個錯誤，通常是由於JVM物理內存太小。默認的Java虛擬機最大內存僅爲64兆，這在開發調試過程當中可能沒有問題，但在實際的應用環境中是遠遠不能知足須要的，除非你的應用很是小，也沒什麼訪問量。不然你可能會發現程序運行一段時間後包java.lang.OutOfMemoryError的錯誤。所以咱們須要提高resin可用的虛擬機內存的大小。

解決：
修改/usr/local/resin/bin/httpd.sh中的args選項
添加參數-Xms（初始內存）和-Xmx（最大可以使用內存大小）
能夠用來限制JVM的物理內存使用量。
例如：
args="-Xms128m -Xmx256m"
設置後，JVM初始物理內存是128m，最大能使用物理內存爲256m。
這兩個值應該由系統管理員根據服務器的實際狀況進行設置。

 

java.lang.OutOfMemoryError：GC overhead limit exceeded異常處理

緣由：

java.lang.OutOfMemoryError：GC overhead limit exceeded致使服務起不來，查看日誌發現加載了太多資源到內存，本地的性能也很差，gc時間消耗的較多。

OOM你們都知道，就是JVM內存溢出了，那GC overhead limit exceed呢？

GC overhead limt exceed檢查是Hotspot VM 1.6定義的一個策略，經過統計GC時間來預測是否要OOM了，提早拋出異常，防止OOM發生。Sun 官方對此的定義是：「並行/併發回收器在GC回收時間過長時會拋出OutOfMemroyError。過長的定義是，超過98%的時間用來作GC而且回收了不到2%的堆內存。用來避免內存太小形成應用不能正常工做。「

聽起來沒啥用...預測OOM有啥用？起初開來這玩意只能用來Catch住釋放內存資源，避免應用掛掉。後來發現通常狀況下這個策略不能拯救你的應用，可是能夠在應用掛掉以前作最後的掙扎，好比數據保存或者保存現場（Heap Dump）。

並且有些時候這個策略還會帶來問題，好比加載某個大的內存數據時頻繁OOM。

假如你也生產環境中遇到了這個問題，在不知道緣由時不要簡單的猜想和規避。能夠經過-verbose:gc -XX:+PrintGCDetails看下到底什麼緣由形成了異常。一般緣由都是由於old區佔用過多致使頻繁Full GC，最終致使GC overhead limit exceed。若是gc log不夠能夠藉助於JProfile等工具查看內存的佔用，old區是否有內存泄露。分析內存泄露還有一個方法-XX:+HeapDumpOnOutOfMemoryError，這樣OOM時會自動作Heap Dump，能夠拿MAT來排查了。還要留意young區，若是有過多短暫對象分配，可能也會拋這個異常。

日誌的信息不難理解，就是每次gc時打條日誌，記錄GC的類型，先後大小和時間。舉個例子。

33.125: [GC [DefNew: 16000K->16000K(16192K), 0.0000574 secs][Tenured: 2973K->2704K(16384K), 0.1012650 secs] 18973K->2704K(32576K), 0.1015066 secs]

100.667:[Full GC [Tenured: 0K->210K(10240K), 0.0149142 secs] 4603K->210K(19456K), [Perm : 2999K->2999K(21248K)], 0.0150007 secs] 

GC和Full GC表明gc的停頓類型，Full GC表明stop-the-world。箭頭兩邊是gc先後的區空間大小，分別是young區、tenured區和perm區，括號裏是該區的總大小。冒號前面是gc發生的時間，單位是秒，從jvm啓動開始計算。DefNew表明Serial收集器，爲Default New Generation的縮寫，相似的還有PSYoungGen，表明Parallel Scavenge收集器。這樣能夠經過分析日誌找到致使GC overhead limit exceeded的緣由，經過調節相應的參數解決問題。

文中涉及到的名詞解釋，

Eden Space：堆內存池，大多數對象在這裏分配內存空間。

Survivor Space：堆內存池，存儲在Eden Space的gc中存活下來的對象。

Tenured Generation：堆內存池，存儲Survivor Space中存活過幾回gc的對象。

Permanent Generation：非堆空間，存儲的是class和method對象。

Code Cache：非堆空間，JVM用來存儲編譯和存儲native code。

解決：

1.增長參數，-XX:-UseGCOverheadLimit，關閉這個特性，同時增長heap大小，-Xmx1024m。

2.排查並優化消耗內存資源代碼.