如果你做TCP通訊或者map集合操作，並發處理等功能時，很容易出現 Java 內存溢出的問題。本篇文章，帶領大家深入jvm，分析並找出jvm內存溢出的代碼。
jvm中除了程序計數器，其他的區域都有可能會發生內存溢出
內存溢出是什么
當程序需要申請內存的時候，由於沒有足夠的內存，此時就會拋出OutOfMemoryError，這就是內存溢出
內存溢出和內存泄漏有什么區別
內存泄漏是由於使用不當，把一部分內存“丟掉了”，導致這部分內存不可用。
當在堆中創建了對象，后來沒有使用這個對象了，又沒有把整個對象的相關引用設為null。此時垃圾收集器會認為這個對象是需要的，就不會清理這部分內存。這就會導致這部分內存不可用。
所以內存泄漏會導致可用的內存減少，進而會導致內存溢出。
用到的jvm參數
下面為了說明溢出的情景，會執行一些實例代碼，同時需要給jvm指定參數
-Xms 堆最小容量(heap min size)
-Xmx 堆最大容量(heap max size)
-Xss 棧容量(stack size)
-XX:PermSize=size 永生代最小容量
-XX:MaxPermSize=size 永生代最大容量
堆溢出
堆是存放對象的地方，那么只要在堆中瘋狂的創建對象，那么堆就會發生內存溢出。
下面做一個堆溢出的實驗
執行這段代碼的時候，要給jvm指定參數
1
2
3
4
5
6
7
8
9
//jvm參數：-Xms20m -Xmx20m
public class HeapOOMTest {
public static void main(String[] args){
LinkedList xttblog=new LinkedList();//作為GC Root
while(true){
xttblog.add(new HeapOOMTest());//瘋狂創建對象
}
}
}
-Xms20m -Xmx20m作用是將jvm的最小堆容量和最大堆容量都設定為20m，這樣就不會動態擴展jvm堆了
這段代碼瘋狂的創建對象，雖然對象沒有聲明變量名引用，但是將對象添加到隊列l中，這樣隊列l就持有了一份對象的引用
通過可達性算法(jvm判斷對象是否可被收集的算法)分析，隊列l作為GC Root，每一個對象都是l的一個可達的節點，所以瘋狂創建的對象不會被收集，這就是內存泄漏，這樣總有一天堆就溢出了。
運行結果：
Exception in thread “main” java.lang.OutOfMemoryError: Java heap space at java.util.LinkedList.linkLast(Unknown Source) at java.util.LinkedList.add(Unknown Source) at test.HeapOOMTest.main(HeapOOMTest.java:23)
程序發生內存溢出，並提示發生在Java heap space
分析解決方法
思路
用visualVM工具分析堆快照
如果發生內存泄漏：
step1:找出泄漏的對象
step2:找到泄漏對象的GC Root
step3:根據泄漏對象和GC Root找到導致內存泄漏的代碼
step4:想法設法解除泄漏對象與GCRoot的連接
如果不存在泄漏:
看下是否能增大jvm堆的最大容量
優化程序，減小對象的生命周期
前期准備
當發生堆溢出的時候，可以讓程序在崩潰時產生一份堆內存快照
產生堆內存快照的方法：
給jvm加上參數XX:+HeapDumpOnOutofMemoryError，這樣就會在程序崩潰的時候，產生一份堆內存快照
分析堆內存快照我建議用jdk自帶的可視化監視工具visualVM，位置在jdk安裝目錄下的bin，如果是在Linux環境的話，可以把快照傳到window。因為分析工具會占用很大的內存，不建議在服務端進行分析。
實戰
下面對剛才程序產生的堆內存快照進行分析。
打開visualVM，裝入剛剛生成的快照，打開類標簽頁
visualVM
隊列和瘋狂創建的對象幾乎占滿了整個棧，想要讓垃圾收集器回收這些對象，要讓他們與GC Root斷開連接
雙擊HeapOOMTest類，跳轉到實例標簽頁，可以查看這個類的所有實例
在實例上右鍵——顯示最近的垃圾回收根節點，可以看到這個對象與根節點的連接
StackOverFlowError
只要斷開HeapOOMTest對象與LinkedList的連接，這些瘋狂創建的對象就會被收集了
棧溢出
調用方法的時候，會在棧中入棧一個棧幀，如果當前棧的容量不足，就會發生棧溢出StackOverFlowError
那么只要瘋狂的調用方法，並且有意的不讓棧幀出棧就可以導致棧溢出了。
下面來一次棧溢出
1
2
3
4
5
6
7
8
9
10
//jvm參數:-Xss128k
public class StackSOFTest {
public void stackLeak(){
stackLeak();//遞歸，瘋狂的入棧，有意不讓出棧
}
public static void main(String[] args){
StackSOFTest s=new StackSOFTest();
s.stackLeak();
}
}
jvm設置參數-Xss128k，目的是縮小棧的空間，這樣棧溢出“來的快一點”
程序中用了遞歸，讓棧幀瘋狂的入棧，又不讓棧幀出棧，這樣就會棧溢出了。
運行結果：
Exception in thread “main” java.lang.StackOverflowError at test.StackSOFTest.stackLeak(StackSOFTest.java:17) at test.StackSOFTest.stackLeak(StackSOFTest.java:17)
運行時常量池溢出
這里儲存的是一些常量、字面量。如果運行時常量池內存不足，就會發生內存溢出。從jdk1.7開始，運行時常量池移動到了堆中，所以如果堆的內存不足，也會導致運行時常量池內存溢出。
下面來一次運行時常量池溢出，環境是jdk8
只要創建足夠多的常量，就會發生溢出
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
/**
* jvm參數：
* jdk6以前：-XX:PermSize=10M -XX:MaxPermSize=10M
* jdk7開始：-Xms10m -Xmx10m
* */
public class RuntimePoolOOM {
public static void main(String[] args){
int i=1;
//保持常量的引用，防止被fullgc收集
LinkedList xttblog=new LinkedList();
while(true){
//將常量添加到常量池
xttblog.add(String.valueOf(i++).intern());
}
}
}
因為jdk6以前，運行時常量池是在方法區（永生代）中的，所以要限制永生代的容量，讓內存溢出來的更快。
從jdk7開始，運行時常量池是在堆中的，那么固定堆的容量就好了
這里用了鏈表去保存常量的引用，是因為防止被fullgc清理，因為fullgc會清理掉方法區和老年代
intern()方法是將常量添加到常量池中去，這樣運行時常量池一直都在增長，然后內存溢出
運行結果：
Exception in thread “main” java.lang.OutOfMemoryError: Java heap space
at java.lang.Integer.toString(Unknown Source)
at java.lang.String.valueOf(Unknown Source)
at test.RuntimePoolOOM.main(RuntimePoolOOM.java:30)
提示在heap區域發生內存溢出，果然運行時常量池被移到了堆中
方法區溢出
方法區是存放類的信息，而且很難被gc，只要加載了大量類，就有可能引起方法區溢出
這里將不做演示了，想試試的可以用cglib創建大量的代理類
分析
工作中也有可能會遇上方法區溢出：
當多個項目都有相同jar包的時候，又都存放在WEB-INF\lib\下，這樣每個項目都會加載一遍jar包。會導致方法區中有大量相同類（被不同的類加載器所加載），又不會被gc掉。
解決方案
在應用服務器中建立一個共享lib庫，把項目中常用重復的jar包存放在這里，項目從這里加載jar包，這樣就會大大減少類加載的數量，方法區也“瘦身”了
如果實在不能瘦身類的話，那可以擴大方法區的容量，給jvm指定參數-XX:MaxPermSize=xxxM