一JVM結構

1 Java記憶體結構

JVM記憶體結構主要有三大塊：堆記憶體、方法區和棧。

堆記憶體是JVM中最大的一塊由年輕代和老年代組成，而年輕代記憶體又被分成三部分，Eden空間、From Survivor空間、To Survivor空間,預設情況下年輕代按照8:1:1的比例來分配；

方法區儲存類資訊、常量、靜態變數等資料，是執行緒共享的區域，為與Java堆區分，方法區還有一個別名Non-Heap(非堆)；

棧又分為java虛擬機器棧和本地方法棧主要用於方法的執行。

2 各區域記憶體大小

3 控制引數

-Xms設定堆的最小空間大小。

-Xmx設定堆的最大空間大小。

-XX:NewSize設定新生代最小空間大小。

-XX:MaxNewSize設定新生代最大空間大小。

-XX:PermSize設定永久代最小空間大小。

-XX:MaxPermSize設定永久代最大空間大小。

-Xss設定每個執行緒的堆疊大小。

沒有直接設定老年代的引數，但是可以設定堆空間大小和新生代空間大小兩個引數來間接控制。

老年代空間大小=堆空間大小-年輕代大空間大小

4 JVM和系統呼叫間的關係

方法區和堆是所有執行緒共享的記憶體區域；而java棧、本地方法棧和程式設計師計數器是執行是執行緒私有的記憶體區域。

二JVM各區域的作用

1 Java堆

對於大多數應用來說，Java堆（Java Heap）是Java虛擬機器所管理的記憶體中最大的一塊。Java堆是被所有執行緒共享的一塊記憶體區域，在虛擬機器啟動時建立。此記憶體區域的唯一目的就是存放物件例項，幾乎所有的物件例項都在這裡分配記憶體。

Java堆是垃圾收集器管理的主要區域，因此很多時候也被稱做“GC堆”。如果從記憶體回收的角度看，由於現在收集器基本都是採用的分代收集演算法，所以Java堆中還可以細分為：新生代和老年代；再細緻一點的有Eden空間、From Survivor空間、To Survivor空間等。

根據Java虛擬機器規範的規定，Java堆可以處於物理上不連續的記憶體空間中，只要邏輯上是連續的即可，就像我們的磁碟空間一樣。在實現時，既可以實現成固定大小的，也可以是可擴充套件的，不過當前主流的虛擬機器都是按照可擴充套件來實現的（通過-Xmx和-Xms控制）。

如果在堆中沒有記憶體完成例項分配，並且堆也無法再擴充套件時，將會丟擲OutOfMemoryError異常。

2 方法區

方法區（Method Area）與Java堆一樣，是各個執行緒共享的記憶體區域，它用於儲存已被虛擬機器載入的類資訊、常量、靜態變數、即時編譯器編譯後的程式碼等資料。雖然Java虛擬機器規範把方法區描述為堆的一個邏輯部分，但是它卻有一個別名叫做Non-Heap（非堆），目的應該是與Java堆區分開來。

對於習慣在HotSpot虛擬機器上開發和部署程式的開發者來說，很多人願意把方法區稱為“永久代”（Permanent Generation），本質上兩者並不等價，僅僅是因為HotSpot虛擬機器的設計團隊選擇把GC分代收集擴充套件至方法區，或者說使用永久代來實現方法區而已。

Java虛擬機器規範對這個區域的限制非常寬鬆，除了和Java堆一樣不需要連續的記憶體和可以選擇固定大小或者可擴充套件外，還可以選擇不實現垃圾收集。相對而言，垃圾收集行為在這個區域是比較少出現的，但並非資料進入了方法區就如永久代的名字一樣“永久”存在了。這個區域的記憶體回收目標主要是針對常量池的回收和對型別的解除安裝，一般來說這個區域的回收“成績”比較難以令人滿意，尤其是型別的解除安裝，條件相當苛刻，但是這部分割槽域的回收確實是有必要的。

根據Java虛擬機器規範的規定，當方法區無法滿足記憶體分配需求時，將丟擲OutOfMemoryError異常。

