http://www.importnew.com/14604.html

http://blog.csdn.net/znb769525443/article/details/50853712

簡介

Java虛擬機器規範規定JVM的記憶體分為了好幾塊，比如堆，棧，程式計數器，方法區等，而Hotspot jvm的實現中，將堆記憶體分為了三部分，新生代，老年代，持久帶，其中持久帶實現了規範中規定的方法區，而記憶體模型中不同的部分都會出現相應的OutOfMemoryError錯誤，接下來我們就分開來討論一下。java.lang.OutOfMemoryError這個錯誤我相信大部分開發人員都有遇到過，產生該錯誤的原因大都出於以下原因：

JVM記憶體過小、程式不嚴密，產生了過多的垃圾。

導致OutOfMemoryError異常的常見原因有以下幾種：

1. 記憶體中載入的資料量過於龐大，如一次從資料庫取出過多資料；
2. 集合類中有對物件的引用，使用完後未清空，使得JVM不能回收；
3. 程式碼中存在死迴圈或迴圈產生過多重複的物件實體；
4. 使用的第三方軟體中的BUG；
5. 啟動引數記憶體值設定的過小；

此錯誤常見的錯誤提示：

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

棧溢位(StackOverflowError)

棧溢位丟擲java.lang.StackOverflowError錯誤，出現此種情況是因為方法執行的時候棧的深度超過了虛擬機器容許的最大深度所致。出現這種情況，一般情況下是程式錯誤所致的，比如寫了一個死遞迴，就有可能造成此種情況。 下面我們通過一段程式碼來模擬一下此種情況的記憶體溢位。

1. import java.util.*;  
2. import java.lang.*;  
3. publicclass OOMTest{  
4.   publicvoid stackOverFlowMethod(){  
5.       stackOverFlowMethod();  
6.   }  
7.   publicstaticvoid main(String... args){  
8.       OOMTest oom = new OOMTest();  
9.       oom.stackOverFlowMethod();  
10.   }  
11. }  

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

堆溢位(OutOfMemoryError:java heap space)

堆記憶體溢位的時候，虛擬機器會丟擲java.lang.OutOfMemoryError:java heap space,出現此種情況的時候，我們需要根據記憶體溢位的時候產生的dump檔案來具體分析（需要增加-XX:+HeapDumpOnOutOfMemoryErrorjvm啟動引數）。出現此種問題的時候有可能是記憶體洩露，也有可能是記憶體溢位了。
如果記憶體洩露，我們要找出洩露的物件是怎麼被GC ROOT引用起來，然後通過引用鏈來具體分析洩露的原因。
如果出現了記憶體溢位問題，這往往是程式本生需要的記憶體大於了我們給虛擬機器配置的記憶體，這種情況下，我們可以採用調大-Xmx來解決這種問題。

下面我們通過如下的程式碼來演示一下此種情況的溢位：

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

我們通過如下的命令執行上面的程式碼：

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

1. [GC 1180K->366K(19456K), 0.0037311 secs]  
2. [Full GC 366K->330K(19456K), 0.0098740 secs]  
3. [Full GC 330K->292K(19456K), 0.0090244 secs]  
4. Exception in thread "main" java.lang.OutOfMemoryError: Java heap space  
5.         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方法來模擬一下執行時常量區的溢位.下面我們通過如下的程式碼來模擬此種情況：

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

我們通過如下的命令執行上面程式碼：

java -verbose:gc -Xmn5M -Xms10M -Xmx10M -XX:MaxPermSize=1M -XX:+PrintGC OOMTest

執行後的輸入如下圖所示:

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

OutOfMemoryError:unable to create native thread

最後我們在來看看java.lang.OutOfMemoryError:unable to create natvie thread這種錯誤。 出現這種情況的時候，一般是下面兩種情況導致的：

1. 程式建立的執行緒數超過了作業系統的限制。對於Linux系統，我們可以通過ulimit -u來檢視此限制。
2. 給虛擬機器分配的記憶體過大，導致建立執行緒的時候需要的native記憶體太少。我們都知道作業系統對每個程序的記憶體是有限制的，我們啟動Jvm,相當於啟動了一個程序，假如我們一個程序佔用了4G的記憶體，那麼通過下面的公式計算出來的剩餘記憶體就是建立執行緒棧的時候可以用的記憶體。 執行緒棧總可用記憶體=4G-（-Xmx的值）- （-XX:MaxPermSize的值）- 程式計數器佔用的記憶體 通過上面的公式我們可以看出，-Xmx 和 MaxPermSize的值越大，那麼留給執行緒棧可用的空間就越小，在-Xss引數配置的棧容量不變的情況下，可以建立的執行緒數也就越小。因此如果是因為這種情況導致的unable to create native thread,那麼要麼我們增大程序所佔用的總記憶體，或者減少-Xmx或者-Xss來達到建立更多執行緒的目的。