jvm虛拟機運作時記憶體分析，堆，棧，方法區，程式計數器，本地棧，常量池

**

JVM自動記憶體管理機制

**

java記憶體區域與記憶體溢出異常

概述 ： 對于從事C/C++程式開發的開發人員來說，在記憶體管理領域他們是擁有最高權力的皇帝又是從事最基礎工作的勞動人民，即擁有每一個對象的所有權，有擔負這每一個對象生命的開始到結束的維護責任。

對于java程式員來說，在虛拟機自動記憶體管理機制的幫助下，不在需要為每一個new操作去寫配對的delete/free代碼，不容易出現記憶體洩漏和記憶體溢出的問題，由虛拟機管理記憶體這一切看起來非常美好，但是一旦出現記憶體溢出或者記憶體洩漏的問題，對于不熟悉jvm虛拟機是怎麼使用記憶體的話，那麼排查錯誤将會是一項非常艱巨的任務。

2.2 運作時資料區域

運作時資料區怎麼了解？

JVM運作時首先需要類加載器（classLoader）加載所需類的位元組碼檔案。加載完畢交由執行引擎執行，在執行過程中需要一段空間來存儲資料（類比CPU與主存）。這段記憶體空間的配置設定和釋放過程正是我們需要關心的運作時資料區。

運作時資料區

運作時資料區都包括，程式計數器，方法區（包含常量池），虛拟機棧，本地方法棧，堆 。 JVM本身就是一台虛拟的計算機，目的是為了實作一次編譯處處執行。

程式計數器

程式計數器是一塊較小的記憶體空間。他可以看做是目前線程所執行的位元組碼行号訓示器。位元組碼解釋器工作就是通過改變這個計數器的值來選擇下一條需要執行的位元組碼指令。分支，循環，跳轉，異常，線程恢複等基礎功能都需要依賴這個計數器來完成。

由于JVM虛拟機的多線程是通過線程輪流切換并配置設定處理器執行時間的方式實作的，在任何一個确定的時刻，一個處理器（對于多核處理器來說是一個核心）都隻會執行一條線程中的指令。當切換到另外一條線程時，若不儲存目前未執行完線程的執行位置，下次處理機再執行這條線程時，又要重新開始執行。這種情況顯然是不能容忍的。是以，為了線程切換後能正确的恢複到執行位置，每條線程都需要有一個獨立的程式計數器，各條線程之間計數器互不影響，獨立存儲，我們稱這類記憶體區域為‘線程私有’記憶體，

如果線程正在執行的是一個java方法，這個計數器記錄的是正在執行的虛拟機位元組碼指令的位址，如果正在執行的是native方法，這個計數器則為（undefined）,此記憶體區域是為一個在java虛拟機規範中沒有規定任何OutOfMemoryError情況的區域

java虛拟機棧

與程式計數器一樣java虛拟機也是線程私有的，他的生命周期與線程相同，虛拟機棧描述的是java方法執行的記憶體模型：每個方法在執行的同時都會建立一個棧幀（Stack Frame，可以這麼了解棧幀，虛拟機棧包含N個棧幀每個棧幀包含局部變量表,操作數棧，動态連結，方法出口等資訊）。每個方法從調用到執行完成這個過程，就對應這一個棧幀在虛拟機棧中的入棧到出棧的過程。

經常有人将java記憶體分為堆，棧記憶體，這其實是很粗糙的，java記憶體的劃分遠比這複雜。隻能說明傳統的程式員最關注的，與對象記憶體配置設定關系最密切的就是這兩塊記憶體堆，棧。棧就是現在說的虛拟機棧，或者說是虛拟機棧中棧幀的局部變量表部分。

局部變量表存放了編譯期可知的各種基本資料類型（boolean,byte,char,short,int,float,long,double），對象引用（reference類型，他不等同于對象本身，可能是一個指向對象起始位址的引用指針，也可能是指向一個代表對象的句柄或其他與此相關的位置）和returnAddress類型（指向了一條位元組碼指令的位址）

其中64位長度的long和double類型會占用2個局部變量空間，其餘的資料類型隻會占用1個局部變量空間。局部變量表所需的記憶體空間在編譯期間完成記憶體配置設定，當進入一個方法時，這個方法需要在幀中配置設定多大的記憶體空間是完全确定的，在方法運作期間不會改變局部變量表的大小。

在java虛拟機規範中，對這個區域規定了兩種異常狀态：如果線程請求的棧的深度大于虛拟機允許的深度，将抛出StackOverFlowError異常（棧溢出），如果虛拟機棧可以動态擴充（現在大部分java虛拟機都可以動态擴充，隻不過java虛拟機規範中也允許固定長度的java虛拟機棧），如果擴充時無法申請到足夠的記憶體空間，就會抛出OutOfmMemoryError異常（沒有足夠的記憶體）

本地方法棧

本地方法棧（Native Method Stacks）與虛拟機棧所發揮的作用是非常相似的，他們之間的差別不過是虛拟機棧為虛拟機執行java方法（也就是位元組碼）服務，而本地方法棧則為虛拟機使用到的本地Native方法服務，在虛拟機規範中對本地方法棧中的使用方法，語言，與資料結構并沒有強制規定，是以具體的虛拟機可以自由實作它。甚至有的虛拟機（例如Sun HotSpot虛拟機）直接就把本地方法棧和虛拟機棧合二為一。與虛拟機棧一樣本地方法棧也會抛出StackOverFlowError和OutOfmMemoryError異常

java堆