3 程式計數器

程式計數器（Program Counter Register）是一塊較小的記憶體空間，它的作用可以看做是當前執行緒所執行的位元組碼的行號指示器。在虛擬機器的概念模型裡（僅是概念模型，各種虛擬機器可能會通過一些更高效的方式去實現），位元組碼直譯器工作時就是通過改變這個計數器的值來選取下一條需要執行的位元組碼指令，分支、迴圈、跳轉、異常處理、執行緒恢復等基礎功能都需要依賴這個計數器來完成。
由於Java虛擬機器的多執行緒是通過執行緒輪流切換並分配處理器執行時間的方式來實現的，在任何一個確定的時刻，一個處理器（對於多核處理器來說是一個核心）只會執行一條執行緒中的指令。因此，為了執行緒切換後能恢復到正確的執行位置，每條執行緒都需要有一個獨立的程式計數器，各條執行緒之間的計數器互不影響，獨立儲存，我們稱這類記憶體區域為“執行緒私有”的記憶體。
如果執行緒正在執行的是一個Java方法，這個計數器記錄的是正在執行的虛擬機器位元組碼指令的地址；如果正在執行的是Natvie方法，這個計數器值則為空（Undefined）。

此記憶體區域是唯一一個在Java虛擬機器規範中沒有規定任何OutOfMemoryError情況的區域。

4 VM棧

與程式計數器一樣，Java虛擬機器棧（Java Virtual Machine Stacks）也是執行緒私有的，它的生命週期與執行緒相同。虛擬機器棧描述的是Java方法執行的記憶體模型：每個方法被執行的時候都會同時建立一個棧幀（Stack Frame）用於儲存區域性變量表、操作棧、動態連結、方法出口等資訊。每一個方法被呼叫直至執行完成的過程，就對應著一個棧幀在虛擬機器棧中從入棧到出棧的過程。

區域性變量表存放了編譯期可知的各種基本資料型別（boolean、byte、char、short、int、float、long、double）、物件引用（reference型別，它不等同於物件本身，根據不同的虛擬機器實現，它可能是一個指向物件起始地址的引用指標，也可能指向一個代表物件的控制代碼或者其他與此物件相關的位置）和returnAddress型別（指向了一條位元組碼指令的地址）。

其中64位長度的long和double型別的資料會佔用2個區域性變數空間（Slot），其餘的資料型別只佔用1個。區域性變量表所需的記憶體空間在編譯期間完成分配，當進入一個方法時，這個方法需要在幀中分配多大的區域性變數空間是完全確定的，在方法執行期間不會改變區域性變量表的大小。

在Java虛擬機器規範中，對這個區域規定了兩種異常狀況：如果執行緒請求的棧深度大於虛擬機器所允許的深度，將丟擲StackOverflowError異常；如果虛擬機器棧可以動態擴充套件（當前大部分的Java虛擬機器都可動態擴充套件，只不過Java虛擬機器規範中也允許固定長度的虛擬機器棧），當擴充套件時無法申請到足夠的記憶體時會丟擲OutOfMemoryError異常。

5 本地方法棧

本地方法棧（Native Method Stacks）與虛擬機器棧所發揮的作用是非常相似的，其區別不過是虛擬機器棧為虛擬機器執行Java方法（也就是位元組碼）服務，而本地方法棧則是為虛擬機器使用到的Native方法服務。虛擬機器規範中對本地方法棧中的方法使用的語言、使用方式與資料結構並沒有強制規定，因此具體的虛擬機器可以自由實現它。甚至有的虛擬機器（譬如Sun HotSpot虛擬機器）直接就把本地方法棧和虛擬機器棧合二為一。與虛擬機器棧一樣，本地方法棧區域也會丟擲StackOverflowError和OutOfMemoryError異常。

三、GC概述

垃圾收集 Garbage Collection 通常被稱為“GC”，它誕生於1960年 MIT 的 Lisp 語言，經過半個多世紀，目前已經十分成熟了。

