JVM-各記憶體區域丟擲OutOfMemoryError異常分析
阿新 • • 發佈：2020-12-29
OutOfMemoryError異常
- 注：本人測試基於jdk1.8測試，有部分不同但是原理可以瞭解，感興趣可以下載jdk1.7配套測試
- Java虛擬機器規範中描述，除了程式計數器，虛擬機器的其他幾個執行時區域都有發生OOM異常的可能。 下面的示例程式碼都基於HotSpot虛擬機器執行，設定VM引數可以在IDE的VM options內設定,如圖
Java堆溢位
引發思路：Java堆用於儲存物件例項，只要不斷地建立物件，並且保證GC Roots到物件之間有可達路徑來避免垃圾回收機制清除這些物件，那麼在物件數量到達最大堆的容量限制後就會產生記憶體溢位異常。
- 以下程式碼需要配置VM，設定java堆大小20MB,不可擴充套件（將堆的最小值-Xms引數與最大值-Xmx引數設定為一樣即可避免堆自動擴充套件），-XX：+HeapDumpOnOutOfMemoryError可以讓虛擬機器在出現記憶體溢位異常時Dump出當前的記憶體堆轉儲快照以便事後進行分析 -Xmx：最大堆大小
-Xmx20M -Xms20M -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=E:\jvmlog\oom.hprof
可以指定hprof檔案存放位置，之後使用jdk自帶工具jvisualvm.exe開啟分析即可
import java.util.ArrayList;
import java.util.List;
public class HeapOOM {
static class OOMObject {
}
public static void main(
String[] args) {
List<OOMObject> list = new ArrayList<OOMObject>();
while (true) {
list.add(new OOMObject());
}
}
}
執行結果：
java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid12092.hprof ...
Heap dump file created [28256955 bytes in 0.096 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3210)
at java.util.Arrays.copyOf(Arrays.java:3181)
at java.util.ArrayList.grow(ArrayList.java:267)
at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:241)
at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:233)
at java.util.ArrayList.add(ArrayList.java:464)
at com.llh.jdk.map.HeapOOM.main(HeapOOM.java:14)
Java堆記憶體的OOM異常是實際應用中常見的記憶體溢位異常情況。當出現Java堆記憶體溢位時，異常堆疊資訊“java.lang.OutOfMemoryError”會跟著進一步提示“Java heap space”。
- 如果是記憶體洩露，可進一步通過工具檢視洩露物件到GC Roots的引用鏈。於是就能找到洩露物件是通過怎樣的路徑與GC Roots相關聯並導致垃圾收集器無法自動回收它們的。掌握了洩露物件的型別資訊及GC Roots引用鏈的資訊，就可以比較準確地定位出洩露程式碼的位置。
- 如果不存在洩露，換句話說，就是記憶體中的物件確實都還必須存活著，那就應當檢查虛擬機器的堆引數（-Xmx與-Xms），與機器實體記憶體對比看是否還可以調大，從程式碼上檢查是否存在某些物件生命週期過長、持有狀態時間過長的情況，嘗試減少程式執行期的記憶體消耗。
虛擬機器棧和本地方法棧溢位
- 在java虛擬機器棧中描述了兩種異常：
- 如果執行緒請求的棧深度大於虛擬機器所允許的最大深度，將丟擲StackOverflowError異常
- 如果虛擬機器在擴充套件棧時無法申請到足夠的記憶體空間，則丟擲OutOfMemoryError異常
- 定義大量的本地變數，增大此方法棧中本地變量表的長度，設定-Xss引數減少棧記憶體容量
-Xss20M -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=E:\jvmlog\sof.hprofpublic class JavaVMStackSOF { private int stackLength = 1; public void stackLeak() { stackLength++; stackLeak(); } public static void main(String[] args) throws Throwable { JavaVMStackSOF oom = new JavaVMStackSOF(); try { oom.stackLeak(); } catch (Throwable e) { System.out.println("stack length：" + oom.stackLength); throw e; } } }stack length：1271382 Exception in thread "main" java.lang.StackOverflowError at com.llh.jdk.map.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:8) at com.llh.jdk.map.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:8) at com.llh.jdk.map.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:8) at com.llh.jdk.map.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:8) at com.llh.jdk.map.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:8) at com.llh.jdk.map.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:8) at com.llh.jdk.map.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:8) at com.llh.jdk.map.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:8) ···
3.如果不限於單執行緒，通過不斷建立執行緒的方式可以產生記憶體溢位異常，這樣產生的記憶體溢位異常與棧空間是否足夠大並不存在任何聯絡，在這種情況下，為每個執行緒的棧分配的記憶體越大，反而越容易產生記憶體溢位異常。
- 原因：作業系統分配給每個程序的記憶體是有限制的，虛擬機器提供引數來控制Java堆和方法區的這兩部分記憶體的最大值。剩餘的記憶體為作業系統限制減去Xmx(最大堆容量)，再減去MaxPermSize(最大方法區容量)。如果虛擬機器程序本身耗費的記憶體不計算在內，剩下的記憶體由虛擬機器棧和本地方法棧瓜分。每個執行緒分配到的棧容量越大，可以建立的執行緒數量越少，建立執行緒時越容易把剩下的記憶體耗盡
- 解決：如果是建立多執行緒導致記憶體溢位，在不能減少執行緒數或者更換虛擬機器的情況下，通過減少堆的最大堆和減少棧容量來換取更多的執行緒。
建立執行緒導致記憶體溢位
-Xss20M
public class JavaVMStackOOM {
private void dontStop(){
while(true){
}
}
public void stackLeakByThread(){
while(true){
Thread thread=new Thread(this::dontStop);
thread.start();
}
}
public static void main(String[]args)throws Throwable{
JavaVMStackOOM oom=new JavaVMStackOOM();
oom.stackLeakByThread();
}
}
執行結果
Exception in thread"main"java.lang.OutOfMemoryError：unable to create new native thread
注意：在windows上，Java執行緒是對映到作業系統的核心執行緒上的，執行此程式碼會導致作業系統假死。
方法區和執行時常量池記憶體溢位
-
String.intern（）是一個Native方法
- 作用：如果字串常量池中已經包含一個等於此String物件的字串，則返回代表池中這個字串的String物件； 否則，將此String物件包含的字串新增到常量池中，並且返回此String物件的引用。
-
執行時常量池導致的記憶體溢位(因為筆者使用的jdk1.8，所以設定元空間來測試常量池記憶體溢位情況)
-XX:MetaspaceSize=10M -XX:MaxMetaspaceSize=10Mimport java.util.ArrayList; import java.util.List; public class RuntimeConstantPoolOOM { public static void main(String[] args) { //使用List保持著常量池引用，避免Full GC回收常量池行為 List<String> list = new ArrayList<String>(); //10MB的PermSize在integer範圍內足夠產生OOM了 int i = 0; while (true) { list.add(String.valueOf(i++).intern()); } } }在jdk1.7下會一直執行下去，在看一段程式碼測試String.intern()方法
import java.util.ArrayList; import java.util.List; public class RuntimeConstantPoolOOM { public static void main(String[] args) { String str1 = new StringBuilder("計算機").append("軟體").toString(); System.out.println(str1.intern() == str1); String str2 = new StringBuilder("ja").append("va").toString(); System.out.println(str2.intern() == str2); } }在1.7與1.8版本的jdk中，這個程式碼執行會得到一個true,一個false,jdk1.7的intern()方法會在常量池中記錄首先出現的例項引用，因此intern（）返回的引用和由StringBuilder建立的那個字串例項是同一個。對str2比較返回false是因為“java”這個字串在執行StringBuilder.toString（）之前已經出現過，字串常量池中已經有它的引用了，不符合“首次出現”的原則，而“計算機軟體”這個字串則是首次出現的，因此返回true。
-
方法區用於存放Class的相關資訊，如類名、訪問修飾符、常量池、欄位描述、方法描述等，這個區域的測試思路是：執行時產生大量的類去填滿方法區，直到溢位
-
筆者採用CGLIB直接操作位元組碼執行時產生大量的動態類。很多主流框架，如Spring、Hibernate，在對類進行增強時，都會使用到CGLib這類位元組碼技術，增強的類越多，就需要越大的方法區來保證動態生成的Class可以載入入記憶體。
-XX:MetaspaceSize=10M -XX:MaxMetaspaceSize=10M -XX:+PrintGCDetails
import org.springframework.cglib.proxy.Enhancer;
import org.springframework.cglib.proxy.MethodInterceptor;
public class JavaMethodAreaOOM {
public static void main(
String[] args) {
while (true) {
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(OOMObject.class);
enhancer.setUseCache(false);
enhancer.setCallback((MethodInterceptor) (obj, method, args1, proxy) -> proxy.invokeSuper(obj, args1));
enhancer.create();
}
}
static class OOMObject {
}
}
執行結果
Exception in thread "main" org.springframework.cglib.core.CodeGenerationException: java.lang.OutOfMemoryError-->Metaspace
at org.springframework.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:538)
at org.springframework.cglib.core.AbstractClassGenerator.generate(AbstractClassGenerator.java:363)
at org.springframework.cglib.proxy.Enhancer.generate(Enhancer.java:585)
at org.springframework.cglib.core.AbstractClassGenerator$ClassLoaderData.get(AbstractClassGenerator.java:131)
at org.springframework.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:319)
at org.springframework.cglib.proxy.Enhancer.createHelper(Enhancer.java:572)
at org.springframework.cglib.proxy.Enhancer.create(Enhancer.java:387)
at com.llh.jdk.map.JavaMethodAreaOOM.main(JavaMethodAreaOOM.java:14)
- 方法區溢位也是一種常見的記憶體溢位異常，一個類要被垃圾收集器回收掉，判定條件是比較苛刻的。在經常動態生成大量Class的應用中，需要特別注意類的回收狀況。這類場景除了上面提到的程式使用了CGLib位元組碼增強和動態語言之外，常見的還有：大量JSP或動態產生JSP檔案的應用（JSP第一次執行時需要編譯為Java類）、基於OSGi的應用（即使是同一個類檔案，被不同的載入器載入也會視為不同的類）等。
本地直接記憶體溢位
DirectMemory容量可通過-XX：MaxDirectMemorySize指定，如果不指定，則預設與Java堆最大值（-Xmx指定）一樣
- 使用unsafe分配本機記憶體
-XX:MaxDirectMemorySize=50M -XX:+PrintGCDetails
import sun.misc.Unsafe;
import java.lang.reflect.Field;
public class DirectMemoryOOM {
private static final int _1MB = 1024 * 1024;
public static void main(String[] args) throws Exception {
Field unsafeField = Unsafe.class.getDeclaredFields()[0];
unsafeField.setAccessible(true);
Unsafe unsafe = (Unsafe) unsafeField.get(null);
while (true) {
unsafe.allocateMemory(_1MB);
}
}
}
執行結果
Exception in thread "main" java.lang.OutOfMemoryError
at sun.misc.Unsafe.allocateMemory(Native Method)
at com.llh.jdk.map.DirectMemoryOOM.main(DirectMemoryOOM.java:15)
Heap
PSYoungGen total 75264K, used 5161K [0x000000076ca00000, 0x0000000771e00000, 0x00000007c0000000)
eden space 64512K, 8% used [0x000000076ca00000,0x000000076cf0a638,0x0000000770900000)
from space 10752K, 0% used [0x0000000771380000,0x0000000771380000,0x0000000771e00000)
to space 10752K, 0% used [0x0000000770900000,0x0000000770900000,0x0000000771380000)
ParOldGen total 172032K, used 0K [0x00000006c5e00000, 0x00000006d0600000, 0x000000076ca00000)
object space 172032K, 0% used [0x00000006c5e00000,0x00000006c5e00000,0x00000006d0600000)
Metaspace used 3348K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 366K, capacity 388K, committed 512K, reserved 1048576K
由DirectMemory導致的記憶體溢位，一個明顯的特徵是在Heap Dump檔案中不會看見明顯的異常，如果讀者發現OOM之後Dump檔案很小，而程式中又直接或間接使用了NIO，那就可以考慮檢查一下是不是這方面的原因。