第二章:Java內存區域與內存溢出異常（1）

學習筆記：深刻理解Java虛擬機 第二章:Java內存區域與內存溢出異常（1）

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

1、概述

​ C、C++的開發人員在內存管理領域擁有最高權力，但他們也要從事最基礎的工做——擁有每一個對象的「全部權」，也要負責對每個對象生命週期內的維護。

而Java程序員，由於有JVM的自動內存管理機制，不須要爲每一個new操做寫配對的delete/free代碼，不容易出現內存泄漏和內存溢出。但也正由於此一旦發生了內存泄漏和溢出問題，若是不瞭解JVM使用內存的原理，那麼排查異常將會異常艱難。

2、運行時數據區域

​ Java虛擬機在執行Java程序的過程當中會把所管理的內存劃分爲若干個不一樣的數據區，這些區域具備不一樣的用途和生命週期。有的區域隨虛擬機啓動而存在，有的則依賴於用戶線程的啓動和創建和銷燬。《Java虛擬機規範》規定，Java虛擬機所管理的內存將會包括如下幾個運行時數據區域。

1.程序計數器

​ 程序計數器(Program Counter Register)是一塊較小的內存空間，它能夠看做是當前線程所執行的字節碼的行號指示器。在虛擬機的概念模型中，字節碼解釋器工做時就是經過改變計數器的值選取下一條須要執行的字節碼指令，分支、循環、跳轉、異常處理、線程恢復等基礎功能都須要依賴程序計數器來完成。

​ 因爲Java虛擬機的多線程是經過線程輪流切換並分配處理器執行時間的方式來實現的，在任何一個肯定的時刻，一個處理器（對於多核處理器來講是一個內核）都只會執行一條線程中的指令。所以，爲了線程切換後能恢復到正確的執行位置，每條線程都須要有一個獨立的程序計數器，各線程的程序計數器相互獨立，互不影響，獨立存儲。咱們稱這類內存區域爲==「線程私有」==的內存。

​ 若是線程正在執行一個Java方法,這個計數器記錄的是正在執行的虛擬機字節碼指令的地址;若是執行的是本地方法(native method),這個計數器值爲空(undefined)。此內存區域是惟一一個在Java虛擬機規範中沒有規定任何OutOfMemoryError狀況的區域。

2.Java虛擬機棧

​ 與程序計數器同樣，Java虛擬機棧（Java Virtual Machine Stacks）也是線程私有的，它的生命週期與線程相同。虛擬機棧描述的是Java方法執行的內存模型：每一個方法在執行的同時都會建立一個棧幀（Stack Frame）用於存儲局部變量表、操做數棧、動態連接、方法出口等信息。每個方法從調用直至完成的過程，都對應一個棧幀在虛擬機棧中入棧到出棧（壓棧到彈棧）的過程。

​ 咱們常說的堆內存（Heap）和棧內存（Stack），這種分法比較粗糙，Java內存區域的劃分遠比這複雜。這種劃分只能說明大多數程序員最關注的的、與對象內存分配關係最密切的內存區域是這兩塊。其中的「棧」就是虛擬機棧，或者說是虛擬機棧中局部變量表部分。

​ 局部變量表中存放了編譯期可知的各類基本數據類型、對象引用（reference類型，它不等同於對象自己，多是一個指向對象的起始地址的引用指針，也多是指向一個表明對象的句柄或其餘與此對象相關的位置）和returnAddress類型（指向一條字節碼指令的地址）。

​ 64位長度（8個字節）的long和double類型數據會佔用2個局部變量空間（slot），其他的數據類型只佔用1個局部變量空間（4個字節）。局部變量表所需的內存空間在編譯期完成分配，當進入一個方法時，這個方法須要在幀中分配多大的局部變量空間是徹底肯定的，在方法運行期間不會改變局部變量表的大小。

​ Java虛擬機規範對這個區域規定了兩種異常：線程請求的棧深度大於虛擬機所容許的深度，將拋出StackOverflowError；若是虛擬機棧能夠動態擴展，若是擴展時沒法申請到足夠的內存，就會拋出OutOfMemoryError。

3.本地方法棧

​ 本地方法棧（Native Method Stack）與虛擬機棧發揮的做用很是類似，它們之間的區別僅僅是虛擬機棧爲虛擬機執行Java方法（字節碼）服務，而本地方法棧則爲虛擬機執行用到的本地（Native）方法。在虛擬機規範中對本地方法棧中方法使用的語言、使用方式和數據結構沒有強制規定，所以虛擬機能夠自由實現。Sun HotSpot虛擬機直接把本地方法棧和虛擬機棧合二爲一。與虛擬機棧同樣，本地方法棧也會拋出StackOverflowError和OutOfMemoryError異常。

4.Java堆

