Java 堆 OutOfMemoryError

　　Java 堆是用來存儲(chǔ)對(duì)象實(shí)例的， 因此如果我們不斷地創(chuàng)建對(duì)象， 并且保證 GC Root 和創(chuàng)建的對(duì)象之間有可達(dá)路徑以免對(duì)象被垃圾回收， 那么當(dāng)創(chuàng)建的對(duì)象過多時(shí)， 會(huì)導(dǎo)致 heap 內(nèi)存不足， 進(jìn)而引發(fā) OutOfMemoryError 異常。

　　public class OutOfMemoryErrorTest{

　　public static void main （String［］ args）{

　　List《Integer》 list = new ArryList《》（）;

　　int i=0;

　　while（true）{

　　list.add（i++）;

　　}}}

　　上面是一個(gè)引發(fā) OutOfMemoryError 異常的代碼， 我們可以看到， 它就是通過不斷地創(chuàng)建對(duì)象， 并將對(duì)象保存在 list 中防止其被垃圾回收， 因此當(dāng)對(duì)象過多時(shí)， 就會(huì)使堆內(nèi)存溢出。

　　通過 java -Xms10m -Xmx10m -XX：+HeapDumpOnOutOfMemoryError 我們?cè)O(shè)置了堆內(nèi)存為 10 兆， 并且使用參數(shù) -XX：+HeapDumpOnOutOfMemoryError 讓 JVM 在發(fā)生 OutOfMemoryError 異常時(shí)打印出當(dāng)前的內(nèi)存快照以便于后續(xù)分析。

　　編譯運(yùn)行上述代碼后， 會(huì)有如下輸出：

　　》》》java -Xms10m - Xms10m-XX:HeapDumpOnOutOfMemoryError com.test.OutOfMemoryErrorTest 16-10-12 10:28

　　java.lang.OutOfMemoryError:Java heap space

　　Dumping heap to java_pid1810.hprof.。。

　　Heap dump file created ［14212861 bytes in 0.128 secs］

　　Exception in thread “main” java.lang.OutOfMemoryError:Java heap space

　　at java.util.Arrays.copyof（Arrays.java:3210）

　　at java.util.Arrays.copyof（Arrays.java:3181）

　　堆內(nèi)存溢出的時(shí)候，虛擬機(jī)會(huì)拋出java.lang.OutOfMemoryError:java heap space，出現(xiàn)此種情況的時(shí)候，我們需要根據(jù)內(nèi)存溢出的時(shí)候產(chǎn)生的dump文件來具體分析（需要增加-XX：+HeapDumpOnOutOfMemoryErrorjvm啟動(dòng)參數(shù)）。出現(xiàn)此種問題的時(shí)候有可能是內(nèi)存泄露，也有可能是內(nèi)存溢出了。

　　如果內(nèi)存泄露，我們要找出泄露的對(duì)象是怎么被GC ROOT引用起來，然后通過引用鏈來具體分析泄露的原因。

　　如果出現(xiàn)了內(nèi)存溢出問題，這往往是程序本生需要的內(nèi)存大于了我們給虛擬機(jī)配置的內(nèi)存，這種情況下，我們可以采用調(diào)大-Xmx來解決這種問題。

　　下面我們通過如下的代碼來演示一下此種情況的溢出：

　?。踛ava］ view plain copyimport java.util.*;

　　import java.lang.*;

　　public class OOMTest{

　　public static void main（String.。。 args）{

　　List《byte［］》 buffer = new ArrayList《byte［］》（）;

　　buffer.add（new byte［10*1024*1024］）;

　　}

　　}

　　我們通過如下的命令運(yùn)行上面的代碼：

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

　　程序輸入如下的信息：

　?。踦lain］ view plain copy［GC 1180K-》366K（19456K）， 0.0037311 secs］

　?。跢ull GC 366K-》330K（19456K）， 0.0098740 secs］

　?。跢ull GC 330K-》292K（19456K）， 0.0090244 secs］

　　Exception in thread “main” java.lang.OutOfMemoryError： Java heap space

　　at OOMTest.main（OOMTest.java:7）

　　從運(yùn)行結(jié)果可以看出，JVM進(jìn)行了一次Minor gc和兩次的Major gc，從Major gc的輸出可以看出，gc以后old區(qū)使用率為134K，而字節(jié)數(shù)組為10M，加起來大于了old generation的空間，所以拋出了異常，如果調(diào)整-Xms21M，-Xmx21M，那么就不會(huì)觸發(fā)gc操作也不會(huì)出現(xiàn)異常了。

　　Java 棧 StackOverflowError

　　我們知道， JVM 的運(yùn)行時(shí)數(shù)據(jù)區(qū)中有一個(gè)叫做 虛擬機(jī)棧 的內(nèi)存區(qū)域， 此區(qū)域的作用是： 每個(gè)方法在執(zhí)行時(shí)都會(huì)創(chuàng)建一個(gè)棧幀， 用于存儲(chǔ)局部變量表， 操作數(shù)棧， 方法出口等信息。

