Java內存分析

Java內存管理：深刻Java內存區域

　　本文引用自：深刻理解Java虛擬機的第2章內容

　　Java與C++之間有一堵由內存動態分配和垃圾收集技術所圍成的高牆，牆外面的人想進去，牆裏面的人卻想出來。

　　概述：

　　對於從事C和C++程序開發的開發人員來講，在內存管理領域，他們既是擁有最高權力的皇帝，又是從事最基礎工做的勞動人民—既擁有每

一個對象的「全部權」，又擔負着每個對象生命開始到終結的維護責任。

　　對於Java程序員來講，在虛擬機的自動內存管理機制的幫助下，再也不須要爲每個new操做去寫配對的delete/free代碼，並且不容易出現

內存泄漏和內存溢出問題，看起來由虛擬機管理內存一切都很美好。不過，也正是由於Java程序員把內存控制的權力交給了Java虛擬機，一旦

出現內存泄漏和溢出方面的問題，若是不瞭解虛擬機是怎樣使用內存的，那排查錯誤將會成爲一項異常艱難的工做。

 

　　運行時數據區域

　　Java虛擬機在執行Java程序的過程當中會把它所管理的內存劃分爲若干個不一樣的數據區域。這些區域都有各自的用途，以及建立和銷燬的時

間，有的區域隨着虛擬機進程的啓動而存在，有些區域則是依賴用戶線程的啓動和結束而創建和銷燬。根據《Java虛擬機規範（第2版）》的規

定，Java虛擬機所管理的內存將會包括如下幾個運行時數據區域，以下圖所示：

　　　　　　　　　　

 

　　程序計數器　　　　　

　　程序計數器（Program Counter Register）是一塊較小的內存空間，它的做用能夠看作是當前線程所執行的字節碼的行號指示器。在虛擬

機的概念模型裏（僅是概念模型，各類虛擬機可能會經過一些更高效的方式去實現），字節碼解釋器工做時就是經過改變這個計數器的值來選取

下一條須要執行的字節碼指令，分支、循環、跳轉、異常處理、線程恢復等基礎功能都須要依賴這個計數器來完成。 因爲Java虛擬機的多線

程是經過線程輪流切換並分配處理器執行時間的方式來實現的，在任何一個肯定的時刻，一個處理器（對於多核處理器來講是一個內

核）只會執行一條線程中的指令。所以，爲了線程切換後能恢復到正確的執行位置，每條線程都須要有一個獨立的程序計數器，各條

線程之間的計數器互不影響，獨立存儲，咱們稱這類內存區域爲「線程私有」的內存。 若是線程正在執行的是一個Java方法，這個計數器

記錄的是正在執行的虛擬機字節碼指令的地址；若是正在執行的是Natvie方法，這個計數器值則爲空（Undefined）。此內存區域是惟一一個

在Java虛擬機規範中沒有規定任何OutOfMemoryError狀況的區域。

 

　　Java虛擬機棧

　　與程序計數器同樣，Java虛擬機棧（Java Virtual Machine Stacks）也是線程私有的，它的生命週期與線程相同。虛擬機棧描述的是Java

方法執行的內存模型：每一個方法被執行的時候都會同時建立一個棧幀（Stack Frame）用於存儲局部變量表、操做棧、動態連接、方法出口

等信息。每個方法被調用直至執行完成的過程，就對應着一個棧幀在虛擬機棧中從入棧到出棧的過程。

　　常常有人把Java內存區分爲堆內存（Heap）和棧內存（Stack），這種分法比較粗糙，Java內存區域的劃分實際上遠比這複雜。這種劃分

方式的流行只能說明大多數程序員最關注的、與對象內存分配關係最密切的內存區域是這兩塊。其中所指的「堆」在後面會專門講述，而所指

的「棧」就是如今講的虛擬機棧，或者說是虛擬機棧中的局部變量表部分。

　　局部變量表存放了編譯期可知的各類基本數據類型（boolean、byte、char、short、int、float、long、double）、對象引用

（reference類型），它不等同於對象自己，根據不一樣的虛擬機實現，它多是一個指向對象起始地址的引用指針，也可能指向一個表明對象的

句柄或者其餘與此對象相關的位置）和returnAddress類型（指向了一條字節碼指令的地址）。

　　其中64位長度的long和double類型的數據會佔用2個局部變量空間（Slot），其他的數據類型只佔用1個。局部變量表所需的內存

空間在編譯期間完成分配，當進入一個方法時，這個方法須要在幀中分配多大的局部變量空間是徹底肯定的，在方法運行期間不會改

