主要介紹以下內容: Java虛擬機器記憶體的各個區域, 這些區域的作用, 服務物件以及其中可能產生的問題

執行時資料區域

概覽圖

程式計數器(Program Counter Register)

可以看做當前執行緒所執行的位元組碼的行號指示器. 在多執行緒程式中, 為了執行緒切換後能恢復到正確的執行位置, 每條執行緒都需要一個獨立的程式計數器, 獨立儲存, 我們稱這類記憶體區域為執行緒私有的記憶體.

如果正在執行一個Java方法, 則指向正在執行的虛擬機器位元組碼指令的地址;
如果正在執行一個Native方法(Native方法通常指的是一些系統的底層方法, 有可能是其他語言編寫額), 則計數器的值為未定義(undefined)

注: 本記憶體區域是唯一不會出現OutOfMemoryError的區域.

Java虛擬機器棧(Java Virtual Machine Stacks)

也是執行緒私有的, 生命週期與執行緒相同. 虛擬機器棧描述的是Java方法執行的記憶體模型: 每個方法在執行的同時都會建立一個棧幀(Stack Frame)用於儲存區域性變量表, 運算元棧, 動態連結, 方法出口等資訊. 每一個方法從呼叫到執行完成的過程, 就對應著一個棧幀在虛擬機器棧從入棧到出棧的過程.

區域性變量表: 存放編譯期可知的基本資料型別(boolean, byte, char, short, int, float, long, double

本區域可能出現兩種異常:

• StackOverflowError: 執行緒請求的棧深度大於虛擬機器所允許的深度;
• OutOfMemoryError: 棧擴充套件時無法申請到足夠的記憶體.

本地方法棧(Native Method Stack)

與Java虛擬機器棧非常類似, Java虛擬機器棧為執行Java位元組碼服務, 本地方法棧為執行Native方法服務. 有的虛擬機器的實現直接將二者合為一, 比如HotSpot虛擬機器. 本區域可能出現的異常與Java虛擬機器棧相同.

Java堆(Java Heap)

被所有執行緒共享, 用於存放物件例項. 是垃圾收集器管理的主要區域. 很多時候也叫做GC堆(Garbage Collected Heap).

從記憶體回收的角度來說, 現在的收集器採用分代收集演算法, 所以可以分為: 新生代和老年代, 再細分可以分為Eden空間, From Survivor空間, To Survivor空間.

從記憶體分配的角度來看, Java堆中可能劃分出多個執行緒私有的分配緩衝區(Thread Local Allocation Buffer, TLAB). 所有劃分方式的目的都是為了更好的回收記憶體, 或者更快的分配記憶體.

此區域只是一個邏輯上連續的記憶體區域, 當堆無法擴充套件的時候, 會丟擲OutOfMemoryError異常.

方法區(Method Area)

所有執行緒共享, 儲存被虛擬機器載入的類資訊(個人補充: 實際上就是類物件的存放位置), 常量, 靜態變數, 即時編譯器編譯後的程式碼(TODO 這是什麼)等資料.是Java堆的一個邏輯部分.

通常來說, GC分代收集方法會將方法區設定為永久代(Permanent Generation), 但是容易出現記憶體溢位問題(比如永久代有-XX:MaxPermSize的上限). 這個區域的記憶體回收目標主要是針對常量池的回收和對型別的解除安裝.

本區域可能出現的異常是OutOfMemoryError.

執行時常量池(Runtime Constant Pool)

是方法區的一部分, 存放類在編譯期生成的各種字面量和符號引用, 在類被載入後進入這裡存放. 其次, 在執行期間也可以將新的常量放入池中, 比如String類的intern()方法.

本區域可能出現的異常是OutOfMemoryError

直接記憶體(Direct Memory)

注意: 本區域不是虛擬機器執行時資料區的一部分, 但是因為也被頻繁的使用, 也可能導致OutOfMemoryError的出現.

通常是作為堆外記憶體的一種形式, 例如, Java的NIO(New Input/Output), 引入了一種基於通道(Channel)和緩衝區(Buffer)的I/O方式, 使用Native函式庫直接分配堆外記憶體, 通過一個儲存在Java堆中的DirectByteBuffer物件作為這塊記憶體的引用進行操作. 這樣能在一些場景中顯著提高效能, 因為它避免了在Java堆和Native堆中來回複製資料.

記憶體溢位

Java堆溢位

要解決這個區域的異常, 通常先通過記憶體映像分析工具對Dump出來的堆轉儲快照進行分析, 重點是確認記憶體中的物件是否是必要的, 也就是要先分清楚到底是出現了記憶體洩露(Memory Leak)還是記憶體溢位(Memory Overflow).

記憶體洩露 指的是本來應該回收的物件沒有被正確回收, 那麼物件肯定存在到GC Root的引用鏈, 從而找到程式碼洩露的位置.
記憶體溢位 指的是記憶體中的物件確實都是必要的, 此時應該檢查虛擬機器的堆引數(-Xms與-Xmx), 看是否可以調大, 不然就需要從程式碼上檢查是否有物件的生命週期過長的情況, 嘗試減少程式執行期的記憶體消耗.

虛擬機器棧和本地方法棧溢位

在單個執行緒下, 無論是由於棧幀太大還是虛擬機器棧容量太小, 都會丟擲StackOverflowError.

在多執行緒的情況下, 會出現OutOfMemoryError的情況, 但是這不是虛擬機器棧記憶體溢位, 而是程序的記憶體溢位. 究其原因, 作業系統分配給每個程序的記憶體是有限制的, 比如32bits的windows是2GB.
2GB-Xmx-MaxPermSize就約等於虛擬機器棧的容量了, 如果每個執行緒分配到的棧容量越大, 那麼可以建立的執行緒數量自然就越少. 需要通過:

1. 減小Xmx
2. 減小棧容量

來換取更多的執行緒. 實踐經驗表明, 棧深度在1000~2000完全沒問題, 對於正常的方法呼叫(包括遞迴), 這個深度完全夠用了.

方法區和執行時常量池溢位

在JDK 1.7之前, 執行時常量池基本上在垃圾回收中屬於永久代, 所以我們可以通過設定-XX:PermSize=10M -XX:MaxPermsize=10M將它的大小限制在10M, 不能增長.

但是JDK1.7之後, 這部分就不大容易溢位了, 究其原因, 例如在遇到String型別的物件上進行intern()呼叫時, 不是進行賦值, 而是直接呼叫引用.

而方法區在使用Spring, Hibernate等框架對類進行增強的時候, 會使用到CGLib這類位元組碼技術, 增強的類越多, 需要越大的方法區來保證動態生成的Class可以載入記憶體. 其次還有以下場景會引出OutofMemoryError:

• 基於JVM的動態語言
• 大量JSP或者動態生成JSP檔案的應用(JSP第一次執行需要編譯為Java類);

本機直接記憶體溢位

直接記憶體的大小可以通過-XX:MaxDirectMemorySize指定, 預設為-Xmx的值

通常直接記憶體溢位丟擲的異常與Java堆溢位丟擲的異常類似, 不過Dump檔案不會看見明顯的異常, 而且檔案很小, 如果符合以上特徵, 而程式中又直接或者間接的使用了NIO, 那麼就可能是這方面的原因.