JVM-03内存区域与内存溢出异常(下)【OutOfMemoryError案例】
文章目錄
- 思維導圖
- Java堆溢出
- 前置操作
- 測試類
- 結果
- 使用mat分析
- 內存泄露Memory Leak
- 內存溢出Memory Overflow
- 虛擬機棧和本地方法棧溢出
- 概述
- StackOverflowError
- OutofMemoryError
- 方法區和運行時常量池溢出
- 測試
- 本機直接內存溢出
思維導圖
接下來,我們來通過示例來演示下出現異常的場景。
Java堆溢出
前置操作
JVM參數官網 :http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
為了更加方便的制造出內存溢出的錯誤,我們需要通過JVM提供的參數來設置虛擬機啟動參數,因為我們是使用的IDE,設置如下
-Xms10m -Xmx10m -XX:+HeapDumpOnOutOfMemoryError- -Xms 初始堆大小。-Xmx 最大堆大小。 設置成一樣即是不可擴展的意思
- -XX:+HeapDumpOnOutOfMemoryError 讓虛擬機在發生內存溢出時 Dump 出當前的內存堆轉儲快照,以便分析用
如果Java Application 下沒有對應的類,選中要測試的類,右鍵Run Configuratons ,然后在Java Application處,右鍵New即可。
測試類
package com.artisan.memory;import java.util.ArrayList; import java.util.List;public class HeapOOM {static class OOMObject {}// 如果堆中沒有內存完成實例分配,并且對也無法再擴展時,將會拋出OutOfMemoryError異常。public static void main(String[] args) {List<OOMObject> list = new ArrayList<OOMObject>();while (true) {list.add(new OOMObject());}} }結果
運行日志輸出如下:
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space Dumping heap to java_pid16572.hprof ... Heap dump file created [13008837 bytes in 0.079 secs] Exception in thread "main" java.lang.OutOfMemoryError: Java heap spaceat java.util.Arrays.copyOf(Arrays.java:2245)at java.util.Arrays.copyOf(Arrays.java:2219)at java.util.ArrayList.grow(ArrayList.java:242)at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:216)at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:208)at java.util.ArrayList.add(ArrayList.java:440)at com.artisan.memory.HeapOOM.main(HeapOOM.java:16)當java應用程序出現堆內存溢出的時候,異常堆棧信息為java.lang.OutOfMemoryError 后面會跟著 Java heap space
使用mat分析
要解決這個區域的異常,一般的手段是先通過內存映射分析工具比如Eclipse Memory Analyzer 對dump出來的堆轉儲快照進行分析,重點是確認內存中的對象是否是必要的,就是要分先分清到底是出現了內存泄露(Memory Leak) 還是 內存溢出(Memory Overflow).
我們使用mat來分析下剛才產生的dump文件
Shallow Size :對象自身占用的內存大小,不包括它引用的對象。
針對非數組類型的對象,它的大小就是對象與它所有的成員變量大小的總和。當然這里面還會包括一些java語言特性的數據存儲單元。
針對數組類型的對象,它的大小是數組元素對象的大小總和。
Retained Size=當前對象大小+當前對象可直接或間接引用到的對象的大小總和。(間接引用的含義:A->B->C, C就是間接引用)
換句話說,Retained Size就是當前對象被GC后,從Heap上總共能釋放掉的內存。
不過,釋放的時候還要排除被GC Roots直接或間接引用的對象。他們暫時不會被被當做Garbage
內存泄露Memory Leak
如果是內存泄露,可進一步通過工具排查看看泄露對象到GC Roots的引用鏈。于是就能找到泄露對象是通過怎樣的路徑與GC Roots相關聯并導致垃圾收集器無法自動回收他們的,從而比較準確的定位到泄漏代碼的位置
內存溢出Memory Overflow
如果不存在泄露,換句話說就是內存中的對象確實都還必須存活著,那就應該檢查虛擬機的堆參數(-Xms 和 -Xms),與物理機器內存對比存看下是否可以調大,從代碼是否存在某些生命周期過長,持有狀態時間工廠的情況,嘗試減少程序運行期的內存消耗。
虛擬機棧和本地方法棧溢出
概述
由于在Hotspot虛擬機中并不區分虛擬機棧和本地方法棧,因此對于Hotspot來說,雖然-Xoss參數(設置本地方法棧大小)存在,但是無效的。 棧容量只由-Xss參數設定。
關于虛擬機棧和本地方法棧,在Java虛擬機規范中描述了兩種異常
- 如果線程請求的棧深度大于虛擬機所允許的最大深度,將拋出StackOverflowError異常
- 如果虛擬機在擴展棧時無法申請到最夠的內存空間,則拋出OutOfMemoryError異常
雖然把異常分成兩種情況,看起來很嚴謹,其實卻存在一些重疊的地方: 當棧空間無法繼續分配時,是內存太小 還是已經使用的棧空間過大,本質上只是對同一件事情的兩種描述而已。
StackOverflowError
單線程, 通過調整-Xss參數減少棧內存容量 ----> StackOverflowError
單線程,定義了大量的本地變量,增大此方法幀中本地變量表的長度----> StackOverflowError
輸出日志:
Stack length:987Exception in thread "main" java.lang.StackOverflowErrorat com.artisan.memory.JVMStatckSOF.statckLeak(JVMStatckSOF.java:25)at com.artisan.memory.JVMStatckSOF.statckLeak(JVMStatckSOF.java:26)at com.artisan.memory.JVMStatckSOF.statckLeak(JVMStatckSOF.java:26)at com.artisan.memory.JVMStatckSOF.statckLeak(JVMStatckSOF.java:26)at com.artisan.memory.JVMStatckSOF.statckLeak(JVMStatckSOF.java:26)試驗結果表明,在單線程先,無論是由于幀棧太大還是由于虛擬機棧容量太小,當內存無法分配的時候,虛擬機拋出的都是StackOverflowError異常。
OutofMemoryError
如果不限制單線程,通過不斷的建立線程的方式倒是可以產生內存溢出
的場景(謹慎使用,如果是windows會使電腦卡死)
如上述代碼產生的內存溢出異常和棧空間是否足夠大不存在任何聯系,或者準確的說,在這種情況下,為每個線程的棧分配的內存越大,反而越容易產生內存溢出。
操作系統分配給每個進程的內存是有限制的,虛擬機提供了參數來控制Java堆和方法區的這兩部分內存的最大值。 剩余內存為操作系統總內存-Xmx(最大堆容量)-MaxPermSize(最大方法區容量)-程序計數器消耗的內存(很小可忽略不計)如果虛擬機進程本身消耗的內存不計算在內,剩下的內存就由虛擬機棧和本地方法棧瓜分了。 每個線程分配到的棧容量越大(-Xss設置),可以建立的線程數自然越少,建立線程的時候就越容易把剩下的內存耗盡。
異常信息
Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread方法區和運行時常量池溢出
由于運行時常量池是方法區(永久代)的一部分,因此將這兩個區域的移除測試放到一起。
我們知道JDK1.7開始逐步“去永久代”,所以我們這個案例是在JDK1.6中的版本測試的。
String.intern()是一個Native方法,它的作用是:如果字符串常量池中包含一個等于此String對象的字符串,則返回代表池中這個字符串的String對象,否則將此String對象包含的字符串添加到常量池中,并且返回此String對象的引用。
測試
package com.artisan.memory;import java.util.ArrayList; import java.util.List;/*** * * @ClassName: RuntimeConstantPoolOOM* * @Description: JDK1.6中運行* * VM Args -XX:PermSize=10M -XX:MaxPermSize=10M* * @author: Mr.Yang* * @date: 2018年7月27日 下午9:57:43*/ public class RuntimeConstantPoolOOM {public static void main(String[] args) {// 使用List保持常量池引用,避免Full GC回收常量池行為List<String> list = new ArrayList<String>();// 10M的PermSize在integer范圍內最夠產生OOM了int i = 1 ;while (true) {list.add(String.valueOf(i++).intern());}} }輸出
Exception in thread "main" java.lang.OutOfMemoryError: PermGen spaceat java.lang.String.intern(Native Method)at com.artisan.memory.RuntimeConstantPoolOOM.main(RuntimeConstantPoolOOM.java:27)如果在JDK1.7中會得到不同的結果,該程序會一直運行下去。
本機直接內存溢出
DirectMemory容量可通過 -XX:MaxDirectorySize指定,如果不指定,這默認和Java堆最大內存(-Xmx指定)一樣。
由于DirectMemory導致的內存溢出,一個明顯的特征是在Heap Dump文件中不會看見明顯的異常,如果發現OOM之后Dump很小,而程序中又直接或者間接的使用了NIO,那就可以考慮下是不是這個方面的原因。
總結
以上是生活随笔為你收集整理的JVM-03内存区域与内存溢出异常(下)【OutOfMemoryError案例】的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: JVM-02内存区域与内存溢出异常(中)
- 下一篇: JVM-04垃圾收集Garbage Co