Java常見內存溢出異常分析

Java虛擬機規範規定JVM的內存分爲了好幾塊，好比堆，棧，程序計數器，方法區等，而Hotspot jvm的實現中，將堆內存分爲了三部分，新生代，老年代，持久帶，其中持久帶實現了規範中規定的方法區，而內存模型中不一樣的部分都會出現相應的OOM錯誤，接下來咱們就分開來討論一下。 

棧溢出(StackOverflowError) 

棧溢出拋出java.lang.StackOverflowError錯誤，出現此種狀況是由於方法運行的時候棧的深度超過了虛擬機允許的最大深度所致。 

出現這種狀況，通常狀況下是程序錯誤所致的，好比寫了一個死遞歸，就有可能形成此種狀況。 下面咱們經過一段代碼來模擬一下此種狀況的內存溢出。 

Java代碼 

1. import java.util.*;  
2. import java.lang.*;  
3. public class OOMTest{  
4.    
5.   public void stackOverFlowMethod(){  
6.       stackOverFlowMethod();  
7.   }  
8.    
9.   public static void main(String... args){  
10.       OOMTest oom = new OOMTest();  
11.       oom.stackOverFlowMethod();  
12.   }  
13.    
14. }  

運行上面的代碼，會拋出以下的異常： 

引用

Exception in thread "main" java.lang.StackOverflowError 
        at OOMTest.stackOverFlowMethod(OOMTest.java:6) 

堆溢出(OutOfMemoryError:java heap space) 

堆內存溢出的時候，虛擬機會拋出java.lang.OutOfMemoryError:java heap space,出現此種狀況的時候，咱們須要根據內存溢出的時候產生的dump文件來具體分析（須要增長-XX:+HeapDumpOnOutOfMemoryErrorjvm啓動參數）。出現此種問題的時候有多是內存泄露，也有多是內存溢出了。 
若是內存泄露，咱們要找出泄露的對象是怎麼被GC ROOT引用起來，而後經過引用鏈來具體分析泄露的緣由。 
若是出現了內存溢出問題，這每每是程序本生須要的內存大於了咱們給虛擬機配置的內存，這種狀況下，咱們能夠採用調大-Xmx來解決這種問題。 

下面咱們經過以下的代碼來演示一下此種狀況的溢出： 

Java代碼 

1. import java.util.*;  
2. import java.lang.*;  
3. public class OOMTest{  
4.    
5.         public static void main(String... args){  
6.                 List<byte[]> buffer = new ArrayList<byte[]>();  
7.                 buffer.add(new byte[10*1024*1024]);  
8.         }  
9.    
10. }  

咱們經過以下的命令運行上面的代碼： 

Java代碼 

1. java -verbose:gc -Xmn10M -Xms20M -Xmx20M -XX:+PrintGC OOMTest  

程序輸入以下的信息： 

引用

[GC 1180K->366K(19456K), 0.0037311 secs] 
[Full GC 366K->330K(19456K), 0.0098740 secs] 
[Full GC 330K->292K(19456K), 0.0090244 secs] 
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space 
        at OOMTest.main(OOMTest.java:7) 

從運行結果能夠看出，JVM進行了一次Minor gc和兩次的Major gc，從Major gc的輸出能夠看出，gc之後old區使用率爲134K，而字節數組爲10M，加起來大於了old generation的空間，因此拋出了異常，若是調整-Xms21M,-Xmx21M,那麼就不會觸發gc操做也不會出現異常了。 

經過上面的實驗其實也從側面驗證了一個結論：當對象大於新生代剩餘內存的時候，將直接放入老年代，當老年代剩餘內存仍是沒法放下的時候，出發垃圾收集，收集後仍是不能放下就會拋出內存溢出異常了 

持久帶溢出(OutOfMemoryError: PermGen space) 

咱們知道Hotspot jvm經過持久帶實現了Java虛擬機規範中的方法區，而運行時的常量池就是保存在方法區中的，所以持久帶溢出有多是運行時常量池溢出，也有多是方法區中保存的class對象沒有被及時回收掉或者class信息佔用的內存超過了咱們配置。當持久帶溢出的時候拋出java.lang.OutOfMemoryError: PermGen space。 
我在工做可能在以下幾種場景下出現此問題。 