　　因此我們可以創(chuàng)建一個(gè)無限遞歸的遞歸調(diào)用， 當(dāng)遞歸深度過大時(shí)， 就會(huì)耗盡?？臻g， 進(jìn)而導(dǎo)致了 StackOverflowError 異常。

　　下面是具體的代碼：

　　public class OutOfMemoryErrorTest{

　　public static void main （String ［］ srgs）{

　　stackOutOfMemoryError（1）;

　?。?/p>

　　public static void stackOutOfMemoryError（int depth）{

　　depth++;

　　stackOutOfMemoryError（depth）;

　　}}

　　當(dāng)編譯運(yùn)行上述的代碼后， 會(huì)輸出如下異常信息：

　　Exception in thread “main” java.lang.StackOverflowError

　　at com.test.OutOfMemoryErrorTest.stackOutOfMemoryError（OutOfMemoryErrorTest.java:27）

　　棧溢出拋出java.lang.StackOverflowError錯(cuò)誤，出現(xiàn)此種情況是因?yàn)榉椒ㄟ\(yùn)行的時(shí)候棧的深度超過了虛擬機(jī)容許的最大深度所致。

　　出現(xiàn)這種情況，一般情況下是程序錯(cuò)誤所致的，比如寫了一個(gè)死遞歸，就有可能造成此種情況。 下面我們通過一段代碼來模擬一下此種情況的內(nèi)存溢出。

　?。踛ava］ view plain copyimport java.util.*;

　　import java.lang.*;

　　public class OOMTest{

　　public void stackOverFlowMethod（）{

　　stackOverFlowMethod（）;

　　}

　　public static void main（String.。。 args）{

　　OOMTest oom = new OOMTest（）;

　　oom.stackOverFlowMethod（）;

　　}

　　}

　　運(yùn)行上面的代碼，會(huì)拋出如下的異常：

　?。踦lain］ view plain copyException in thread “main” java.lang.StackOverflowError

　　at OOMTest.stackOverFlowMethod（OOMTest.java:6）

　　通過上面的實(shí)驗(yàn)其實(shí)也從側(cè)面驗(yàn)證了一個(gè)結(jié)論：當(dāng)對(duì)象大于新生代剩余內(nèi)存的時(shí)候，將直接放入老年代，當(dāng)老年代剩余內(nèi)存還是無法放下的時(shí)候，出發(fā)垃圾收集，收集后還是不能放下就會(huì)拋出內(nèi)存溢出異常了

　　持久帶溢出（OutOfMemoryError： PermGen space）

　　我們知道Hotspot jvm通過持久帶實(shí)現(xiàn)了Java虛擬機(jī)規(guī)范中的方法區(qū)，而運(yùn)行時(shí)的常量池就是保存在方法區(qū)中的，因此持久帶溢出有可能是運(yùn)行時(shí)常量池溢出，也有可能是方法區(qū)中保存的class對(duì)象沒有被及時(shí)回收掉或者class信息占用的內(nèi)存超過了我們配置。當(dāng)持久帶溢出的時(shí)候拋出java.lang.OutOfMemoryError： PermGen space。

　　我在工作可能在如下幾種場(chǎng)景下出現(xiàn)此問題。

　　使用一些應(yīng)用服務(wù)器的熱部署的時(shí)候，我們就會(huì)遇到熱部署幾次以后發(fā)現(xiàn)內(nèi)存溢出了，這種情況就是因?yàn)槊看螣岵渴鸬暮?，原來的class沒有被卸載掉。

　　如果應(yīng)用程序本身比較大，涉及的類庫(kù)比較多，但是我們分配給持久帶的內(nèi)存（通過-XX:PermSize和-XX:MaxPermSize來設(shè)置）比較小的時(shí)候也可能出現(xiàn)此種問題。

　　一些第三方框架，比如spring，hibernate都通過字節(jié)碼生成技術(shù)（比如CGLib）來實(shí)現(xiàn)一些增強(qiáng)的功能，這種情況可能需要更大的方法區(qū)來存儲(chǔ)動(dòng)態(tài)生成的Class文件。

　　我們知道Java中字符串常量是放在常量池中的，String.intern（）這個(gè)方法運(yùn)行的時(shí)候，會(huì)檢查常量池中是否存和本字符串相等的對(duì)象，如果存在直接返回對(duì)常量池中對(duì)象的引用，不存在的話，先把此字符串加入常量池，然后再返回字符串的引用。那么我們就可以通過String.intern方法來模擬一下運(yùn)行時(shí)常量區(qū)的溢出。下面我們通過如下的代碼來模擬此種情況：

　?。踛ava］ view plain copyimport java.util.*;

　　import java.lang.*;

