Java記憶體模型-（2）
這裡主要從JVM記憶體結構和GC角度講解。
一、記憶體結構
主體結構
-
堆（heap） ：執行緒共享，所有的物件例項、陣列都要在堆上分配，是回收器主要管理的物件。
-
方法區（MEATHOD AREA） ：執行緒共享，儲存類資訊、常量、靜態變數、即時編譯器編譯後的程式碼。
-
方法棧（JVM Stack） ：執行緒私有，儲存區域性變量表、操作棧、動態連結、方法出口，物件指標。
-
本地方法棧（NATIVE METHOD STACK） ：執行緒私有，為虛擬機器使用到的Native 方法服務。如Java使用c或者c++編寫的介面服務時，程式碼在此區執行。
-
PC暫存器（PC Register） ：執行緒私有，指向下一條要執行的指令。
各區域詳細說明
Java記憶體結構中我們主要關心的是堆和方法區。
堆
|
堆介紹 |
作用 |
存放物件例項和陣列，是各個執行緒共享的記憶體區域。 |
|
劃分 |
從結構上來分，可以分為新生代和老生代。而新生代又可以分為Eden 空間、From Survivor 空間（s0）、To Survivor 空間（s1）。所有新生成的物件首先都是放在年輕代的。需要注意，Survivor的兩個區是對稱的，沒先後關係，所以同一個區中可能同時存在從Eden複製過來 物件，和從前一個Survivor複製過來的物件，而複製到年老區的只有從第一個Survivor去過來的物件。而且，Survivor區總有一個是空的。
|
|
|
控制引數 |
-Xms設定堆的最小空間大小。-Xmx設定堆的最大空間大小。 -XX:NewSize設定新生代最小空間大小。-XX:MaxNewSize設定新生代最小空間大小。 |
|
|
垃圾回收 |
堆是垃圾回收的主要操作區域。 |
|
|
異常情況 |
如果在堆中沒有記憶體完成例項分配，並且堆也無法再擴充套件時，將會丟擲OutOfMemoryError 異常。 |
方法區
|
方法區介紹 |
作用 |
用於儲存已被虛擬機器載入的類資訊、常量、靜態變數、即時編譯器編譯後的程式碼等資料，是各個執行緒共享的記憶體區域。 |
|
劃分 |
很多人願意把方法區稱為“永久代”（Permanent Generation），本質上兩者並不等價，僅僅是因為HotSpot虛擬機器的設計團隊選擇把GC 分代收集擴充套件至方法區，或者說使用永久代來實現方法區而已。對於其他虛擬機器（如BEA JRockit、IBM J9 等）來說是不存在永久代的概念的。在Java8中永生代徹底消失了。 |
|
|
控制引數 |
-XX:PermSize 設定最小空間、 -XX:MaxPermSize 設定最大空間。 |
|
|
垃圾回收 |
對此區域會涉及但是很少進行垃圾回收。這個區域的記憶體回收目標主要是針對常量池的回收和對型別的解除安裝，一般來說這個區域的回收“成績”比較難以令人滿意。 |
|
|
異常情況 |
根據Java 虛擬機器規範的規定， 當方法區無法滿足記憶體分配需求時，將丟擲OutOfMemoryError。 |
虛擬機器棧
|
虛擬機器棧介紹 |
每個執行緒會有一個私有的棧。每個執行緒中方法的呼叫又會在本棧中建立一個棧幀。在方法棧中會存放編譯期可知的各種基本資料型別（boolean、byte、char、short、int、float、long、double）、物件引用（reference 型別，它不等同於物件本身。區域性變量表所需的記憶體空間在編譯期間完成分配，當進入一個方法時，這個方法需要在幀中分配多大的區域性變數空間是完全確定的，在方法執行期間不會改變區域性變量表的大小。 |
|
控制引數 |
-Xss控制每個執行緒棧的大小。 |
|
異常情況 |
在Java 虛擬機器規範中，對這個區域規定了兩種異常狀況：
|
本地方法棧
|
本地方法棧介紹 |
本地方法棧（Native Method Stacks）與虛擬機器棧所發揮的作用是非常相似的，其 區別不過是虛擬機器棧為虛擬機器執行Java 方法（也就是位元組碼）服務，而本地方法棧則 是為虛擬機器使用到的Native 方法服務。 |
|
控制引數 |
在Sun JDK中本地方法棧和方法棧是同一個，因此也可以用-Xss控制每個執行緒的大小。 |
|
異常情況 |
與虛擬機器棧一樣，本地方法棧區域也會丟擲StackOverflowError 和OutOfMemoryError異常。 |
PC程式計數器
它的作用可以看做是當前執行緒所執行的位元組碼的行號指示器。
此記憶體區域是唯一一個在Java 虛擬機器規範中沒有規定任何OutOfMemoryError 情況的區域。
二、GC
簡言之，Java程式記憶體主要（這裡強調主要二字）分兩部分，堆和非堆。大家一般new的物件和陣列都是在堆中的，而GC主要回收的記憶體也是這塊堆記憶體。
堆記憶體模型的特點：
-
堆記憶體由垃圾回收器的自動記憶體管理系統回收。堆記憶體分為兩大部分：新生代和老年代。比例為1：2。
-
老年代主要存放應用程式中生命週期長的存活物件。
-
新生代又分為三個部分：一個Eden區和兩個Survivor區，比例為8：1：1。
-
Eden區存放新生的物件。Survivor存放每次垃圾回收後存活的物件。
關於幾個重點問題：
-
為什麼要分新生代和老年代？
-
為什麼要新生代要分一個Eden區和兩個Survivor區？
-
一個Eden和兩個Survivor區的比例為什麼是8:1:1？
那麼這幾個問題都是由垃圾回收器鎖採用的回收演算法決定的，所以問題轉化為，是哪種演算法，為什麼要採用這種演算法的問題。
判定可回收物件
在進行垃圾回收之前，我們需要清除一個問題——什麼樣的物件是垃圾（無用物件），需要被回收？目前最常見的有兩種演算法用來判定一個物件是否為垃圾：引用計數演算法、可達性分析演算法（根搜尋演算法）；
引用計數演算法
給物件中新增一個引用計數器，每當有一個地方引用它時，計數器值就加1；當引用失效時，計數器值就減1；任何時刻計數器為0的物件就是不可能再被使用的。
優點：簡單，高效，現在的objective-c用的就是這種演算法
缺點：很難處理迴圈引用，比如圖中相互引用的兩個物件則無法釋放。
這個缺點很致命，有人可能會問，那objective-c不是用的好好的嗎？我個人並沒有覺得objective-c好好的處理了這個迴圈引用問題，它其實是把這個問題拋給了開發者。
可達性分析演算法（根搜尋演算法）
為了解決上面的迴圈引用問題，Java採用了一種新的演算法：可達性分析演算法。
從GC Roots（每種具體實現對GC Roots有不同的定義）作為起點，向下搜尋它們引用的物件，可以生成一棵引用樹，樹的節點視為可達物件，反之視為不可達。
OK，即使迴圈引用了，只要沒有被GC Roots引用了依然會被回收。但是，這個GC Roots的定義就要考究了，Java語言定義瞭如下GC Roots物件：
-
虛擬機器棧（幀棧中的本地變量表）中引用的物件。
-
方法區中靜態屬性引用的物件。
-
方法區中常量引用的物件。
-
本地方法棧中JNI引用的物件。
Stop The World
有了上面的垃圾物件的判定，我們還要考慮的問題就是Stop The World。
因為垃圾回收的時候，需要整個的引用狀態保持不變，否則判定是判定垃圾，等我稍後回收的時候它又被引用了，就全亂了。所以，GC的時候，其他所有的程式執行處於暫停狀態，卡住了。
幸運的是，這個卡頓是非常短（尤其是新生代），對程式的影響微乎其微 （關於其他GC比如併發GC之類的，在此不討論）。所以GC的卡頓問題由此而來，也是情有可原，暫時無可避免。
垃圾回收
標記了哪些是垃圾，接下來就可以進行垃圾回收了。目前JVM採用的是分代回收演算法，而這個演算法正是從以下幾種演算法發展而來：
標記清除法
這個演算法分兩個階段：標記階段、清除階段。
標記階段的任務是標記出所有需要被回收的物件，清除階段就是回收被標記的物件所佔用的空間。
優點：簡單實現。
缺點：容易產生記憶體碎片（碎片太多可能會導致後續過程中需要為大物件分配空間時無法找到足夠的空間而提前觸發新的一次垃圾收集動作）。
複製演算法
複製演算法將可用記憶體按容量劃分為大小相等的兩塊，每次只使用其中的一塊。當這一塊的記憶體用完了，就將還存活著的物件複製到另外一塊上面，然後再把已使用的記憶體空間一次清理掉，這樣一來就不容易出現記憶體碎片的問題。
優點：實現簡單，執行高效且不容易產生記憶體碎片。
缺點：對記憶體空間的使用做出了高昂的代價，因為能夠使用的記憶體縮減到原來的一半。複製演算法演算法的效率跟存活物件的數目多少有很大的關係，如果存活物件很多，那麼複製演算法演算法的效率將會大大降低。
標記整理法
標記階段與標記清除演算法一致，但是在完成標記之後，它不是直接清理可回收物件，而是將存活物件都向一端移動，然後清理掉端邊界以外的記憶體。
優點：實現簡單，不容易產生記憶體碎片，記憶體使用高效。
缺點：效率非常低。
所以，特別適用於存活物件多，回收物件少的情況下。
分代回收演算法
以上幾種演算法都有各自的優點和缺點，適用於不同的記憶體情景。而分代回收演算法根據Java的語言特性，將複製演算法和標記整理演算法的的特點相結合，針對不同的記憶體情景使用不同的回收演算法。
這裡重複一下兩種老演算法的適用場景：
複製演算法：適用於存活物件很少。回收物件多
標記整理演算法: 適用用於存活物件多，回收物件少
於是，我們根據物件存活的生命週期將記憶體劃分為若干個不同的區域。一般情況下將堆區劃分為老年代（Old Generation）和新生代（Young Generation），老年代的特點是每次垃圾收集時只有少量物件需要被回收，使用標記整理演算法，而新生代的特點是每次垃圾回收時都有大量的物件需要被回收，複製演算法 ，那麼就可以根據不同代的特點採取最適合的收集演算法。
現在回頭去看堆記憶體為什麼要劃分新生代和老年代，是不是覺得如此的清晰和自然了？
具體來看：
-
對於新生代，雖然採取的是複製演算法，但是，實際中並不是按照上面演算法中說的1：1的比例來劃分新生代的空間，而是將新生代劃分為一塊較大的Eden空間和兩塊較小的Survivor空間，比例為8：1：1。這一點後面會講解。
-
老年代的特點是每次回收都只回收少量物件，這符合一個穩定系統的主要特徵——超過一半的物件會長期駐留在記憶體中。所以老年代的比例要大於新生代，預設的新生代：老年代的比例為1：2。
這就是分代回收演算法。
深入理解垃圾回收演算法
為什麼不是一塊Survivor空間而是兩塊？
這裡涉及到一個新生代和老年代的存活週期的問題，比如一個物件在新生代經歷15次（僅供參考）GC，就可以移到老年代了。問題來了，當我們第一次GC的時候，我們可以把Eden區的存活物件放到Survivor A空間，但是第二次GC的時候，Survivor A空間的存活物件也需要再次用Copying演算法，放到Survivor B空間上，而把剛剛的Survivor A空間和Eden空間清除。第三次GC時，又把Survivor B空間的存活物件複製到Survivor A空間，如此反覆。
所以，這裡就需要兩塊Survivor空間來回倒騰。
為什麼Eden空間這麼大而Survivor空間要分的少一點？
新建立的物件都是放在Eden空間，這是很頻繁的，尤其是大量的區域性變數產生的臨時物件，這些物件絕大部分都應該馬上被回收，能存活下來被轉移到survivor空間的往往不多。所以，設定較大的Eden空間和較小的Survivor空間是合理的，大大提高了記憶體的使用率，緩解了Copying演算法的缺點。
我看8：1：1就挺好的，當然這個比例是可以調整的，包括上面的新生代和老年代的1：2的比例也是可以調整的。
新的問題又來了，從Eden空間往Survivor空間轉移的時候Survivor空間不夠了怎麼辦？直接放到老年代去。
Eden空間和兩塊Survivor空間的工作流程
假定有新生代Eden，Survivor A， Survivor B三塊空間和老生代Old一塊空間。其主要流程為：
// 分配了一個又一個物件 放到Eden區 // 不好，Eden區滿了，只能GC(新生代GC：Minor GC)了 把Eden區的存活物件copy到Survivor A區，然後清空Eden區（本來Survivor B區也需要清空的，不過本來就是空的） // 又分配了一個又一個物件 放到Eden區 // 不好，Eden區又滿了，只能GC(新生代GC：Minor GC)了 把Eden區和Survivor A區的存活物件copy到Survivor B區，然後清空Eden區和Survivor A區 // 又分配了一個又一個物件 放到Eden區 // 不好，Eden區又滿了，只能GC(新生代GC：Minor GC)了 把Eden區和Survivor B區的存活物件copy到Survivor A區，然後清空Eden區和Survivor B區 // ... // 有的物件來回在Survivor A區或者B區呆了比如15次，就被分配到老年代Old區 // 有的物件太大，超過了Eden區，直接被分配在Old區 // 有的存活物件，放不下Survivor區，也被分配到Old區 // ... // 在某次Minor GC的過程中突然發現： // 不好，老年代Old區也滿了，這是一次大GC(老年代GC：Major GC) Old區慢慢的整理一番，空間又夠了 // 繼續Minor GC // ... // ...複製程式碼
觸發GC的型別
Java虛擬機器會把每次觸發GC的資訊打印出來來幫助我們分析問題，所以掌握觸發GC的型別是分析日誌的基礎。
-
GC_FOR_MALLOC: 表示是在堆上分配物件時記憶體不足觸發的GC。
-
GC_CONCURRENT: 當我們應用程式的堆記憶體達到一定量，或者可以理解為快要滿的時候，系統會自動觸發GC操作來釋放記憶體。
-
GC_EXPLICIT: 表示是應用程式呼叫System.gc、VMRuntime.gc介面或者收到SIGUSR1訊號時觸發的GC。
-
GC_BEFORE_OOM: 表示是在準備拋OOM異常之前進行的最後努力而觸發的GC。