jvm中，程式計數器、虛擬機器棧、本地方法棧都是隨執行緒而生隨執行緒而滅，棧幀隨著方法的進入和退出做入棧和出棧操作，實現了自動的記憶體清理，因此，我們的記憶體垃圾回收主要集中於 java 堆和方法區中，在程式執行期間，這部分記憶體的分配和使用都是動態的。

3.1GC是什麼

GC其實是一種自動的記憶體管理工具，其行為主要包括2步

• 在Java堆中，為新建立的物件分配空間
• 在Java堆中，回收沒用的物件佔用的空間

3.2為什麼需要GC

釋放開發人員的生產力

3.3為什麼需要多種GC

首先，Java平臺被部署在各種各樣的硬體資源上，其次，在Java平臺上部署和執行著各種各樣的應用，並且使用者對不同的應用的效能指標(吞吐率和延遲) 預期也不同，為了滿足不同應用的對記憶體管理的不同需求，JVM提供了多種GC以供選擇

效能指標

• 最大停頓時長：垃圾回收導致的應用停頓時間的最大值
• 吞吐率：垃圾回收停頓時長和應用執行總時長的比例

不同的GC能滿足不同應用不同的效能需求，現有的GC包括：

• 序列化GC(serial garbage collector)：適合佔用記憶體少的應用
• 並行GC 或 吞吐率GC(parallel or throughput garbage collector)：適合佔用記憶體較多，多CPU，追求高吞吐率的應用
• 併發GC：適合佔用記憶體較多，多CPU的應用，對延遲有要求的應用

3.4物件存活的判斷

判斷物件是否存活一般有兩種方式：

引用計數：每個物件有一個引用計數屬性，新增一個引用時計數加1，引用釋放時計數減1，計數為0時可以回收。此方法簡單，缺點是無法解決物件相互迴圈引用的問題。

可達性分析（Reachability Analysis）：從GC Roots開始向下搜尋，搜尋所走過的路徑稱為引用鏈。當一個物件到GC Roots沒有任何引用鏈相連時，則證明此物件是不可用的。不可達物件。

在Java語言中，GC Roots包括：

虛擬機器棧中引用的物件。

方法區中類靜態屬性實體引用的物件。

方法區中常量引用的物件。

本地方法棧中JNI引用的物件。

由於迴圈引用的問題，一般採用跟蹤（可達性分析）方法

四、垃圾回收演算法

4.1 標記 -清除演算法

“標記-清除”（Mark-Sweep）演算法，如它的名字一樣，演算法分為“標記”和“清除”兩個階段：首先標記出所有需要回收的物件，在標記完成後統一回收掉所有被標記的物件。之所以說它是最基礎的收集演算法，是因為後續的收集演算法都是基於這種思路並對其缺點進行改進而得到的。

它的主要缺點有兩個：一個是效率問題，標記和清除過程的效率都不高；另外一個是空間問題，標記清除之後會產生大量不連續的記憶體碎片，空間碎片太多可能會導致，當程式在以後的執行過程中需要分配較大物件時無法找到足夠的連續記憶體而不得不提前觸發另一次垃圾收集動作。

4.2 複製演算法

“複製”（Copying）的收集演算法，它將可用記憶體按容量劃分為大小相等的兩塊，每次只使用其中的一塊。當這一塊的記憶體用完了，就將還存活著的物件複製到另外一塊上面，然後再把已使用過的記憶體空間一次清理掉。

這樣使得每次都是對其中的一塊進行記憶體回收，記憶體分配時也就不用考慮記憶體碎片等複雜情況，只要移動堆頂指標，按順序分配記憶體即可，實現簡單，執行高效。只是這種演算法的代價是將記憶體縮小為原來的一半，持續複製長生存期的物件則導致效率降低。

4.3 標記-整理演算法

複製收集演算法在物件存活率較高時就要執行較多的複製操作，效率將會變低。更關鍵的是，如果不想浪費50%的空間，就需要有額外的空間進行分配擔保，以應對被使用的記憶體中所有物件都100%存活的極端情況，所以在老年代一般不能直接選用這種演算法。

