1.Java堆溢出：
? ? 思路：Java堆用于存儲(chǔ)對象實(shí)例，只要不斷地創(chuàng)造對象，并且保證GC Root到對象之間有可達(dá)路徑來避免垃圾回收機(jī)制清除這些對象，那么在對象數(shù)量達(dá)到最大堆的容量限制后就會(huì)產(chǎn)生內(nèi)存溢出異常。
? ? 操作：將虛擬機(jī)參數(shù)－Xms參數(shù)與－Xmx參數(shù)設(shè)置為一樣即可避免堆自動(dòng)擴(kuò)展（－Xms參數(shù)堆最小值，－Xmx參數(shù)堆最大值），通過參數(shù)－XX:HeapDumpOnOutOfMemoryError可以讓虛擬機(jī)在出現(xiàn)內(nèi)存溢出異常時(shí)Dump出當(dāng)前的內(nèi)存堆轉(zhuǎn)儲(chǔ)快照以便事后進(jìn)行分析。
? ? 運(yùn)行異常結(jié)果? ?java.lang.OutOfMemoryError: Java heap space
? ? Java堆內(nèi)存的OOM異常是實(shí)際應(yīng)用中常見的內(nèi)存溢出異常情況。當(dāng)出現(xiàn)Java堆內(nèi)存溢出時(shí)，異常堆棧信息“java.lang.OutOfMemoryError”會(huì)跟著進(jìn)一步提示“Java heap space”。
處理思路：要解決這個(gè)區(qū)域的異常，一般手段是通過內(nèi)存映像分析工具對Dump出來的堆轉(zhuǎn)儲(chǔ)快照進(jìn)行分析，重點(diǎn)是確認(rèn)內(nèi)存中的對象是否是必要的，也就是要先分清除到底是內(nèi)存泄漏還是內(nèi)存溢出。
1>如果是內(nèi)存泄漏（內(nèi)存中的對象不是必須存活），可以進(jìn)一步通過工具查看泄漏對象到GC Root的引用鏈。于是就能找到泄漏對象是通過怎樣的路徑與GC Root相關(guān)聯(lián)并導(dǎo)致垃圾收集器無法自動(dòng)回收它們的。掌握了泄漏對象信息及GC ROOT引用鏈的信息，就可以比較準(zhǔn)確地定位出泄露代碼的位置。
2>如果不存在內(nèi)存泄漏，即內(nèi)存中的對象確實(shí)都還必須存活著，那就應(yīng)當(dāng)檢查虛擬機(jī)的堆參數(shù)（－Xmx和－Xms）,與機(jī)器物理內(nèi)存對比看是否還可以調(diào)大，從代碼上檢查是否存在某些對象生命周期過長、持有狀態(tài)時(shí)間過長的情況，嘗試減少程序運(yùn)行期的內(nèi)存消耗。
2.虛擬機(jī)棧和本地方法棧溢出：
? ?1.由于HotSpot虛擬機(jī)中并不區(qū)分虛擬機(jī)棧和本地方法棧，因此，對于HotSpot來說，－Xoss參數(shù)（設(shè)置本地方法棧大小）存在，但實(shí)際上是無效的，棧容量只由－Xss參數(shù)設(shè)定。關(guān)于虛擬機(jī)和本地方法棧，在Java虛擬機(jī)規(guī)范中描述了兩種異常：
? ? ? ?1>如果線程請求的棧深度大于虛擬機(jī)所允許的最大深度，將拋出StackOverflowError異常。
? ? ? ?2>如果虛擬機(jī)在擴(kuò)展時(shí)無法申請到足夠的內(nèi)存空間，則拋出OutOfMemoryError異常。
上述兩種情況其實(shí)本質(zhì)上是對同一件事情的兩種描述。
2.實(shí)驗(yàn)：單線程下的兩種方式均無法產(chǎn)生OutOfMemoryError異常，嘗試的結(jié)果都是獲得StackOverflowError異常
? ? ?1>使用－Xss參數(shù)減少棧內(nèi)容量。結(jié)果：拋出StackOverflowError異常，異常出現(xiàn)時(shí)輸出的堆棧深度相應(yīng)縮小。
? ? ?2>定義了大量的本地變量，增大此方法楨中本地變量表的長度。結(jié)果：拋出StackOverflowError異常時(shí)輸出的堆棧深度相應(yīng)縮小。
3.處理：出現(xiàn)StackOverflowError異常時(shí)有錯(cuò)誤堆棧可以閱讀，相對來說，比較容易找到問題的所在。而且，如果使用虛擬機(jī)默認(rèn)參數(shù)，棧深度在大多數(shù)情況下（因?yàn)槊總€(gè)方法壓入棧的楨大小并不是一樣的，所以只能說在大多數(shù)情況下）達(dá)到1000～2000完全沒有問題，對于正常的方法調(diào)用（包括遞歸），這個(gè)深度應(yīng)該完全夠用了。
多線程下：通過不斷地建立線程的方式可以產(chǎn)生內(nèi)存溢出異常，但這樣產(chǎn)生的內(nèi)存溢出異常與棧空間是否足夠大并不存在任何聯(lián)系，或者說，為每個(gè)線程的棧分配的內(nèi)存越大，反而越容易產(chǎn)生內(nèi)存溢出異常。
原因：操作系統(tǒng)分配給每個(gè)進(jìn)程的內(nèi)存是有限的，譬如32位的Windows限制為2GB。虛擬機(jī)提供了參數(shù)來控制Java堆和方法區(qū)的這兩部分內(nèi)存的最大值剩余的內(nèi)存為2GB（操作系統(tǒng)限制）減去Xmx（最大堆容量），再減去MaxPermSize(最大方法區(qū)容量)，程序計(jì)數(shù)器消耗內(nèi)存很小，可以忽略掉。如果虛擬機(jī)進(jìn)程本身耗費(fèi)的內(nèi)存不計(jì)算在內(nèi)，剩下的內(nèi)存就由虛擬機(jī)棧和本地方法棧“瓜分”了。每個(gè)線程分配到的棧容量越大，可以建立的線程數(shù)就變少了，建立線程時(shí)就越容易把剩下的內(nèi)存耗盡。
處理：如果是建立多線程導(dǎo)致內(nèi)存溢出，在不能減少線程或者更換64位虛擬機(jī)的情況下，就只能通過減少最大堆和減少棧容量來換取更多線程。
3.方法區(qū)和運(yùn)行時(shí)常量池溢出：
（注：String.intern()是一個(gè)Native方法，它的作用是：如果字符串常量池中已經(jīng)包含一個(gè)等于此String對象的字符串，則返回代表池中這個(gè)字符串的String對象的引用。）
具體操作：通過－XX:PermSize和－XX:MaxPermSize限制方法區(qū)大小，從而間接限制其中常量池的容量。提示信息是“PermGen space”說明運(yùn)行時(shí)常量屬于方法區(qū)（HotSpot虛擬機(jī)中的永久代）的一部分。
思路：方法區(qū)用于存放Class的相關(guān)信息，如類名、訪問修飾符、常量池、字段描述、方法描述等。對于這些區(qū)域的測試，基本的思路是運(yùn)行時(shí)產(chǎn)生大量的類去填滿方法區(qū)，直到溢出。
注意：在這個(gè)例子中模擬的場景并非純粹是一個(gè)實(shí)驗(yàn)，這樣的應(yīng)用經(jīng)常會(huì)出現(xiàn)在實(shí)際應(yīng)用中：當(dāng)前的很多主流框架，如Spring、Hibernate,在對類進(jìn)行增強(qiáng)時(shí)都會(huì)使用到CGLib這類字節(jié)碼技術(shù)，增強(qiáng)的類越多，就需要越大的方法區(qū)來保證動(dòng)態(tài)生成的Class可以加載入內(nèi)存。
? ? ? 方法區(qū)溢出也是一種常見的內(nèi)存溢出異常，一個(gè)類要被垃圾收集器回首掉，判定條件是比較苛刻的。在經(jīng)常動(dòng)態(tài)生成大量Class的應(yīng)用中，需要特別注意類的回收狀況。這類場景除了上面提到的程序使用了CGLib字節(jié)碼增強(qiáng)和動(dòng)態(tài)語言之外，常見的還有：大量JSP或動(dòng)態(tài)產(chǎn)生JSP文件的應(yīng)用（JSP第一次運(yùn)行時(shí)需要編譯為Java類）、基于OSGi的應(yīng)用（即使是同一個(gè)類文件，被不同的加載器加載也會(huì)視為不同的類）
4.本機(jī)直接內(nèi)存溢出：
DirectMemory容量可通過－XX:MaxDirectMemorySize指定，如果不指定，則默認(rèn)與Java堆最大值（－Xmx指定）一樣，直接通過反射獲取Unsafe實(shí)例進(jìn)行內(nèi)存分配（使用DirectByteBuffer分配內(nèi)存也會(huì)拋出內(nèi)存溢出異常，但它并沒有真正向操作系統(tǒng)申請分配內(nèi)存，而是通過計(jì)算得知內(nèi)存無法分配，于是手動(dòng)拋出異常）真正申請分配內(nèi)存的方法是unsafe.allocateMemory()。
由DirectMemory導(dǎo)致內(nèi)存溢出，一個(gè)明顯的特征是在Heap Dump文件中不會(huì)看見明顯的異常，如果讀者發(fā)現(xiàn)OOM之后Dump文件很小，而程序中又直接或間接使用了NIO,那就可以考慮檢查一下是不是這方面的原因。
