@
目錄- 前言
- 正文
- 一、物件的創建方式
- 二、物件的創建程序
- 物件在哪里創建
- 分配記憶體
- 物件的記憶體布局
- 三、物件的訪問定位
- 四、判斷物件的存活
- 物件生死
- 回收方法區
- 參考
- 物件的自我拯救
- 五、物件的分配策略
- 優先在Eden區分配
- 大物件直接進入老年代
- 長期存活的物件進入老年代
- 動態物件年齡判定
- 空間分配擔保
- 總結
前言
Java是面向物件的語言，所謂“萬事萬物皆物件”就是Java是基于物件來設計程式的，沒有物件程式就無法運行（8大基本型別除外），那么物件是如何創建的？在記憶體中又是怎么分配的呢？
正文
一、物件的創建方式
在Java中我們有幾種方式可以創建一個新的物件呢？總共有以下幾種方式：
- new關鍵字
- 反射
- clone
- 反序列化
- Unsafe.allocateInstance
為了便于說明和理解，下文僅針對new出來的物件進行討論，
二、物件的創建程序
Java中物件的創建程序就包含上圖中的5個步驟，首先需要驗證待創建物件的類是否已經被JVM記載，如果沒有則會先進行類的加載，如果已經加載則會在堆中（不完全是堆，后文會講到）分配記憶體；分配完記憶體后則是對物件的成員變數設定初始值（0或null），這樣物件在堆中就創建好了，但是，這個物件是屬于哪個類的還不知道，因為類資訊存在于方法區，所以還需要設定物件的頭部（當然頭部中也不僅僅只有型別指標資訊，稍后也會詳細講到），這樣堆中才創建好了一個完整的物件，但是這個物件的成員變數還都是初始值，所以最后會呼叫init方法按照我們自己的意愿初始化物件，一個真正的物件就創建好了，
物件的整個創建程序是非常簡單的，但是其中還有很多細節，比如物件會在哪里創建？分配記憶體有哪些方式？怎么保證執行緒安全？物件頭中有哪些資訊？下面一一講解，
物件在哪里創建
基本上所有的物件都是在堆中，但并非絕對，在JDK1.6版本引入了逃逸分析技術，逃逸分析就是指標對物件的作用域進行判定，當一個物件在方法中被定義后，如果被其它方法或其它執行緒訪問到，就稱為方法逃逸或執行緒逃逸，
該技術針對未逃逸的物件做了一個優化：堆疊上分配（除此之外還有同步消除、標量替換，這里暫時不講），這個優化是指當一個物件能被確定不會在該方法之外被參考，那么就可以直接在虛擬機堆疊中創建該物件，那么這個物件就可以隨著執行緒的消亡而銷毀，不再需要垃圾回收器進行回收，這個優化帶來的收益是明顯的，因為有相當一部分物件都只會在該方法內部被參考，逃逸分析默認是開啟的，可以通過-XX:-DoEscapeAnalysis引數關閉，下面看一個實體：
public class EscapeAnalysisTest {
public static void main(String[] args) throws Exception {
long start = System.currentTimeMillis();
for (int i = 0; i < 50000000; i++) {//5000萬次---5000萬個物件
allocate();
}
System.out.println((System.currentTimeMillis() - start) + " ms");
Thread.sleep(600000);
}
static void allocate() {//逃逸分析（不會逃逸出方法）
//這個myObject參考沒有出去，也沒有其他方法使用
MyObject myObject = new MyObject(2020, 2020.6);
}
static class MyObject {
int a;
double b;
MyObject(int a, double b) {
this.a = a;
this.b = b;
}
}
}
加上-XX:+PrintGC引數運行上面的方法，會看到控制臺只是列印了執行時間5ms，但是若再加上-XX:-DoEscapeAnalysis關閉逃逸分析就會出現下面的結果：
[GC (Allocation Failure) 66384K->848K(251392K), 0.0012528 secs]
[GC (Allocation Failure) 66384K->816K(251392K), 0.0010461 secs]
[GC (Allocation Failure) 66352K->848K(316928K), 0.0009666 secs]
[GC (Allocation Failure) 131920K->784K(316928K), 0.0018284 secs]
[GC (Allocation Failure) 131856K->816K(438272K), 0.0009315 secs]
[GC (Allocation Failure) 262960K->684K(438272K), 0.0022738 secs]
[GC (Allocation Failure) 262828K->684K(700928K), 0.0005052 secs]
308 ms
執行時間大大提升，主要是用在了GC回收上，
分配記憶體
- 分配方式
JVM有兩種分配記憶體的方式：指標碰撞和空閑串列，使用哪種方式取決于堆中記憶體是否規整，而是否規整又取決于使用的垃圾回收器，這個是下一篇的內容，如果記憶體規整，那么就會使用指標碰撞分配記憶體，也就是將已用的記憶體和未用的記憶體分開分別放到一邊，中間使用指標作為分界線；當需要分配記憶體時，指標就向未分配的那一邊挪動一段與物件大小相等的距離，如果記憶體不是規整的，JVM會維護一個串列，串列中會記錄哪些記憶體是可用的，分配記憶體時首先就會去這個表里面找到可用且大小合適的記憶體， - 執行緒安全
理解了上面的兩種方式，敏銳的讀者應該很快就能發現其中的問題，我們的JVM肯定不會以單執行緒的方式去堆中創建物件，那樣效率是極低的，那么怎么保證同一時間不會有兩個執行緒同時占用同一塊記憶體呢？JVM同樣有兩種方式保證執行緒安全：CAS和TLAB（本地執行緒緩沖），- CAS是compare and swap，涉及到預期值、記憶體值和更新值，意思當前執行緒每當需要分配記憶體時首先從記憶體中取出值和期望值比較，如果相等則將記憶體中的值更新為更新值，否則則繼續回圈比較，這樣當前執行緒在申請記憶體時，一旦該記憶體被其它執行緒提前占據，那么當前執行緒就會去申請其它未被占據的記憶體，
- TLAB是指執行緒首先會去堆中申請一塊記憶體，每個執行緒都在各自占據的記憶體中創建物件，也就不存在執行緒安全問題了，可以通過-XX:+/-UseTLAB引數進行控制，
物件的記憶體布局
在HotSpot虛擬機中，物件在記憶體中分為三塊：物件頭、實體資料和對齊填充，如下圖：
物件的記憶體布局上面這張圖寫的很清楚了，其中自身運行時資料了解一下有哪些資訊即可，型別指標則是指向物件所屬的類，如果物件是陣列，則物件頭中還會包含陣列的長度資訊；實體資料就是指物件的欄位資訊；最后對齊填充則不是必須的，因為為了方便處理和計算，HotSpot要求物件的大小必須是8位元組的整數倍，因此當不滿8位元組的整數倍時，就需要對齊填充來補全，
三、物件的訪問定位
當物件創建完成后就存在于堆中，那么堆疊中怎么定位并參考到該物件呢？虛擬機規范中本身并沒有定義這一部分該如何實作，具體的實作取決于各個虛擬機廠商，而目前主流的定位方式有兩種：句柄和直接指標，
- 句柄
通過句柄的方式參考就是虛擬機首先會在堆中劃分一塊區域作為句柄池，句柄池中包含了指向物件實體和型別資料的指標，而堆疊中則只需要參考句柄池即可，這種方式的好處顯而易見，參考非常穩定，不會隨著物件的移動而需要改變堆疊中的參考，但這樣勢必會降低參考的性能，同時堆中可用記憶體變少， - 直接指標
顧名思義，直接指標就是指堆疊中參考直接指向堆中的物件，這樣做的好處就是效率非常高，不需要通過句柄池中轉，但也因此失去了穩定性，
以上兩種方式在各個語言和框架都有使用，而本文所討論的HotSpot虛擬機使用的是直接指標方式，因為物件的訪問是非常頻繁的，這時效率就顯得格外重要，
四、判斷物件的存活
物件生死
JVM不需要我們手動釋放記憶體，這是Java廣受歡迎的原因之一，那么它是如何做到自動管理記憶體，回收不需要的物件的呢？既然要回收物件，那么就需要判斷哪些物件是可以被回收的，即物件的死活判定，哪些物件不會再被參考？有兩種實作方式：參考計數法和可達性分析，
- 參考計數法：這個演算法很簡單，每個物件關聯一個計數器，物件每被參考一次，計數器就加1，參考失效時，計數器就減一，垃圾回收時只需要回收計數為0的物件即可，這樣做效率很高，但是這個演算法有個顯著的缺點，沒法解決回圈依賴，即A依賴B，B依賴A，這樣它們的計數器都為1，但實際上除此之外沒有任何地方參考它們了，就會導致記憶體泄露（即記憶體無法被釋放），
- 可達性分析：相較于參考計數法，這個演算法效率會低一些，但卻是虛擬機采用的方式，因為它就能解決回圈依賴的問題，該演算法會將一部分物件作為GC Roots，然后以這些物件作為起點開始搜索，當一個物件到GC Roots沒有任何途徑可以到達時，則表示該物件可以被回收，問題就在于那些物件可以作為GC Roots呢？
- 虛擬機堆疊（堆疊幀中的區域變數表）中參考的物件
- 方法區中類靜態屬性參考的物件
- 常量池參考的物件
- 本地方法堆疊中JNI（native方法）參考的物件
以上4種非常好理解，是重點，需要熟記于心，因為上面4種物件是在方法運行時或常量參考的物件，在對應的生命周期是肯定不能被GC回收的，作為GC Roots自然再合適不過，另外還有下面幾種可以作為了解：
- JVM內部參考的物件（class物件、例外物件、類加載器等）
- 被同步鎖（synchronized關鍵字）持有的物件
- JVM內部的JMXBean、JVMTI中注冊的回呼、本地代碼快取等
- JVM中實作的“臨時性”物件，跨代參考的物件
回收方法區
除了堆中物件需要回收，方法區中的class物件也是可以被回收的，但是回收的條件非常苛刻：
- 該類的所有實體都已經被回收，堆中不存在該類的物件
- 加載該類的ClassLoader已被回收
- 該類對應的java.lang.Class物件沒有在任何地方被參考，無法在任何地方通過反射訪問該類的方法
可以看到方法區的回收條件是多么苛刻，所以方法區的回收率一般極低，因此可以通過-Xnoclassgc關閉方法區的回收，提升GC效率，但需要注意，關閉后將會導致方法區的記憶體永久被占用，導致OOM出現，
參考
通過上文我們可以發現，物件的存活判定都是基于參考，而Java中參考又分為了4種：
- 強參考：平時我們使用=賦值就屬于強參考，被強參考關聯的物件，永遠不會被GC回收，
- 軟參考（SoftReference）：常用來參考一些有用但并非必需的物件，如實作快取，因為軟參考只會在要發生OOM之前檢查并被回收掉，如果回收后空間仍然不足，才會拋出OOM例外，
- 弱參考（WeakReference）：比軟參考更弱的參考，只要發生垃圾回收就會被回收掉的參考，也可以用來實作快取，在Java中，WeakHashMap和ThreadLocal的鍵都是利用弱參考實作的（注意這兩個類的區別，前者可以配合ReferenceQueue使用，當key被回收時會被加入到該佇列中，繼而在清除null key時直接掃描這個佇列即可；而后者在清除null key時需要遍歷所有的鍵，關于ThreaLocal后面會在并發系列中詳細分析），
- 虛參考（PhantomReference）：最弱的參考，一個物件是否有虛參考，完全不會影響到其生命周期，無法通過該參考獲取到一個物件的實體，使用時需要和ReferenceQueue配合使用，而使用它的唯一目的就是在這個物件被垃圾回收時能夠接收到一個通知，
物件的自我拯救
虛擬機提供了一次自我拯救的機會給物件，即finalize方法，如果物件覆寫了該方法，當經過可達性分析后，就會進行一次判斷，判斷該物件是否有必要執行finalize方法，如果物件沒有覆寫該方法或者已經執行過一次該方法都會判定為該物件沒有必要執行finalize方法，在GC時被回收，否則就會將該物件放入到一個叫F-Queue的佇列中，之后GC會對該佇列的物件進行二次標記，即呼叫該方法，如果我們要讓該物件復活，那么就只需要在finalize方法中將該物件重新與GC Roots關聯上即可，
該方法是虛擬機提供給物件復活的唯一機會，但是該方法作用極小，因為使用不慎可能會導致系統崩潰，另外由于它的運行優先級也非常低，常常需要主執行緒等待它的執行，導致系統性能大大降低，所以基本上可以忘記該方法的存在了，
五、物件的分配策略
上文說到物件是在堆中分配記憶體的，但是堆中也是分為新生代和老年代的，新生代中又分了Eden、from、survivor區，那么物件具體會分配到哪個區呢？這涉及到物件的分配規則，下面一一說明，
優先在Eden區分配
大多數情況，物件直接在Eden區中分配記憶體，當Eden區記憶體不足時，就會進行一次MinorGC（新生代垃圾回收，可以通過-XX:+PrintGCDetails這個引數列印GC日志資訊），
大物件直接進入老年代
什么是大物件？虛擬機提供了一個引數：-XX:PretenureSizeThreshold，當物件大小大于該值時，該物件就會直接被分配到老年代中（該引數只對Serial和ParNew垃圾收集器有效），為什么不分配到新生代中呢？因為在新生代中每一次MinroGC都會導致物件在Eden、from和sruvivor中復制，如果存在很多這樣的大物件，那么新生代的GC和復制效率就會極低（關于垃GC的內容后面的文章會詳細講解），
長期存活的物件進入老年代
既然物件優先在新生代中分配，那么什么時候會進入到老年代呢？這就和上文講解的物件頭中的分代年齡有關了，默認情況下超過15歲就會進入老年代，可以通過-XX:MaxTenuringThreshold引數進行設定，那歲數又是怎么增長的呢？每當物件熬過一次MiniorGC后年齡都會增加1歲，
動態物件年齡判定
但是虛擬機并不是要求物件年齡必須達到MaxTenuringThreshold才能晉升老年代，當Survivor空間中相同年齡的所有物件的大小總和大于Survivor空間一半時，年齡大于或等于該年齡的物件就會直接晉升到老年代，
空間分配擔保
在發生MiniorGC之前，虛擬機首先會檢查老年代中最大可用的連續空間是否大于新生代所有物件的總和，如果大于則進行一次MiniorGC；否則，則會檢查HandlePromotionFailure設定值是否允許擔保失敗，如果允許則會檢查老年代最大連續空間是否大于歷次晉升到老年代物件的平均大小，如果大于則進行一次MiniorGC，否則則進行一次FullGC，
為什么要這么設計呢？因為頻繁的FullGC會導致性能大大降低，而取歷次晉升老年代物件的平均大小肯定也不是百分百有效，因為存在物件突然大大增加的情況，這個時候就會出現擔保失敗的情況，也會導致FullGC，需要注意的是HandlePromotionFailure這個引數在JDK6Update24后就不會再影響到虛擬機的空間分配擔保策略了，即默認老年代的連續空間大于新生代物件的總大小或歷次晉升的平均大小就會進行MinorGC，否則進行FullGC，
總結
本文概念性的東西非常多，這是學習JVM的難點和基礎，但這是繞不開的一道坎，讀者只有多看，多思考，寫代碼復現文中提到的概念，才能真正的理解這些基礎知識，另外還有垃圾是怎么回收的？有哪些垃圾回收器？怎么選擇？這些問題將在下一篇進行解答，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/137674.html
標籤：Java
下一篇：自已動手作圖搞清楚AVL樹