​ 對大多數應用來講，Java堆（Java Heap）是虛擬機管理內存中最大的一塊。Java堆是被全部線程共享的一塊內存區域，在虛擬機啓動時建立。此內存區域的惟一目的就是存放對象實例，幾乎全部的對象實例都在堆區進行分配內存。Java虛擬機規範中的描述是：全部的對象實例以及數組都在堆上分配。可是隨着JIT編譯期的發展和逃逸分析技術逐漸成熟，棧上分配、標量替換優化技術將會致使一些變化發生，全部的對象都分配在堆上也不那麼「絕對」了。

​ Java堆是垃圾收集器管理的主要區域，所以不少時候也被稱做「GC堆」（Garbage Collected Heap）。從內存回收的角度來看，因爲如今收集器基本都採用分代收集算法，因此Java堆中還能夠細分爲：新生代和老年代；再細緻一點的有Eden空間、From Survivor空間、To Survivor空間等。從內存分配的角度來看，線程共享的堆中可能劃分出多個線程私有的分配緩衝區（Thread Local Allocation Buffer，TLAB）。但不管如何劃分，都與存放內容無關，不管哪一個區域,儲存的都還是對象實例，進一步的劃分是爲了更好的回收內存。

​ 根據Java虛擬機規範的規定，Java堆能夠處於物理上不連續的內存空間中，只要邏輯上連續便可。若是堆中沒有內存完成實例分配，而且堆也沒法再擴展時，將會拋出OutOfMemoryError異常。

5.方法區

​ 方法區（Method Area）與堆同樣，是線程共享的內存區域，它用於存儲已被虛擬機加載的類信息、常量、靜態變量、即時編譯器編譯後的代碼等數據。雖然Java虛擬機把它描述爲一個邏輯部分，但它卻有一個別名叫Non-Heap（非堆），目的是與Java堆區分開。

​ HotSpot虛擬機上開發、部署程序的開發者，習慣於把方法區稱爲「永久代」（Permanent Generation），本質上二者並不等價，僅僅由於HotSpot虛擬機團隊選擇把GC分代收集擴展至方法區，或者使用永久代來實現方法區而已，這樣HotSpot的垃圾收集器能夠像管理Java堆同樣管理這部分的內存空間。可以省去專門爲方法區編寫內存管理代碼的工做。其餘虛擬機中是不存在永久代這個概念的。並且，使用永久代來實現方法區，如今看來並非一個好主意，由於永久代的內存空間很小，這樣很容易內存溢出。所以，JDK1.7中已經把本來放在永久代的字符串常量池移出，放到了堆區。而在JDK1.8中，則用元空間完全取代了永久代。

​ Java虛擬機規範對方法區的限制很是寬鬆，除了和堆同樣不須要連續的物理內存和能夠選擇固定大小或可擴展外，還能夠選擇不實現垃圾收集。相對而言，垃圾收集在這個區域比較少出現，但並不是數據真的永久存在,這個區域的內存回收主要是針對常量池的回收和對類型的卸載。

​ Java虛擬機規範規定，當方法區沒法知足內存分配需求時，拋出OutOfMemoryError異常。

6.運行時常量池

​ 運行時常量池（Runtime Constant Pool）是方法區的一部分。Class文件中除了有類的元數據（版本、字段、方法、接口等描述信息），還有一項是常量池（Constant Pool Table），用於存放編譯期生成的各類字面量和符號引用，這部份內容將在類加載之後進入方法區的運行時常量池中存放。

​ Java虛擬機對Class文件每一部分的格式都有嚴格規定，每個字節用於存儲哪一種數據都必須符合規範上的要求才會被虛擬機任何、裝載和執行，但對於運行時常量池，Java虛擬機規範沒有作任何細節的要求，不一樣的提供商實現的虛擬機能夠按照本身的須要來實現這個內存區域。不過通常來講，除了保存Class文件中描述的符號引用外，還會把翻譯出來的直接引用也存儲在運行時常量池中。

​ 運行時常量池相對於Class文件常量池的另一個重要特徵是具有動態性，Java語言並不要求常量必定只有編譯期才能產生，也就是並不是預置入Class文件中常量池的內容才能進入方法區運行時常量池，運行期間也可能將新的常量放入池中，好比String類的intern()方法。

​ 運行時常量池是方法區的一部分，因此受到方法區內存的限制，當常量池沒法再申請到內存會拋出OutOfMemoryError異常。

7.直接內存

​ 直接內存（Direct Memory）並非虛擬機運行時數據區的一部分，也不是Java虛擬機規範中定義的內存區域。可是這部份內存也被頻繁的使用，並且也可能致使OutOfMemoryError異常。

​ JDK1.4新增了NIO(New Input/Output)類，引入了一種基於通道（Channel）和緩衝區（Buffer）的I/O方式，它可使用Native函數庫直接分配堆外內存，而後經過一個存儲在堆中的DirectByteBuffer對象做爲這塊內存的引用進行操做。這樣能在一些場景中顯著提高性能，避免了在Java堆和Native堆中來回複製數據。

​ 直接內存會受到本機總內存大小以及處理器尋址空間的限制。配置虛擬機參數時若是忽略直接內存，使得各個內存區域總和大於物理內存限制，動態擴展時可能會出現OutOfMemoryError異常。