一、堆(Heap)
1.1.什么是堆
堆是用於存放對象的內存區域。因此,它是垃圾收集器(GC)管理的主要目標。其具有以下特點:
- 堆在邏輯上划分為“新生代”和“老年代”。由於JAVA中的對象大部分是朝生夕滅,還有一小部分能夠長期的駐留在內存中,為了對這兩種對象進行最有效的回收,將堆划分為新生代和老年代,並且執行不同的回收策略。不同的垃圾收集器對這2個邏輯區域的回收機制不盡相同,在后續的章節中我們將詳細的講解。
- 堆占用的內存並不要求物理連續,只需要邏輯連續即可。
- 堆一般實現成可擴展內存大小,使用“-Xms”與“-Xmx”控制堆的最小與最大內存,擴展動作交由虛擬機執行。但由於該行為比較消耗性能,因此一般將堆的最大最小內存設為相等。
- 堆是所有線程共享的內存區域,因此每個線程都可以拿到堆上的同一個對象。
- 堆的生命周期是隨着虛擬機的啟動而創建。

1.2.堆異常
當堆無法分配對象內存且無法再擴展時,會拋出OutOfMemoryError異常。
一般來說,堆無法分配對象時會進行一次GC,如果GC后仍然無法分配對象,才會報內存耗盡的錯誤。可以通過不斷生成新的對象但不釋放引用來模擬這種情形:
1 /** 2 * java堆溢出demo 3 * JVM參數:-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError 4 * Created by chenjunyi on 2018/4/25. 5 */ 6 public class HeapOOM { 7 8 static class OOMObject { 9 } 10 11 public static void main(String[] args) { 12 List<OOMObject> list = new ArrayList<>(); 13 //不斷創建新對象,使得Heap溢出 14 while (true) { 15 list.add(new OOMObject()); 16 } 17 } 18 19 }
上述代碼中對象不斷的被創建而不進行引用釋放,導致GC無法回收堆內存,最終OutOfMemoryError,錯誤信息:
1 java.lang.OutOfMemoryError: Java heap space
二、方法區(Method Area)
2.1.什么是方法區
方法區,也稱非堆(Non-Heap),又是一個被線程共享的內存區域。其中主要存儲加載的類字節碼、class/method/field等元數據對象、static-final常量、static變量、jit編譯器編譯后的代碼等數據,。另外,方法區包含了一個特殊的區域“運行時常量池”,它們的關系如下圖所示:


(1)加載的類字節碼:要使用一個類,首先需要將其字節碼加載到JVM的內存中。至於類的字節碼來源,可以多種多樣,如.class文件、網絡傳輸、或cglib字節碼框架直接生成。
(2)class/method/field等元數據對象:字節碼加載之后,JVM會根據其中的內容,為這個類生成Class/Method/Field等對象,它們用於描述一個類,通常在反射中用的比較多。不同於存儲在堆中的java實例對象,這兩種對象存儲在方法區中。
(3)static-final常量、static變量:對於這兩種類型的類成員,JVM會在方法區為它們創建一份數據,因此同一個類的static修飾的類成員只有一份;
(4)jit編譯器的編譯結果:以hotspot虛擬機為例,其在運行時會使用JIT即時編譯器對熱點代碼進行優化,優化方式為將字節碼編譯成機器碼。通常情況下,JVM使用“解釋執行”的方式執行字節碼,即JVM在讀取到一個字節碼指令時,會將其按照預先定好的規則執行棧操作,而棧操作會進一步映射為底層的機器操作;通過JIT編譯后,執行的機器碼會直接和底層機器打交道。如下圖所示:
(2)class/method/field等元數據對象:字節碼加載之后,JVM會根據其中的內容,為這個類生成Class/Method/Field等對象,它們用於描述一個類,通常在反射中用的比較多。不同於存儲在堆中的java實例對象,這兩種對象存儲在方法區中。
(3)static-final常量、static變量:對於這兩種類型的類成員,JVM會在方法區為它們創建一份數據,因此同一個類的static修飾的類成員只有一份;
(4)jit編譯器的編譯結果:以hotspot虛擬機為例,其在運行時會使用JIT即時編譯器對熱點代碼進行優化,優化方式為將字節碼編譯成機器碼。通常情況下,JVM使用“解釋執行”的方式執行字節碼,即JVM在讀取到一個字節碼指令時,會將其按照預先定好的規則執行棧操作,而棧操作會進一步映射為底層的機器操作;通過JIT編譯后,執行的機器碼會直接和底層機器打交道。如下圖所示:


2.2.運行時常量池
在2.1小節中,我們了解到類的字節碼在加載時會被解析並生成不同的東西存入方法區。類的字節碼中不僅包含了類的版本、字段、方法、接口等描述信息,還包含了一個常量池。常量池用於存放在字節碼中使用到的所有字面量和符號引用(如字符串字面量),在類加載時,它們進入方法區的運行時常量池存放。
運行時常量池是方法區中一個比較特殊的部分,具備動態性,也就是說,除了類加載時將常量池寫入其中,java程序運行期間也可以向其中寫入常量:
1 //使用StringBuilder在堆上創建字符串abc,再使用intern將其放入運行時常量池 2 String str = new StringBuilder("abc"); 3 str.intern(); 4 //直接使用字符串字面量xyz,其被放入運行時常量池 5 String str2 = "xyz";
2.3.方法區的實現
方法區的實現,虛擬機規范中並未明確規定,目前有2種比較主流的實現方式:
(1)HotSpot虛擬機1.7-:在JDK1.6及之前版本,HotSpot使用“永久代(permanent generation)”的概念作為實現,即將GC分代收集擴展至方法區。這種實現比較偷懶,可以不必為方法區編寫專門的內存管理,但帶來的后果是容易碰到內存溢出的問題(因為永久代有-XX:MaxPermSize的上限)。在JDK1.7+之后,HotSpot逐漸改變方法區的實現方式,如1.7版本移除了方法區中的字符串常量池。
(2)HotSpot虛擬機1.8+:1.8版本中移除了方法區並使用metaspace(元數據空間)作為替代實現。metaspace占用系統內存,也就是說,只要不碰觸到系統內存上限,方法區會有足夠的內存空間。但這不意味着我們不對方法區進行限制,如果方法區無限膨脹,最終會導致系統崩潰。
我們思考一個問題,為什么使用“永久代”並將GC分代收集擴展至方法區這種實現方式不好,會導致OOM?首先要明白方法區的內存回收目標是什么,方法區存儲了類的元數據信息和各種常量,它的內存回收目標理應當是對這些類型的卸載和常量的回收。但由於這些數據被類的實例引用,卸載條件變得復雜且嚴格,回收不當會導致堆中的類實例失去元數據信息和常量信息。因此,回收方法區內存不是一件簡單高效的事情,往往GC在做無用功。另外隨着應用規模的變大,各種框架的引入,尤其是使用了字節碼生成技術的框架,會導致方法區內存占用越來越大,最終OOM。
2.4.方法區異常
在2.3一節中,我們了解到方法區的2種實現方式最終都會有一個最大值上限,因此若方法區(含運行時常量池)占用內存到達其最大值,且無法再申請到內存時,便會拋出OutOfMemoryError。
在下面的例子中,我們將使用cglib字節碼生成框架不斷生成新的類,最終使方法區內存占用滿,拋出OutOfMemoryError:
1 /** 2 * java方法區溢出OutOfMemoryError(JVM參數適用於JDK1.6之前,借助CGLIB) 3 * JVM參數:-XX:PermSize=10M -XX:MaxPermSize=10M 4 * Created by chenjunyi on 2018/4/26. 5 */ 6 public class JavaMethodAreaOOM { 7 8 public static void main(String[] args) { 9 while (true) { 10 Enhancer enhancer = new Enhancer(); 11 enhancer.setSuperclass(OOMObject.class); 12 enhancer.setUseCache(false); 13 enhancer.setCallback((MethodInterceptor) (o, method, objects, methodProxy) -> methodProxy.invokeSuper(objects, args)); 14 enhancer.create(); 15 } 16 } 17 18 static class OOMObject { 19 } 20 21 }
報錯信息為:
1 Caused by: java.lang.OutOfMemoryError: PermGen space 2 at java.lang.ClassLoader.defineClass1(Native Method) 3 ···
其實,在日常開發中,不僅僅使CGlib字節碼生成框架會產生大量的class信息,動態語言、JSP、基於OSGI的應用都會在方法區額外產生大量的類信息。