1.使用一些應用服務器的熱部署的時候，咱們就會遇到熱部署幾回之後發現內存溢出了，這種狀況就是由於每次熱部署的後，原來的class沒有被卸載掉。 
2.若是應用程序自己比較大，涉及的類庫比較多，可是咱們分配給持久帶的內存（經過-XX:PermSize和-XX:MaxPermSize來設置）比較小的時候也可能出現此種問題。 
3.一些第三方框架，好比spring,hibernate都經過字節碼生成技術（好比CGLib）來實現一些加強的功能，這種狀況可能須要更大的方法區來存儲動態生成的Class文件。 
咱們知道Java中字符串常量是放在常量池中的，String.intern()這個方法運行的時候，會檢查常量池中是否存和本字符串相等的對象，若是存在直接返回對常量池中對象的引用，不存在的話，先把此字符串加入常量池，而後再返回字符串的引用。那麼咱們就能夠經過String.intern方法來模擬一下運行時常量區的溢出.下面咱們經過以下的代碼來模擬此種狀況： 

Java代碼 

1. import java.util.*;  
2. import java.lang.*;  
3. public class OOMTest{  
4.    
5.         public static void main(String... args){  
6.                 List<String> list = new ArrayList<String>();  
7.                 while(true){  
8.                         list.add(UUID.randomUUID().toString().intern());  
9.                 }  
10.         }  
11.    
12. }  

咱們經過以下的命令運行上面代碼： 
java -verbose:gc -Xmn5M -Xms10M -Xmx10M -XX:MaxPermSize=1M -XX:+PrintGC OOMTest 
運行後的輸入以下圖所示: 

引用

Exception in thread "main" java.lang.OutOfMemoryError: PermGen space 
        at java.lang.String.intern(Native Method) 
        at OOMTest.main(OOMTest.java:8) 

經過上面的代碼，咱們成功模擬了運行時常量池溢出的狀況，從輸出中的PermGen space能夠看出確實是持久帶發生了溢出，這也驗證了，咱們前面說的Hotspot jvm經過持久帶來實現方法區的說法。 

OutOfMemoryError:unable to create native thread 

最後咱們在來看看java.lang.OutOfMemoryError:unable to create natvie thread這種錯誤。 出現這種狀況的時候，通常是下面兩種狀況致使的： 

1.程序建立的線程數超過了操做系統的限制。對於Linux系統，咱們能夠經過ulimit -u來查看此限制。 
給虛擬機分配的內存過大，致使建立線程的時候須要的native內存太少。咱們都知道操做系統對每一個進程的內存是有限制的，咱們啓動Jvm,至關於啓動了一個進程，假如咱們一個進程佔用了4G的內存，那麼經過下面的公式計算出來的剩餘內存就是創建線程棧的時候能夠用的內存。 線程棧總可用內存=4G-（-Xmx的值）- （-XX:MaxPermSize的值）- 程序計數器佔用的內存 經過上面的公式咱們能夠看出，-Xmx 和 MaxPermSize的值越大，那麼留給線程棧可用的空間就越小，在-Xss參數配置的棧容量不變的狀況下，能夠建立的線程數也就越小。所以若是是由於這種狀況致使的unable to create native thread,那麼要麼咱們增大進程所佔用的總內存，或者減小-Xmx或者-Xss來達到建立更多線程的目的。

1、內存溢出類型

一、java.lang.OutOfMemoryError: PermGen space

JVM管理兩種類型的內存，堆和非堆。堆是給開發人員用的上面說的就是，是在JVM啓動時建立；非堆是留給JVM本身用的，用來存放類的信息的。它和堆不一樣，運行期內GC不會釋放空間。若是web app用了大量的第三方jar或者應用有太多的class文件而剛好MaxPermSize設置較小，超出了也會致使這塊內存的佔用過多形成溢出，或者tomcat熱部署時侯不會清理前面加載的環境，只會將context更改成新部署的，非堆存的內容就會愈來愈多。

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)那麼就會產生此錯誤信息了。 
一個最佳的配置例子：(通過本人驗證，自從用此配置以後，再未出現過tomcat死掉的狀況)

