Java與C++之間有一堵由內存動態分配和垃圾收集技術所圍成的"高牆",牆外面的人想進去,牆裏面的人卻想出來。
2.1 概述
對於Java程序員來說,在虛擬機自動內存管理機制的幫助下,不需要爲每一個new操作去寫配對的delete/free代碼,不容易出現內存泄漏和內存溢出問題,但也因此把內存控制的權利交給了Java虛擬機,一旦出現內存泄漏和溢出方面的問題,排查錯誤將成爲一項異常艱難的工作
2.2運行時數據區域
Java虛擬機所管理的內存包括以下幾個運行時數據區域:
2.2.1 程序計數器
1.程序計數器(Program Counter Register)是一塊較小的內存空間,它可以看做是當前線程所執行的字節碼的行號指示器,在虛擬機的概念模型裏(僅是概念模型,各種虛擬機可能回通過更高效的方式去實現),字節碼解釋器就是通過改變這個計數器的值來選取下一條需要執行的字節碼指令,分支,循環,跳轉,異常處理,線程回覆等基礎功能都需要依賴這個計數器完成
2.Java虛擬機的多線程是通過線程輪流切換並分配處理器執行時間的方式來實現的,在任何一個確定的時刻,一個處理器(對於多核處理器來說是一個內核)都只會執行一條線程中的指令,因此,爲了線程切換後能恢復到正確的執行位置,每條線程都需要有一個獨立的程序計數器,各條線程之間計數器互不影響,獨立存儲,我們稱這類內存區域爲"線程私有"的內存
3.如果線程正在執行的是一個Java方法,這個計數器記錄的是正在執行的虛擬機字節碼指令的地址,如果正在執行的是Native方法,這個計數器值則爲空,此內存區域是唯一一個在Java虛擬機規範中沒有規定任何OutOfMemoryError情況的區域
2.2.2 Java虛擬機棧
1.與程序計數器是一樣的,Java虛擬機棧(Java Virtual Machine Stacks)也是線程私有的,它的生命週期與線程相同,虛擬機棧描述的是Java方法執行的內存模型,每個方法在執行的同時都會創建一個棧幀用於存儲局部變量表,操作數棧,動態鏈接,方法出口燈信息,每一個方法從調用直至執行完成的過程,就對應着一個棧幀在虛擬機棧中入棧到出棧的過程
2.局部變量表存放了編譯器可知的各種基本數據類型(boolean,bytechar,short,int,float,long,double),對象引用(reference類型,它不等同於對象本身,可能是一個指向對象起始地址的引用指針,也可能是指向一個代表對象的句柄或其他與此對象相關的位置)和returnAddress類型(指向了一條字節碼指令的地址)
3.其中64位長度的long和double類型的數據會佔用兩個局部變量空間,其餘的數據類型只佔用一個,局部變量表所需的內存空間在編譯期間完成,當進入一個方法時,這個方法需要在幀中分配多大的局部變量空間是完全確定的,在方法運行期間不會改變局部變量表的大小
4.在Java虛擬機規範中,對這個區域規定了兩種異常情況,如果線程請求的棧深度大於虛擬機所允許的深度,將拋出StackOverflowError異常;如果虛擬機可以動態擴展,如果擴展時無法申請到足夠的內存,就會拋出OutOfMemoryError異常
2.2.3 本地方法棧
本地方法棧與虛擬機棧所發揮的作用是非常相似的,他們之間的區別是,虛擬機棧爲虛擬機執行Java方法(也就是字節碼)服務,而本地方法棧則爲虛擬機使用到的Native方法服務,有的虛擬機直接把本地方法棧和虛擬機合二爲一.與虛擬機棧一樣,本地方法棧區域也會拋出StackOverflowError和OutOfMemoryError異常
2.2.4 Java堆
1.對於大多數應用來說,Java堆(Java Heap)是Java虛擬機所管理的內存中最大的一塊
2.Java堆是被多有線程共享的一塊內存區域(可能劃分出多個線程私有的分配緩衝區),在虛擬機啓動時創建
3.堆內存區域唯一的目的就是存放對象實例,幾乎所有的對象實例都在這裏分配內存,Java虛擬機規範中的描述是:所有的對象實例以及數組都要在堆上分配(但隨着JIT編譯器的發展與逃逸分析技術逐漸成熟,棧上分配,標量替換優化技術將會導致一些微妙的變化發生,所有的對象都分配在堆上也不是那麼絕對了)
4.Java堆是垃圾收集器管理的主要區域,因此很多時候也被稱作"GC堆"
5.Java堆可以處於物理上不連續的內存空間中,只要邏輯上是連續的即可,並且當前主流的虛擬機都是按照可擴展來實現的,如果在堆中內有內存完成實例分配,並且堆再也無法擴展時,將會拋出OutOfMemoryError異常
2.2.5 方法區
1.方法區(Method Area)與Java堆一樣,是各個線程共享的內存區域,它用於存儲已被虛擬機加載的類信息,常量,靜態變量,即時編譯器編譯後的代碼等數據
2.方法區和Java堆一樣不需要連續的內存和可以選擇固定大小和可擴展外,還可以選擇不實現垃圾收集,垃圾收集行爲在這個區域比較少出現,回收目標主要是針對常量池的回收和堆類型的卸載
3.根據Java虛擬機規範的規定,當方法區無法滿足內存分配需求時,將拋出OutOfMemoryError異常
2.2.6 運行時常量池
1.運行時常量池(Runtime Constant Pool)是方法區的一部分,Class文件中除了有類的版本,字段,方法,接口等描述信息外,還有一項信息是常量池,用於存放編譯器生成的各種字面量和符號引用,這部分內容將在類加載後進入方法區的運行時常量池中存放
2.一般來說,除了保存Class文件中描述的符號引用外,還會把翻譯出來的直接引用也存儲在運行時常量池中
3.運行時常量池相對於Class文件常量池的另外一個重要特徵是具備動態性,Java語言並不要求常量一定只有編譯期才能產生,也就是並非預置入Class文件中常量池的內容才能進入方法區運行時常量池,運行期間也可能將新的常量放入池中,這種特性被開發人員利用比較多的就是String類的intern()
4.當常量池無法再申請到內存時將拋出OutOfMemoryError異常
2.2.7 直接內存
1.直接內存並不是虛擬機運行時數據區的一部分,也不是Java虛擬機規範中定義的內存區域
2.在JDK1.4中新加入了NIO(New Input/Output)類,引入了一種基於通道(Channel)與緩衝區(Buffer)的I/O方式,它可以使用Native函數庫直接分配堆外內存,然後通過一個存儲在Java堆中的DirectByteBuffer對象作爲這塊內存的引用進行操作,這樣能在一些場景中顯著提高性能,因爲避免了在Java堆和Native堆中來回複製數據
3.在配置虛擬機參數時,會根據實際內存設置-Xmx等參數信息,但經常忽略直接內存,使得各個內存區域總和大於物理內存限制(包括物理的和操作系統級的限制),從而導致動態擴展時出現OutOfMemoryError異常
2.3 HotSpot虛擬機對象探祕
以下以虛擬機HotSpot和常用的內存區域Java堆爲例,深入探討HotSpot虛擬機在Java堆中對象分配,佈局和訪問的過程
2.3.1 對象的創建
1.虛擬機遇到一條new指令時,首先將去檢查這個指令的參數是否能在常量池中定位到一個類的符號引用,並且檢查這個符號引用代表的類是否已被加載,解析和初始化過,如果沒有,那必須先執行相應的類加載過程。
2.在類加載檢查通過後,接下來虛擬機將爲新生對象分配內存,對象所需內存的大小在類加載完成後便可完全確定,爲對象分配空間的任務等同於把一塊確定大小的內存從Java堆中劃分出來。
3.如果Java堆中內存是絕對規整的,所有用過的內存都放在一邊,空閒的內存放在另一邊,中間放着一個指針作爲分界點的指示器,那所分配內存就僅僅是把那個指針向空閒空間那邊挪動一段與對象大小相等的距離,這種分配方式成爲"指針碰撞"
如果Java堆中的內存並不是規整的,已使用的內存和空閒的內存相互交錯,那就沒辦法簡單地進行指針碰撞,虛擬機必須維護 一個列表,記錄哪些內存是可用的,在分配的時候從列表中找到一塊足夠大的空間劃分給對象實例,並更新列表上的記錄,這種分配方式成爲"空間列表"，使用哪種分配方式由Java堆是否規整決定,而Java堆是否規整又由所採用的垃圾收集器是否帶有壓縮整理功能決定。
4.即使僅僅修改一個指針所指向的位置,在併發情況下也並不是線程安全的,可能出現正在給對象A分配內存,指針還沒來得及修改,對象B又同時使用了原來的指針來分配內存的情況,解決這個問題有兩種方案：
1）一種是對分配內存空間的動作進行同步處理,實際上虛擬機採用CAS配上失敗重試的方式保證更新操作的原子性；
2）另一種是把內存分配的動作按照線程劃分在不同的空間之中進行,即每個線程在Java堆中預先分配一小塊內存,稱爲本地線程分配緩衝,哪個線程要分配內存,就在哪個線程的TLAB上分配,只有TLAB用完並分配新的TLAB時,才需要同步鎖定。
5.內存分配完成後,虛擬機需要將分配到的內存空間都初始化爲零值(不包括對象頭),如果使用TLAB,這一工作過程也可以提前至TLAB分配時進行,這一步操作保證了對象的實例字段在Java代碼中可以不賦初始值就直接使用,程序能訪問到這些字段的數據類型所對應的零值。
6.虛擬機對對象進行必要的設置,例如這個對象是哪個類的實例,如何才能找到類的元數據信息,對象的哈希碼,對象的GC分代年齡等信息,這些信息存放在對象的對象頭(Object Header)之中。
7.完成以上步驟後,從虛擬機視角,一個新的對象已經產生了,但從Java程序的視角來看,對象的init方法還沒有執行,所有的字段都還爲零,執行完init方法後,一個可用的對象才被完全創建出來。
2.3.2對象的內存佈局
1.在HotSpot虛擬機中,對象在內存中存儲的佈局可以分爲3塊區域:對象頭,實例數據和對齊填充
2.對象頭包括兩部分信息,第一部分用於存儲對象自身的運行時數據,如哈希碼,GC分代年齡,鎖狀態標誌,線程持有的鎖,偏向 鎖ID,偏向時間戳等，另一部分是類型指針,即對象指向它的元數據的指針,虛擬機通過這個指針來確定這個對象是哪個類的實例,並不是所有的虛擬機實現都必須在對象數據上保留類型指針,換句話說,查找對象的元數據信息並不一定要經過對象本身,如果對象是一 個Java數組,那麼對象頭中還必須有一塊用於記錄數組長度的數據,因爲虛擬機可以通過普通Java對象的元數據信息確定 Java對象的大小,但是從數據的元數據中卻無法確定數組的大小
3.實例數據部分是對象真正存儲的有效信息,也是在程序代碼中所定義的各種類型的字段內容,無論是從父類繼承下來的還是 在子類中定義的,都需要記錄下來
4.對齊填充並不是必然存在的,它僅僅起着佔位符的作用,HotSpot自動內存管理系統要求對象起始地址必須是8字節的整數倍,換句話說,就是對象的大小必須是8字節的整數倍而對象頭部分正好是8字節的倍數(1倍或者2倍),因此,當對象實例 數據部分沒有對齊時,就需要通過對齊填充來補全
2.3.3 對象的訪問定位
Java程序需要通過棧上的reference數據來操作堆上的具體對象,由於reference類型在Java虛擬機規範中只規定了一個指向對象的引用,並沒有定義這個引用應該通過何種方式去定位,訪問堆中的對象的具體位置,所以對象訪問方式也是取決於虛擬機實現而定的,目前主流的訪問方式有使用句柄和直接指針兩種
1.句柄訪問:Java堆中會劃分一塊內存來作爲句柄池,reference中存儲的就是對象的句柄地址,而句柄中包含了對象實例數據與類型數據各自的具體地址信息。
2.直接指針訪問:Java堆對象的佈局中必須考慮如何放置訪問類型數據的相關信息,而reference中存儲的直接就是對象地址。
兩種對象訪問方式各有優勢,使用句柄來訪問的最大好處是reference中存儲的是穩定的句柄地址,在對象被移動(垃圾收集時移動對象是非常普遍的行爲)時只會改變句柄中的實例數據指針,而reference本身不需要修改，使用直接指針訪問的最大好處是速度快,它節省了一次指針定位的時間開銷,由於對象的訪問在Java中非常頻繁,因此這類開銷積少成多後也是一項非常可觀的執行成本,Sun HotSpot使用第二種方式進行對象訪問
2.4 實戰:OutOfMemoryError異常
在Java虛擬機規範的描述中,除了程序計數器外,虛擬機內存的其他幾個運行時區域都有發生OutOfMemoryError異常的可能
2.4.1 Java堆溢出
Java堆用於存儲對象實例,只要不斷的創建對象,並且保證GC Roots到對象之間有可達路徑來避免垃圾回收機制清除這些對象,那麼在對象數量達到最大堆的容量限制後就會產生內存溢出異常
// Java堆內存溢出異常測試
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堆內存溢出時,異常堆棧信息"java.lang.OutOfMemoryError"和"Java heap space"提示
要解決這個問題,重點是確認內存中的對象是否是必要的,也就是先分析是出現了內存泄漏還是內存溢出
如果是內存泄漏,可通過工具查看泄漏對象到GC Roots的引用鏈,於是就能找到泄漏對象是通過怎樣的路徑與GC Roots相關聯並導致垃圾收集器無法自動回收它們,掌握了泄漏對象的類型信息及GC Roots引用鏈的信息,就可以比較準確的定位出泄漏代碼的位置
如果不存在泄漏,換句話說,就是內存中的對象確實都還必須存貨着,那就應該檢查虛擬機的堆參數(-Xmx 與 -Xms),與機器物理內存對比看是否還可以調大,從代碼上檢查是否存在某些對象生命週期過長,持有狀態時間過長的情況,嘗試減少程序運行期的內存消耗
2.4.2 虛擬機棧和本地方法棧溢出
HotSpot虛擬機並不區分虛擬機棧和本地方法棧,關於虛擬機棧和本地方法棧,在Java虛擬機規範中描述了兩種異常:
1.如果線程請求和棧深度大於虛擬機所允許的最大深度,將拋出 StackOverflowError異常
2.如果虛擬機在擴展棧時無法申請到足夠的內存空間,則拋出 OutOfMemoryError 異常
在單線程下,無論是由於棧幀太大還是虛擬機棧容量太小,當內存無法分配時,虛擬機拋的都是 StackOverflowError異常
// 虛擬機和本地方法棧OOM單線程測試,結果拋出java.lang.StackOverflowError
public 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;
}
}
}
通過不斷的建立線程可以產生內存溢出異常,但這樣產生的內存溢出異常和棧空間是否足夠大並不存在任何聯繫,在這種情況下,爲每個線程的棧分配的內存越大,反而容易產生內存溢出異常,主要是因爲操作系統分配給每個進程的內存是有限制的,每個線程分配到的棧容量越大,可以建立的線程數量就越少,所以有時候可以通過減少每個線程所分內存的大小來解決內存溢出
// 創建多線程導致內存溢出異常,運行結果報 java.lang.OutOfMemoryError
public class JavaVMStackSOF {
public void dontStop(){
while(true){
}
}
public void stackLeakByThread(){
while (true){
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
dontStop();
}
});
thread.start();
}
}
public static void main(String[] args)throws Throwable {
JavaVMStackSOF oom = new JavaVMStackSOF();
oom.stackLeakByThread();
}
}
2.4.3 方法區和運行時常量池溢出
運行時常量池是方法區的一部分,方法區用於存放Class的相關信息,如類名,訪問修飾符,常量池,字段描述,方法描述等,方法區溢出也是一種常見的內存溢出異常,一個類要被垃圾收集器回收掉,判定條件是比較苛刻的,在經常動態生成大量的Class的應用中,需要特別注意類的回收狀況,這類場景包括CGLib字節碼增強和動態語言,大量JSP或動態產生JSP文件的應用(JSP第一次運行時需要編譯爲Java類),基於OSGi的應用(即使是同一個類文件,被不同的加載器加載也會視爲不同的類)等
2.4.4 本機直接內存溢出
DirectMemory容量可以通過-XX:MaxDirectMemorySize指定,如果不指定,則默認與Java堆最大值(-Xmx指定)一樣,申請分配內存的方法是unsafe.allocateMemory
// 使用unsafe分配本機內存
public class DirectMemoryOOM {
private static final int _1MB = 1024*1024;
public static void main(String[] args) {
Field unsafeField = Unsafe.class.getDeclaredFields()[0];
unsafeField.setAccessible(true);
Unsafe unsage = null;
try {
unsage = (Unsafe)unsafeField.get(null);
} catch (IllegalAccessException e) {
e.printStackTrace();
}
while (true){
unsage.allocateMemory(_1MB);
}
}
}
由DirectMemory導致的內存溢出,一個明顯的特徵是在Heap Dump文件中不會看見明顯的異常,如果發現OOM之後Dump文件很小,而程序中又直接或間接使用了NIO,那麼就可以考慮檢查一下這方面的原因