變局部變量表的大小。 在Java虛擬機規範中，對這個區域規定了兩種異常情況：若是線程請求的棧深度大於虛擬機所容許的深度，將拋出

StackOverflowError異常；若是虛擬機棧能夠動態擴展（當前大部分的Java虛擬機均可動態擴展，只不過Java虛擬機規範中也容許固定長度的

虛擬機棧），當擴展時沒法申請到足夠的內存時會拋出OutOfMemoryError異常。

 

　　本地方法棧

　　本地方法棧（Native Method Stacks）與虛擬機棧所發揮的做用是很是類似的，其區別不過是虛擬機棧爲虛擬機執行Java方法（也就是字

節碼）服務，而本地方法棧則是爲虛擬機使用到的Native方法服務。虛擬機規範中對本地方法棧中的方法使用的語言、使用方式與數據結構並沒

有強制規定，所以具體的虛擬機能夠自由實現它。甚至有的虛擬機（譬如Sun HotSpot虛擬機）直接就把本地方法棧和虛擬機棧合二爲一。與

虛擬機棧同樣，本地方法棧區域也會拋出StackOverflowError和OutOfMemoryError異常。

 

　　Java堆

　　對於大多數應用來講，Java堆（Java Heap）是Java虛擬機所管理的內存中最大的一塊。Java堆是被全部線程共享的一塊內存區域，在虛擬機啓動時建立。此內

存區域的惟一目的就是存放對象實例，幾乎全部的對象實例都在這裏分配內存。這一點在Java虛擬機規範中的描述是：全部的對象實例以及數組都要在堆上分配，

可是隨着JIT編譯器的發展與逃逸分析技術的逐漸成熟，棧上分配、標量替換優化技術將會致使一些微妙的變化發生，全部的對象都分配在堆上也漸漸變得不是那麼「絕

對」了。

　　Java堆是垃圾收集器管理的主要區域，所以不少時候也被稱作「GC堆」（Garbage Collected Heap，幸虧國內沒翻譯成「垃圾堆」）。若是從內存回收的角度看，

因爲如今收集器基本都是採用的分代收集算法，因此Java堆中還能夠細分爲：新生代和老年代；再細緻一點的有Eden空間、From Survivor空間、To Survivor空間

等。若是從內存分配的角度看，線程共享的Java堆中可能劃分出多個線程私有的分配緩衝區（Thread Local Allocation Buffer，TLAB）。不過，不管如何劃

分，都與存放內容無關，不管哪一個區域，存儲的都仍然是對象實例，進一步劃分的目的是爲了更好地回收內存，或者更快地分配內存。在本章中，咱們僅僅針對內存區

域的做用進行討論，Java堆中的上述各個區域的分配和回收等細節將會是下一章的主題。

　　根據Java虛擬機規範的規定，Java堆能夠處於物理上不連續的內存空間中，只要邏輯上是連續的便可，就像咱們的磁盤空間同樣。在實現時，既能夠實現成固定

大小的，也能夠是可擴展的，不過當前主流的虛擬機都是按照可擴展來實現的（經過-Xmx和-Xms控制）。若是在堆中沒有內存完成實例分配，而且堆也沒法再擴展

時，將會拋出OutOfMemoryError異常。

 

　　方法區

　　方法區（Method Area）與Java堆同樣，是各個線程共享的內存區域，它用於存儲已被虛擬機加載的類信息、常量、靜態變量、即時編譯器編譯後的代碼等

數據。雖然Java虛擬機規範把方法區描述爲堆的一個邏輯部分，可是它卻有一個別名叫作Non-Heap（非堆），目的應該是與Java堆區分開來。

　　對於習慣在HotSpot虛擬機上開發和部署程序的開發者來講，不少人願意把方法區稱爲「永久代」（Permanent Generation），本質上二者並不等價，僅僅是因

爲HotSpot虛擬機的設計團隊選擇把GC分代收集擴展至方法區，或者說使用永久代來實現方法區而已。對於其餘虛擬機（如BEA JRockit、IBM J9等）來講是不存在

永久代的概念的。即便是HotSpot虛擬機自己，根據官方發佈的路線圖信息，如今也有放棄永久代並「搬家」至Native Memory來實現方法區的規劃了。

　　Java虛擬機規範對這個區域的限制很是寬鬆，除了和Java堆同樣不須要連續的內存和能夠選擇固定大小或者可擴展外，還能夠選擇不實現垃圾收集。相對而言，

垃圾收集行爲在這個區域是比較少出現的，但並不是數據進入了方法區就如永久代的名字同樣「永久」存在了。這個區域的內存回收目標主要是針對常量池的回收和對類型