set JAVA_OPTS=-Xms800m -Xmx800m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m

二、java.lang.OutOfMemoryError: Java heap space

第一種狀況是個補充，主要存在問題就是出如今這個狀況中。其默認空間(即-Xms)是物理內存的1/64，最大空間(-Xmx)是物理內存的1/4。若是內存剩餘不到40％，JVM就會增大堆到Xmx設置的值，內存剩餘超過70％，JVM就會減少堆到Xms設置的值。因此服務器的Xmx和Xms設置通常應該設置相同避免每次GC後都要調整虛擬機堆的大小。假設物理內存無限大，那麼JVM內存的最大值跟操做系統有關，通常32位機是1.5g到3g之間，而64位的就不會有限制了。

注意：若是Xms超過了Xmx值，或者堆最大值和非堆最大值的總和超過了物理內存或者操做系統的最大限制都會引發服務器啓動不起來。

垃圾回收GC的角色

JVM調用GC的頻度仍是很高的，主要兩種狀況下進行垃圾回收：

當應用程序線程空閒；另外一個是java內存堆不足時，會不斷調用GC，若連續回收都解決不了內存堆不足的問題時，就會報out of memory錯誤。由於這個異常根據系統運行環境決定，因此沒法預期它什麼時候出現。

根據GC的機制，程序的運行會引發系統運行環境的變化，增長GC的觸發機會。

爲了不這些問題，程序的設計和編寫就應避免垃圾對象的內存佔用和GC的開銷。顯示調用System.GC()只能建議JVM須要在內存中對垃圾對象進行回收，但不是必須立刻回收，

一個是並不能解決內存資源耗空的局面，另外也會增長GC的消耗。

2、JVM內存區域組成

簡單的說java中的堆和棧

java把內存分兩種：一種是棧內存，另外一種是堆內存

1。在函數中定義的基本類型變量和對象的引用變量都在函數的棧內存中分配；

2。堆內存用來存放由new建立的對象和數組

在函數（代碼塊）中定義一個變量時，java就在棧中爲這個變量分配內存空間，當超過變量的做用域後，java會自動釋放掉爲該變量所分配的內存空間；在堆中分配的內存由java虛擬機的自動垃圾回收器來管理

堆的優點是能夠動態分配內存大小，生存期也沒必要事先告訴編譯器，由於它是在運行時動態分配內存的。缺點就是要在運行時動態分配內存，存取速度較慢；

棧的優點是存取速度比堆要快，缺點是存在棧中的數據大小與生存期必須是肯定的無靈活性。

java堆分爲三個區：New、Old和Permanent

GC有兩個線程：

新建立的對象被分配到New區，當該區被填滿時會被GC輔助線程移到Old區，當Old區也填滿了會觸發GC主線程遍歷堆內存裏的全部對象。Old區的大小等於Xmx減去-Xmn

java棧存放

棧調整：參數有+UseDefaultStackSize -Xss256K，表示每一個線程可申請256k的棧空間

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

3、JVM如何設置虛擬內存

提示：在JVM中若是98％的時間是用於GC且可用的Heap size 不足2％的時候將拋出此異常信息。

提示：Heap Size 最大不要超過可用物理內存的80％，通常的要將-Xms和-Xmx選項設置爲相同，而-Xmn爲1/4的-Xmx值。

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

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

提示：假設物理內存無限大的話，JVM內存的最大值跟操做系統有很大的關係。

簡單的說就32位處理器雖然可控內存空間有4GB,可是具體的操做系統會給一個限制，

這個限制通常是2GB-3GB（通常來講Windows系統下爲1.5G-2G，Linux系統下爲2G-3G），而64bit以上的處理器就不會有限制了

提示：注意：若是Xms超過了Xmx值，或者堆最大值和非堆最大值的總和超過了物理內存或者操做系統的最大限制都會引發服務器啓動不起來。

提示：設置NewSize、MaxNewSize相等，"new"的大小最好不要大於"old"的一半，緣由是old區若是不夠大會頻繁的觸發"主" GC ，大大下降了性能