對于大多數應用來說，java堆（java Heap）是java虛拟機管理記憶體中的最大一塊。java堆是所有線程共享的一塊記憶體管理區域，在虛拟機啟動時建立。此記憶體區域唯一目的就是存放對象的執行個體。幾乎所有對象執行個體都在堆中配置設定記憶體。這一點在java虛拟機規範中的描述是：所有對象執行個體以及數組都要在堆上配置設定，但是随着JIT編譯器的發展與逃逸技術逐漸成熟，棧上配置設定，标量替換優化技術将會導緻一些微妙的變化發生，所有的對象都配置設定在堆上也不是變的那麼“絕對”了。

java堆是垃圾回收器管理的主要區域，是以很多時候也被稱為GC堆（Garbage Collected Heap）。從記憶體回收的角度來看，由于現在收集器基本都采用分代收集算法，是以java堆中還可以細分為：新生代和年老代：在細緻一點的劃分可以分為：Eden空間，From Survivor空間，To Survivor空間等。從記憶體配置設定的角度來看，線程共享的java堆中可能劃分出多個線程私有的配置設定緩沖區 ，不過無論如何劃分，都與存放内容無關，無論哪個區域存放的都是對象執行個體。進一步劃分的目的是為了更好的回收記憶體，或者更快的配置設定記憶體。

根據java虛拟機規範的規定，java堆可以處在實體上不連續的記憶體空間，隻要邏輯上是連續的即可，就像我們的磁盤空間一樣。在實作上既可以實作成固定大小，也可以是可擴充的大小，不過目前主流的虛拟機都是按照可擴充來實作的（通過-Xmx和-Xms控制）。如果在堆中沒有記憶體執行個體完成配置設定，并且堆也無法在擴充時将會抛出OutOfMemoryError異常。

方法區

方法區和java堆一樣，是各個線程共享的記憶體區域，他用于存儲已被虛拟機加載的類資訊，常量，靜态變量，即時編譯器編譯後的代碼等資料。雖然java虛拟機規範把方法區描述為堆的一部分，但是他還有個别名叫做Non-heap（非堆），目的應該是與java堆區分開來。

java虛拟機規範對方法區的限制非常寬松，除了和java堆一樣不需要連續的記憶體和可以選擇固定大小或者可擴充外，還可以選擇不實作垃圾收集。相對而言，垃圾收集在這個區域是比較少出現的，但并非資料進入了方法區就如永久代的名字一樣永久存在了。這區域的記憶體回收目标重要是針對常量池的回收和類型的解除安裝，一般來說這個記憶體區域的回收‘成績’比較難以令人滿意。尤其是類型的解除安裝條件非常苛刻，但是這部分的回收确實是必要的。在sun公司的bug清單中，曾出現過的若幹個嚴重的bug就是由于低版本的HotSpot虛拟機對此區域未完成回收導緻的記憶體溢出。

這裡有三個概念需要清楚

1 常量池（Constant Pool）： 常量池資料編譯器被确定，是class檔案中的一部分，存儲了類，方法，接口等中的常量，當然也包括字元串常量。

常量池：可以了解為Class檔案之中的資源倉庫，它是Class檔案結構中與其他項目資源關聯最多的資料類型

常量池中主要存放兩大類常量：字面量（Literal）和符号引用（Symbolic Reference）。

字面量：文本字元串、聲明為final的常量值等；

符号引用：類和接口的完全限定名（Fully Qualified Name）、字段的名稱和描述符（Descriptor）、方法的名稱和描述符

2 字元串池/字元串常量池（String Pool/String Constant Pool）：是常量池中的一部分，存儲了編譯器産生的字元串類型資料

3 運作時常量池（Runtime Constant Pool）: 方法區的一部分，所有線程共享。虛拟機加載class檔案後把常量池中的資料存放到運作時常量池中

這裡需要注重提一下在JDK1.6之前字元串常量池是存在于方法區之中，在JDK1.7和以上字元串常量池存在了堆之中。

這是官網翻譯後的中文說明：在JDK 7中，在Java堆的永久生成中不再配置設定interned字元串，而是在Java堆的主要部分(稱為young和old generation)中配置設定，以及應用程式建立的其他對象。此更改将導緻更多的資料駐留在主Java堆中，而在永久生成中資料更少，是以可能需要調整堆大小。由于這種變化，大多數應用程式在堆使用上隻會看到相對較小的差異，但是更大的應用程式加載了許多類，或者大量使用了string . intern()方法将看到更顯著的差異。如果還有疑問可進行測試，測試參考http://blog.csdn.net/u014039577/article/details/50377805

直接記憶體

直接記憶體并不是虛拟機運作記憶體的一部分，也不是java虛拟機規範中定義的記憶體區域。但是這部分記憶體區域也被頻繁的使用，也可能導緻OutOfMemoryError異常出現，

在jdk1.4中新加入了NIO（New Input/Output）類，引入了一種基于通道（Channel）和緩沖區（Buffer）的I/O方式，他可以使用本地的函數庫直接配置設定堆外記憶體，然後通過一個存儲在java堆中的DirectByteBuffer對象作為這塊記憶體的引用進行操作，這樣能在一些場景中顯著提高性能，因為避免了在java堆中和Native堆中來回複制資料。

顯然本機直接記憶體的配置設定不會受到java堆大小的限制，但是既然是記憶體。肯定還會受到本機總記憶體的限制。伺服器管理者在配置虛拟機記憶體參數時，會根據實際記憶體設定-Xmx等參數資訊。但經常忽略直接記憶體，使得各個記憶體區域總和大于實體記憶體限制（包括實體和作業系統級的限制），進而導緻動态擴充時OutOfMemoryError異常。