的卸載，通常來講這個區域的回收「成績」比較難以使人滿意，尤爲是類型的卸載，條件至關苛刻，可是這部分區域的回收確實是有必要的。在Sun公司的BUG列表中，

　　曾出現過的若干個嚴重的BUG就是因爲低版本的HotSpot虛擬機對此區域未徹底回收而致使內存泄漏。 根據Java虛擬機規範的規定，當方法區沒法知足內存分配

需求時，將拋出OutOfMemoryError異常。

 

　　運行時常量池

　　運行時常量池（Runtime Constant Pool）是方法區的一部分。Class文件中除了有類的版本、字段、方法、接口等描述等信息外，還有一項信息是常量池

（Constant Pool Table），用於存放編譯期生成的各類字面量和符號引用，這部份內容將在類加載後存放到方法區的運行時常量池中。 Java虛擬機對Class

文件的每一部分（天然也包括常量池）的格式都有嚴格的規定，每個字節用於存儲哪一種數據都必須符合規範上的要求，這樣纔會被虛擬機承認、裝載和執行。但對於

　　運行時常量池，Java虛擬機規範沒有作任何細節的要求，不一樣的提供商實現的虛擬機能夠按照本身的須要來實現這個內存區域。不過，通常來講，除了保存Class

文件中描述的符號引用外，還會把翻譯出來的直接引用也存儲在運行時常量池中。 運行時常量池相對於Class文件常量池的另一個重要特徵是具有動態性，Java語言

並不要求常量必定只能在編譯期產生，也就是並不是預置入Class文件中常量池的內容才能進入方法區運行時常量池，運行期間也可能將新的常量放入池中，這種特性被

開發人員利用得比較多的即是String類的intern()方法。 既然運行時常量池是方法區的一部分，天然會受到方法區內存的限制，當常量池沒法再申請到內存時會拋出

OutOfMemoryError異常。

 

　　對象訪問

　　介紹完Java虛擬機的運行時數據區以後，咱們就能夠來探討一個問題：在Java語言中，對象訪問是如何進行的？對象訪問在Java語言中無處不在，是最普通的程

序行爲，但即便是最簡單的訪問，也會卻涉及Java棧、Java堆、方法區這三個最重要內存區域之間的關聯關係，以下面的這句代碼：

　　　　　　　　　　Object obj = new Object();

假設這句代碼出如今方法體中，那「Object obj」這部分的語義將會反映到Java棧的本地變量表中，做爲一個reference類型數據出現。而「new Object()」這部分的語

義將會反映到Java堆中，造成一塊存儲了Object類型全部實例數據值（Instance Data，對象中各個實例字段的數據）的結構化內存，根據具體類型以及虛擬機實現

的對象內存佈局（Object Memory Layout）的不一樣，這塊內存的長度是不固定的。另外，在Java堆中還必須包含能查找到此對象類型數據（如對象類型、父類、實

現的接口、方法等）的地址信息，這些類型數據則存儲在方法區中。

　　因爲reference類型在Java虛擬機規範裏面只規定了一個指向對象的引用，並無定義這個引用應該經過哪一種方式去定位，以及訪問到Java堆中的對

象的具體位置，所以不一樣虛擬機實現的對象訪問方式會有所不一樣，主流的訪問方式有兩種：使用句柄和直接指針。 若是使用句柄訪問方式，Java堆中將會

劃分出一塊內存來做爲句柄池，reference中存儲的就是對象的句柄地址，而句柄中包含了對象實例數據和類型數據各自的具體地址信息，以下圖所示：

 

　　　　　　

　　若是使用的是直接指針訪問方式，Java 堆對象的佈局中就必須考慮如何放置訪問類型數據的相關信息，reference中直接存儲的就是對象地址，以下

圖所示：

　　　　　　

　　這兩種對象的訪問方式各有優點，使用句柄訪問方式的最大好處就是reference中存儲的是穩定的句柄地址，在對象被移動（垃圾收集時移動對象是非

常廣泛的行爲）時只會改變句柄中的實例數據指針，而reference自己不須要被修改。使用直接指針訪問方式的最大好處就是速度更快，它節省了一次指針

定位的時間開銷，因爲對象的訪問在Java中很是頻繁，所以這類開銷聚沙成塔後也是一項很是可觀的執行成本。就本書討論的主要虛擬機Sun HotSpot而

言，它是使用第二種方式進行對象訪問的，但從整個軟件開發的範圍來看，各類語言和框架使用句柄來訪問的狀況也十分常見。