JVM使用-XX:PermSize設置非堆內存初始值，默認是物理內存的1/64；

由XX:MaxPermSize設置最大非堆內存的大小，默認是物理內存的1/4。

解決方法：手動設置Heap size

修改TOMCAT_HOME/bin/catalina.bat

在「echo "Using CATALINA_BASE: $CATALINA_BASE"」上面加入如下行：

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

4、性能檢查工具使用

定位內存泄漏：

JProfiler工具主要用於檢查和跟蹤系統（限於Java開發的）的性能。JProfiler能夠經過時時的監控系統的內存使用狀況，隨時監視垃圾回收，線程運行情況等手段，從而很好的監視JVM運行狀況及其性能。

1. 應用服務器內存長期不合理佔用，內存常常處於高位佔用，很難回收到低位；

2. 應用服務器極爲不穩定，幾乎每兩天從新啓動一次，有時甚至天天從新啓動一次；

3. 應用服務器常常作Full GC(Garbage Collection)，並且時間很長，大約須要30-40秒，應用服務器在作Full GC的時候是不響應客戶的交易請求的，很是影響系統性能。

由於開發環境和產品環境會有不一樣，致使該問題發生有時會在產品環境中發生，一般可使用工具跟蹤系統的內存使用狀況，在有些個別狀況下或許某個時刻確實是使用了大量內存致使out of memory，這時應繼續跟蹤看接下來是否會有降低，

若是一直居高不下這確定就由於程序的緣由致使內存泄漏。

5、不健壯代碼的特徵及解決辦法

一、儘早釋放無用對象的引用。好的辦法是使用臨時變量的時候，讓引用變量在退出活動域後，自動設置爲null，暗示垃圾收集器來收集該對象，防止發生內存泄露。

對於仍然有指針指向的實例，jvm就不會回收該資源,由於垃圾回收會將值爲null的對象做爲垃圾，提升GC回收機制效率；

二、咱們的程序裏不可避免大量使用字符串處理，避免使用String，應大量使用StringBuffer，每個String對象都得獨立佔用內存一塊區域；

String str = "aaa";

String str2 = "bbb";

String str3 = str + str2;//假如執行這次以後str ,str2之後再不被調用,那它就會被放在內存中等待Java的gc去回收,程序內過多的出現這樣的狀況就會報上面的那個錯誤,建議在使用字符串時能使用StringBuffer就不要用String,這樣能夠省很多開銷；

三、儘可能少用靜態變量，由於靜態變量是全局的，GC不會回收的；

四、避免集中建立對象尤爲是大對象，JVM會忽然須要大量內存，這時必然會觸發GC優化系統內存環境；顯示的聲明數組空間，並且申請數量還極大。

這是一個案例想定供你們警惕

使用jspsmartUpload做文件上傳,運行過程當中常常出現java.outofMemoryError的錯誤，

檢查以後發現問題：組件裏的代碼

m_totalBytes = m_request.getContentLength();

m_binArray = new byte[m_totalBytes];

問題緣由是totalBytes這個變量獲得的數極大，致使該數組分配了不少內存空間，並且該數組不能及時釋放。解決辦法只能換一種更合適的辦法，至少是不會引起outofMemoryError的方式解決。參考：http://bbs.xml.org.cn/blog/more.asp?name=hongrui&id=3747

五、儘可能運用對象池技術以提升系統性能；生命週期長的對象擁有生命週期短的對象時容易引起內存泄漏，例如大集合對象擁有大數據量的業務對象的時候，能夠考慮分塊進行處理，而後解決一塊釋放一塊的策略。

六、不要在常常調用的方法中建立對象，尤爲是忌諱在循環中建立對象。能夠適當的使用hashtable，vector 建立一組對象容器，而後從容器中去取那些對象，而不用每次new以後又丟棄

七、通常都是發生在開啓大型文件或跟數據庫一次拿了太多的數據，形成 Out Of Memory Error 的情況，這時就大概要計算一下數據量的最大值是多少，而且設定所需最小及最大的內存空間值。