第淺談JVM內(nèi)存溢出原因和解決思路因為HotSpot是不支持擴展的，所在除非在線程創(chuàng)建時申請內(nèi)存無法滿足時，才會出現(xiàn)OutOfMemoryError，其余都是產(chǎn)生StackOverflowError異常。

結論：給每個線程的棧分配內(nèi)存不是越大越好?？梢赃@么理解，比如總的內(nèi)存是2G，如果一個線程就占了1.5G，那就。。。。

解決思路

出現(xiàn)StackOverflowError異常時，會有明確錯誤堆?？晒┓治?，相對而言比較容易定位到問題所在。

如果使用Hotspot虛擬機默認參數(shù)，棧深度在大多數(shù)情況下（因為每個方法壓人棧的幀大小并不是一樣的，所以只能說大多數(shù)情況下）到達1000~2000是完全沒有問題，對于正常的方法調(diào)用（包括不能做尾遞歸優(yōu)化的遞歸調(diào)用)，這個深度應該完全夠用了。但是，如果是建立過多線程導致的內(nèi)存濫出，在不能減少線程數(shù)量或者更換64位虛擬機的情況下，就只能通過減少最大堆和減少棧容量來換取更多的線程。

堆溢出

當不斷的創(chuàng)建對象并避免垃圾回收時，總容量觸及最大堆容量時，就會產(chǎn)生溢出。

運行代碼：設置vm參數(shù)-Xms10m-Xmx10m

publicclassHeapTest{

staticclassOOMObj{

*vmarg-Xms10m-Xmx10m-XX:+HeapDumpOnOutOfMemoryError

publicstaticvoidmain(String[]args){

ListOOMObjoomObjList=newArrayListOOMObj

while(true){

oomObjList.add(newOOMObj());

}

結果：

首先通過內(nèi)存映像分析工具確認是內(nèi)存泄漏還是內(nèi)存溢出。

如果是內(nèi)存泄漏，說明導致OOM的對象不是必要的。進一步通過工具查看GCRoots引用鏈。一般可以比較精確的定位。

如果是內(nèi)存溢出，對象是必須存活的，那就檢查虛擬機的堆參數(shù)-Xms、-Xmx設置，對比機器內(nèi)存，看是否還有上調(diào)的空間。再從代碼上檢查對象生命周期、持有狀態(tài)時間、存儲結構是否有設計不合理等情況。

方法區(qū)和運行時常量池溢出

一個類要被垃圾收集器回收，條件是比較苛刻的。在經(jīng)常運行時生成大量動態(tài)類的應用場景里，就應該特別關注了。

HotSpot在JDK8中已經(jīng)完全使用元空間代替永久帶。Hotspot提供了一些參數(shù)作為元空間的防御措施，主要包括：

XX:MaxMetaspacesize：設置元空間最大值，默認是-1，即不限制，或者說只受限于本地內(nèi)存大小。

-XX:Metaspacesize：指定元空間的初始空間大小，以宇節(jié)為單位，達到該值就會觸發(fā)垃圾收集進行類型卸載，同時收集器會對該值進行調(diào)整：如果釋放了大量的空間，就適當降低該值；如果釋放了很少的空間，那么在不超過-XX:MaxMetaspaceSize（如果設置了的話）的情況下，適當提高該值。

-XX:MinMetaspaceFreeRatio：作用是在垃圾收集之后控制最小的元空間剩余容量的百分比，可減少因為元空間不足導致的垃圾收集的頻率。類似的還有-xx:Max-MetaspaceFreeRatio，用于控制最大的元空間剩余容量的百分比。

本機直接內(nèi)存溢出

在直接或間接使用了ByteBuffer中的allocateDirect方法的時候，而不做cl