JAVA虛擬機器——物件由生（建立物件）到死（垃圾回收）的底層原理過程
建立物件
在Java程式語言中，建立物件通常是一個new關鍵字而已，但在虛擬機器中，物件（此處物件僅代表普通的Java物件，不包括陣列和Class物件等）的建立是如何呢？
①虛擬機器遇到一條new指令時，首先將去檢查這個指令的引數是否能在常量池中定位到一個類的符號引用，並且檢查這個符號引用代表的類是否已被載入、解析和初始化過，如果沒有，那必須先執行相應的類載入過程。
②在類載入檢查通過後，虛擬機器將為新生物件分配記憶體，物件所需記憶體的大小在類載入完成後便可以確定。
③記憶體分配完成後，虛擬機器需要將分配到的記憶體空間都初始化為零值（不包括物件頭）。若使用TLAB，這一工作過程也可提前至TLAB分配時進行，保證了物件的例項欄位在Java程式碼中可以不賦初始值就可以直接使用，程式訪問欄位的資料型別所對應的零值。
④虛擬機器要對物件進行必要的設定（物件雜湊碼，GC分代年齡等資訊）存放在物件的物件頭（Object Header）之中。
⑤前幾步完成後，從虛擬機器的角度來看，一個新的物件產生了，但從Java程式的角度，物件建立才剛開始（init方法沒有執行，所有欄位都為零）。一般來說（由位元組碼中是否跟隨invokespecial指令決定），執行new指令之後會接著執行init方法，把物件初始化。
分配記憶體
虛擬機器為新生物件分配物件分配記憶體，等同於將一塊確定大小的記憶體從Java堆中劃分出來。
指標碰撞
假設java堆中記憶體是絕對規整的，所有用過的記憶體都放在一邊，空閒的記憶體放在另一邊，中間放著一個指標作為分界點的指示器，那所分配記憶體就僅僅是把那個指標向空閒空間那邊挪動一段與物件大小相等的距離，這種分配方式稱為“指標碰撞”。
空閒列表
如果java堆中的記憶體並不是規整的，已使用的記憶體和空閒的記憶體相互交替，那就沒有辦法簡單地進行指標碰撞了，虛擬機器就必須維護一個列表，記錄上哪些記憶體塊是可用的，在分配的時候從列表中找到一塊足夠大的空間劃分給物件例項，並更新列表上的記錄，這種分配方式稱為“空閒列表”
選擇哪種分配方式由java堆是否規整決定，而java堆是否規整又由所採用的垃圾收集器是否帶有壓縮整理功能決定的。
執行緒安全問題
除了如何劃分可用空間之外，還有一個需要考慮的問題是物件建立在虛擬機器中是非常頻繁的行為，即使是僅僅修改一個指標所指向的位置，在併發的情況下也並不是執行緒安全的，可能出現正在給物件A分配記憶體，指標還沒來得及修改，物件B又同時使用了原來的指標來分配記憶體的情況，解決這個問題有兩種方案：
一種是對分配記憶體空間的動作進行同步處理——實際上虛擬機器採用CAS配上失敗重試的方式保證更新操作的原子性
另一種是把記憶體分配的動作按照執行緒劃分在不同的空間之中進行，即每個執行緒在java堆中預先分配一小塊記憶體，稱為本地執行緒分配緩衝（TLAB）。哪個執行緒要分配記憶體，就在哪個執行緒的TLAB上分配，只有TLAB用完並分配新的TLAB時，才需要同步鎖定。虛擬機器是否使用TLAB，可以通過-XX:+/-UseTLAB引數來設定。
回收物件
在堆裡面存放著Java世界中幾乎所有的物件例項，垃圾收集器在對堆進行回收前，第一件事情就是要確定這些物件之中哪些還‘存活’著，哪些已經‘死去’。
可達性分析演算法
在主流的商用程式語言的主流實現中，都通過可達性分析演算法來判定物件是否存活。 通過一系列的稱為“GC Roots”的物件作為起始點，從這些節點開始向下搜尋，搜尋所走過的路徑稱為引用鏈，當一個物件到GC Roots沒有任何引用鏈相連時，這個物件已‘死’。
在Java語言中，GC Roots的物件有：
- 棧中引用的物件
- 方法區中類靜態屬性引用的物件
- 方法區中常量引用的物件
生存還是死亡
即使在可達性分析演算法中不可達的物件，也並非是“非死不可”的，這時候它們暫時處於“緩刑”階段，要真正宣告一個物件死亡，至少要經歷兩次標記過程。
如果物件在進行可達性分析後發現沒有與GC Roots相連線的引用鏈。 那它將會被第一次標記並進行一次篩選。
篩選的條件：此物件是否有必要執行finalize()方法。 當物件沒有覆蓋finalize方法，或者finzlize方法已經被虛擬機器呼叫過， 虛擬機器將這兩種情況都視為“沒有必要執行”。
如果這個物件被判定為有必要執行finalize（）方法，那麼這個物件將會被放置在一個名為：F-Queue的佇列之中，並在稍後由一條虛擬機器自動建立的、低優先順序的Finalizer執行緒去執行。這裡所謂的“執行”是指虛擬機器會觸發這個方法，但並不承諾會等待它執行結束。這樣做的原因是，如果一個物件finalize（）方法中執行緩慢，或者發生死迴圈（更極端的情況），將很可能會導致F-Queue佇列中的其他物件永久處於等待狀態，甚至導致整個記憶體回收系統崩潰。
Finalize（）方法是物件脫逃死亡命運的最後一次機會，稍後GC將對F-Queue中的物件進行第二次小規模標記，如果物件要在finalize（）中成功拯救自己----只要重新與引用鏈上的任何的一個物件建立關聯即可，譬如把自己賦值給某個類變數或物件的成員變數，那在第二次標記時它將移除出“即將回收”的集合。
如果物件這時候還沒逃脫，那基本上它就真的被 回收 了。