根據老年代的特點，有人提出了另外一種“標記-整理”（Mark-Compact）演算法，標記過程仍然與“標記-清除”演算法一樣，但後續步驟不是直接對可回收物件進行清理，而是讓所有存活的物件都向一端移動，然後直接清理掉端邊界以外的記憶體

4.4 分代收集演算法

分代收集法是目前大部分JVM所採用的方法，其核心思想是根據物件存活的不同生命週期將記憶體劃分為不同的域，一般情況下將GC堆劃分為老生代(Tenured/Old Generation)和新生代(Young Generation)。老生代的特點是每次垃圾回收時只有少量物件需要被回收，新生代的特點是每次垃圾回收時都有大量垃圾需要被回收，因此可以根據不同區域選擇不同的演算法。

目前大部分JVM的GC對於新生代都採取Copying演算法，因為新生代中每次垃圾回收都要回收大部分物件，即要複製的操作比較少，但通常並不是按照1：1來劃分新生代。一般將新生代劃分為一塊較大的Eden空間和兩個較小的Survivor空間(From Space, To Space)，每次使用Eden空間和其中的一塊Survivor空間，當進行回收時，將該兩塊空間中還存活的物件複製到另一塊Survivor空間中。

而老生代因為每次只回收少量物件，因而採用Mark-Compact演算法。

物件的記憶體分配主要在新生代的Eden Space和Survivor Space的From Space(Survivor目前存放物件的那一塊)，少數情況會直接分配到老生代。當新生代的Eden Space和From Space空間不足時就會發生一次GC，進行GC後，Eden Space和From Space區的存活物件會被挪到To Space，然後將Eden Space和From Space進行清理。如果To Space無法足夠儲存某個物件，則將這個物件儲存到老生代。在進行GC後，使用的便是Eden Space和To Space了，如此反覆迴圈。當物件在Survivor區躲過一次GC後，其年齡就會+1。預設情況下年齡到達15的物件會被移到老生代中。

五、垃圾收集器

如果說收集演算法是記憶體回收的方法論，垃圾收集器就是記憶體回收的具體實現，不同廠商、不同版本的虛擬機器實現差別很大，HotSpot中包含的收集器如下：

5.1 Serial收集器

序列收集器是最古老，最穩定以及效率高的收集器，可能會產生較長的停頓，只使用一個執行緒去回收。新生代、老年代使用序列回收；新生代複製演算法、老年代標記-壓縮；垃圾收集的過程中會Stop The World（服務暫停）

引數控制：-XX:+UseSerialGC序列收集器

5.2 ParNew收集器

ParNew收集器其實就是Serial收集器的多執行緒版本。新生代並行，老年代序列；新生代複製演算法、老年代標記-壓縮

引數控制：-XX:+UseParNewGCParNew收集器

-XX:ParallelGCThreads限制執行緒數量

5.3 Parallel收集器

Parallel Scavenge收集器類似ParNew收集器，Parallel收集器更關注系統的吞吐量。可以通過引數來開啟自適應調節策略，虛擬機器會根據當前系統的執行情況收集效能監控資訊，動態調整這些引數以提供最合適的停頓時間或最大的吞吐量；也可以通過引數控制GC的時間不大於多少毫秒或者比例；新生代複製演算法、老年代標記-壓縮

引數控制：-XX:+UseParallelGC使用Parallel收集器+ 老年代序列

5.4 CMS收集器

CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時間為目標的收集器。目前很大一部分的Java應用都集中在網際網路站或B/S系統的服務端上，這類應用尤其重視服務的響應速度，希望系統停頓時間最短，以給使用者帶來較好的體驗。

從名字（包含“Mark Sweep”）上就可以看出CMS收集器是基於“標記-清除”演算法實現的，它的運作過程相對於前面幾種收集器來說要更復雜一些，整個過程分為4個步驟，包括：

初始標記（CMS initial mark）

併發標記（CMS concurrent mark）

重新標記（CMS remark）

