1.前言
上一篇我們介紹了java的內存區域結構,這一篇,模擬內存溢出的幾個場景,下面一個圖是總體的指導思想:
2.Java堆溢出
Java堆唯一的作用就是存儲對象實例,只要保證不斷創建對象並且對象不被回收,那麼對象數量達到最大堆容量限制後就會產生內存溢出異常了。所以測試的時候把堆的大小固定住並且讓堆不可擴展即可。測試代碼如下:
1 package com.xrq.test; 2 3 import java.util.ArrayList; 4 import java.util.List; 5 6 /** 7 * 測試內容:堆溢出 8 * 9 * 虛擬機參數:-Xms20M -Xmx20M -XX:+HeapDumpOnOutOfMemoryError 10 */ 11 public class HeapOverflowTest 12 { 13 public static void main(String[] args) 14 { 15 List<HeapOverflowTest> list = new ArrayList<HeapOverflowTest>(); 16 while (true) 17 { 18 list.add(new HeapOverflowTest()); 19 } 20 } 21 }
運行結果
java.lang.OutOfMemoryError: Java heap space Dumping heap to java_pid8876.hprof ... Heap dump file created [15782068 bytes in 0.217 secs] Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2760) at java.util.Arrays.copyOf(Arrays.java:2734) at java.util.ArrayList.ensureCapacity(ArrayList.java:167) at java.util.ArrayList.add(ArrayList.java:351) at com.xrq.test.HeapOverflowTest.main(HeapOverflowTest.java:18)
這種異常很常見,也很好發現,因爲都提示了“Java heap space”了,定位問題的話,根據異常堆棧分析就好了,行號都有指示。
解決方案:可以調大堆的大小或者從代碼上檢視是否存在某些對象生命週期過長、持有狀態時間過長的情況,長時間減少程序運行期間的內存消耗。
另外,由於Java堆內也可能發生內存泄露(Memory Leak),這裏簡要說明一下內存泄露和內存溢出的區別:
內存泄露:是指分配出去的內存沒有被回收回來,由於失去了對該內存區域的控制,因而造成了資源的浪費。Java中一般不會產生內存泄露,因爲有垃圾回收器自動回收垃圾,但這也不絕對,當我們new了對象,並保存了其引用,但是後面一直沒用它,而垃圾回收器又不會去回收它,這邊會造成內存泄露,
內存溢出:是指程序所需要的內存超出了系統所能分配的內存(包括動態擴展)的上限。
3.方法區和運行時常量池溢出
運行時常量池也是方法區的一部分,所以這兩個區域一起看就可以了。這個區域的OutOfMemoryError可以利用String.intern()方法來產生。這是一個Native方法,意思是如果常量池中有一個String對象的字符串就返回池中的這個字符串的String對象;否則,將此String對象包含的字符串添加到常量池中去,並且返回此String對象的引用。測試代碼如下:
1 package com.xrq.test; 2 3 import java.util.ArrayList; 4 import java.util.List; 5 6 /** 7 * 測試內容:常量池溢出(這個例子也可以說明運行時常量池爲方法區的一部分) 8 * 9 * 虛擬機參數-XX:PermSize=10M -XX:MaxPermSize=10M 10 */ 11 public class ConstantPoolOverflowTest 12 { 13 public static void main(String[] args) 14 { 15 List<String> list = new ArrayList<String>(); 16 int i = 0; 17 while (true) 18 { 19 list.add(String.valueOf(i++).intern()); 20 } 21 } 22 }
運行結果
Exception in thread "Reference Handler" Exception in thread "main" java.lang.OutOfMemoryError: PermGen space at java.lang.String.intern(Native Method) at com.xrq.test.ConstantPoolOverflowTest.main(ConstantPoolOverflowTest.java:19) java.lang.OutOfMemoryError: PermGen space at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:123)
之前有講過,對於HotSpot而言,方法區=永久代,這裏看到OutOfMemoryError的區域是“PermGen space”,即永久代,那其實也就是方法區溢出了。注意一下JDK1.7下是不會有這個異常的,while循環將一直下去,因爲JDK1.7之後溢出了永久代並採用Native Memory來實現方法區的規劃了。
4.棧溢出
Java虛擬機規範中描述瞭如果線程請求的棧深度太深(換句話說方法調用的深度太深),就會產生棧溢出了。那麼,我們只要寫一個無限調用自己的方法,自然就會出現方法調用的深度太深的場景了。測試代碼如下
1 package com.xrq.test; 2 3 /** 4 * 測試內容:棧溢出測試(遞歸調用導致棧深度不斷增加) 5 * 6 * 虛擬機參數:-Xss128k 7 */ 8 public class StackOverflowTest 9 { 10 private int stackLength = 1; 11 12 public void stackLeak() 13 { 14 stackLength++; 15 stackLeak(); 16 } 17 18 public static void main(String[] args) throws Throwable 19 { 20 StackOverflowTest stackOverflow = new StackOverflowTest(); 21 try 22 { 23 stackOverflow.stackLeak(); 24 } 25 catch (Throwable e) 26 { 27 System.out.println("stack length:" + stackOverflow.stackLength); 28 throw e; 29 } 30 } 31 }
運行結果:
stack length:1006 Exception in thread "main" java.lang.StackOverflowError at com.xrq.test.StackOverflowTest.stackLeak(StackOverflowTest.java:14) at com.xrq.test.StackOverflowTest.stackLeak(StackOverflowTest.java:15) at com.xrq.test.StackOverflowTest.stackLeak(StackOverflowTest.java:15) at com.xrq.test.StackOverflowTest.stackLeak(StackOverflowTest.java:15) at com.xrq.test.StackOverflowTest.stackLeak(StackOverflowTest.java:15) at com.xrq.test.StackOverflowTest.stackLeak(StackOverflowTest.java:15) ...
多線程:這裏需要注意一下多線程的情況,多線程下通過不斷創建線程的方式,可以產生OutOfMemoryError異常,因爲每個線程都有自己的棧空間,棧空間越大,越容易產生內存溢出異常。其實這也很好理解,操作系統分配給進程的內存是有限制的,比如32位的Windows限制爲2GB。虛擬機提供了了參數來控制Java堆和方法區這兩部分內存的最大值,剩餘內存爲2GB-最大堆容量-最大方法區容量,程序計數器很小就忽略了,虛擬機進程本身的耗費也不算,剩下的內存就是棧的了。每個線程分配到的棧容量越大,可建立的線程數自然就越少,建立線程時就越容易把剩下的內存耗盡,可能造成操作系統的假死。
多線程導致的OutOfMemoryError,在不能減少線程數的情況下,就只能通過減少最大堆和每個線程的棧容量來換取更多的線程了。
單線程:StackOverFlowError這個異常,有錯誤堆棧可以閱讀,比較好定位。而且如果使用虛擬機默認參數,棧深度在大多數情況下,達到1000~2000完全沒有問題,正常方法的調用這個深度應該是完全夠了。
轉載地址:http://www.cnblogs.com/xrq730/p/4833713.html
http://blog.csdn.net/ns_code/article/details/17565503