　　public class OOMTest{

　　public static void main（String.。。 args）{

　　List《String》 list = new ArrayList《String》（）;

　　while（true）{

　　list.add（UUID.randomUUID（）.toString（）.intern（））;

　　}

　　}

　　}

　　我們通過如下的命令運(yùn)行上面代碼：

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

　　運(yùn)行后的輸入如下圖所示：

　?。踦lain］ view plain copyException in thread “main” java.lang.OutOfMemoryError： PermGen space

　　at java.lang.String.intern（Native Method）

　　at OOMTest.main（OOMTest.java:8）

　　通過上面的代碼，我們成功模擬了運(yùn)行時(shí)常量池溢出的情況，從輸出中的PermGen space可以看出確實(shí)是持久帶發(fā)生了溢出，這也驗(yàn)證了，我們前面說的Hotspot jvm通過持久帶來實(shí)現(xiàn)方法區(qū)的說法。

　　OutOfMemoryError:unable to create native thread

　　最后我們?cè)趤砜纯磈ava.lang.OutOfMemoryError:unable to create natvie thread這種錯(cuò)誤。 出現(xiàn)這種情況的時(shí)候，一般是下面兩種情況導(dǎo)致的：

　　程序創(chuàng)建的線程數(shù)超過了操作系統(tǒng)的限制。對(duì)于Linux系統(tǒng)，我們可以通過ulimit -u來查看此限制。

　　給虛擬機(jī)分配的內(nèi)存過大，導(dǎo)致創(chuàng)建線程的時(shí)候需要的native內(nèi)存太少。我們都知道操作系統(tǒng)對(duì)每個(gè)進(jìn)程的內(nèi)存是有限制的，我們啟動(dòng)Jvm，相當(dāng)于啟動(dòng)了一個(gè)進(jìn)程，假如我們一個(gè)進(jìn)程占用了4G的內(nèi)存，那么通過下面的公式計(jì)算出來的剩余內(nèi)存就是建立線程棧的時(shí)候可以用的內(nèi)存。 線程棧總可用內(nèi)存=4G-（-Xmx的值）- （-XX:MaxPermSize的值）- 程序計(jì)數(shù)器占用的內(nèi)存 通過上面的公式我們可以看出，-Xmx 和 MaxPermSize的值越大，那么留給線程?？捎玫目臻g就越小，在-Xss參數(shù)配置的棧容量不變的情況下，可以創(chuàng)建的線程數(shù)也就越小。因此如果是因?yàn)檫@種情況導(dǎo)致的unable to create native thread，那么要么我們?cè)龃筮M(jìn)程所占用的總內(nèi)存，或者減少-Xmx或者-Xss來達(dá)到創(chuàng)建更多線程的目的。

　　JVM內(nèi)存區(qū)域組成

　　簡(jiǎn)單的說java中的堆和棧

　　java把內(nèi)存分兩種：一種是棧內(nèi)存，另一種是堆內(nèi)存

　　1。在函數(shù)中定義的基本類型變量和對(duì)象的引用變量都在函數(shù)的棧內(nèi)存中分配；

　　2。堆內(nèi)存用來存放由new創(chuàng)建的對(duì)象和數(shù)組

　　在函數(shù)（代碼塊）中定義一個(gè)變量時(shí)，java就在棧中為這個(gè)變量分配內(nèi)存空間，當(dāng)超過變量的作用域后，java會(huì)自動(dòng)釋放掉為該變量所分配的內(nèi)存空間；在堆中分配的內(nèi)存由java虛擬機(jī)的自動(dòng)垃圾回收器來管理

　　堆的優(yōu)勢(shì)是可以動(dòng)態(tài)分配內(nèi)存大小，生存期也不必事先告訴編譯器，因?yàn)樗窃谶\(yùn)行時(shí)動(dòng)態(tài)分配內(nèi)存的。缺點(diǎn)就是要在運(yùn)行時(shí)動(dòng)態(tài)分配內(nèi)存，存取速度較慢；

　　棧的優(yōu)勢(shì)是存取速度比堆要快，缺點(diǎn)是存在棧中的數(shù)據(jù)大小與生存期必須是確定的無靈活性。

　　java堆分為三個(gè)區(qū)：New、Old和Permanent

　　GC有兩個(gè)線程：

　　新創(chuàng)建的對(duì)象被分配到New區(qū)，當(dāng)該區(qū)被填滿時(shí)會(huì)被GC輔助線程移到Old區(qū)，當(dāng)Old區(qū)也填滿了會(huì)觸發(fā)GC主線程遍歷堆內(nèi)存里的所有對(duì)象。Old區(qū)的大小等于Xmx減去-Xmn

　　java棧存放

　　棧調(diào)整：參數(shù)有+UseDefaultStackSize -Xss256K，表示每個(gè)線程可申請(qǐng)256k的?？臻g

　　每個(gè)線程都有他自己的Stack