併發清除（CMS concurrent sweep）

其中初始標記、重新標記這兩個步驟仍然需要“Stop The World”。初始標記僅僅只是標記一下GC Roots能直接關聯到的物件，速度很快，併發標記階段就是進行GC Roots Tracing的過程，而重新標記階段則是為了修正併發標記期間，因使用者程式繼續運作而導致標記產生變動的那一部分物件的標記記錄，這個階段的停頓時間一般會比初始標記階段稍長一些，但遠比並發標記的時間短。
由於整個過程中耗時最長的併發標記和併發清除過程中，收集器執行緒都可以與使用者執行緒一起工作，所以總體上來說，CMS收集器的記憶體回收過程是與使用者執行緒一起併發地執行。老年代收集器（新生代使用ParNew）

優點:併發收集、低停頓

缺點：產生大量空間碎片、併發階段會降低吞吐量

引數控制：-XX:+UseConcMarkSweepGC使用CMS收集器

-XX:+ UseCMSCompactAtFullCollectionFullGC後，進行一次碎片整理；整理過程是獨佔的，會引起停頓時間變長

-XX:+CMSFullGCsBeforeCompaction設定進行幾次Full GC後，進行一次碎片整理

-XX:ParallelCMSThreads設定CMS的執行緒數量（一般情況約等於可用CPU數量）

5.5 G1收集器

G1是目前技術發展的最前沿成果之一，HotSpot開發團隊賦予它的使命是未來可以替換掉JDK1.5中釋出的CMS收集器。與CMS收集器相比G1收集器有以下特點：

1.空間整合，G1收集器採用標記整理演算法，不會產生記憶體空間碎片。分配大物件時不會因為無法找到連續空間而提前觸發下一次GC。

2.可預測停頓，這是G1的另一大優勢，降低停頓時間是G1和CMS的共同關注點，但G1除了追求低停頓外，還能建立可預測的停頓時間模型，能讓使用者明確指定在一個長度為N毫秒的時間片段內，消耗在垃圾收集上的時間不得超過N毫秒，這幾乎已經是實時Java（RTSJ）的垃圾收集器的特徵了。

上面提到的垃圾收集器，收集的範圍都是整個新生代或者老年代，而G1不再是這樣。使用G1收集器時，Java堆的記憶體佈局與其他收集器有很大差別，它將整個Java堆劃分為多個大小相等的獨立區域（Region），雖然還保留有新生代和老年代的概念，但新生代和老年代不再是物理隔閡了，它們都是一部分（可以不連續）Region的集合。

G1對Heap的劃分

G1的新生代收集跟ParNew類似，當新生代佔用達到一定比例的時候，開始出發收集。和CMS類似，G1收集器收集老年代物件會有短暫停頓。

收集步驟

1、標記階段，首先初始標記(Initial-Mark),這個階段是停頓的(Stop the World Event)，並且會觸發一次普通Mintor GC。對應GC log:GC pause (young) (inital-mark)

2、Root Region Scanning，程式執行過程中會回收survivor區(存活到老年代)，這一過程必須在young GC之前完成。

3、Concurrent Marking，在整個堆中進行併發標記(和應用程式併發執行)，此過程可能被young GC中斷。在併發標記階段，若發現區域物件中的所有物件都是垃圾，那個這個區域會被立即回收(圖中打X)。同時，併發標記過程中，會計算每個區域的物件活性(區域中存活物件的比例)。

4、Remark, 再標記，會有短暫停頓(STW)。再標記階段是用來收集 併發標記階段 產生新的垃圾(併發階段和應用程式一同執行)；G1中採用了比CMS更快的初始快照演算法:snapshot-at-the-beginning (SATB)。

5、Copy/Clean up，多執行緒清除失活物件，會有STW。G1將回收區域的存活物件拷貝到新區域，清除Remember Sets，併發清空回收區域並把它返回到空閒區域連結串列中。

6、複製/清除過程後。回收區域的活性物件已經被集中回收到深藍色和深綠色區域。

六、常用的收集器組合