在Java中要建立一個物件最簡單方法就是new，當然大部分情況下我們還是通過spring來管理物件。但對於JVM來說一個物件的建立、存亡可沒那麼簡單了。

物件的建立

虛擬機器遇到一條new指令時，首先去檢查這個指令的引數是否能在常量池中定位到一個類的符號引用，並且檢查這個符號引用代表的類是否已經被載入、解析和初始化。如果沒有，則必須先執行相應的類載入過程。參考：關於類載入機制
在類載入檢查通過後，接下來虛擬機器將為新生物件分配記憶體。物件所需記憶體的大小在類載入完成後就可以完全確定，給物件分配空間的任務就等同於把一塊確定大小的記憶體從Java堆中劃分出來。

假設Java堆中記憶體時絕對規整的，所有用過的記憶體都放一邊，空閒的記憶體放另一邊，中間放著一個指標作為分界點的指示器，那所分配記憶體就僅僅是吧指標像空閒的那邊移動一段與物件大小相等的距離，這種分配方式稱為“指標碰撞

假設Java堆中記憶體並不規整，已使用的記憶體和空閒相互交錯，指標碰撞肯定不行，虛擬機器就必須維護一個列表，記錄哪些記憶體塊是可用的，在分配的時候從列表中找到一塊足夠大的空間劃分給物件例項，並更新列表上的記錄，這種分配方式稱為“空間列表”。選擇哪種分配方式有Java堆是否規整決定，而Java堆是否規整又由所採用的垃圾收集器是否帶有壓縮整理功能決定。因此，在使用Serial、ParNew等帶Compact過程的收集器時，系統採用的分配演算法是指標碰撞，而使用CMS這種基於標記-清除演算法的收集器時，通常採用空閒列表。

當然不管哪種分配方式，在併發情況下是執行緒不安全的，即使是僅僅修改一個指標所指向的位置，比如物件A分配記憶體，指標還沒來的及修改，物件B又同時使用了原來的指標來分配記憶體情況。有兩種解決方案，一種是對分配記憶體空間的動作進行同步處理——實際上虛擬機器採用CAS配上失敗重試的方式保證更新新操作的原子性（這種方法被經常使用比如ConcurrentHashMap）；另一種是把記憶體分配的動作按照執行緒劃分在不同的的空間中進行，即每個執行緒在Java堆中預先分配一小塊記憶體，稱為本地現場分配緩衝（Thread Local Allocation Buffer,TLAB）。哪個執行緒要分配記憶體，就在哪個執行緒的TABLE上分配，只有TABLE用完並分配新的TLAB時，才需要同步鎖定。虛擬機器是否使用TLAB，可以通過-XX:+/-UseTLAB引數來設定。
記憶體分配完後，虛擬機器需要將分配到的記憶體空間都初始化為零值（不包括物件頭），如果使用TLAB，這一工作過程也可以提前至TLAB分配時進行。這一步操作保證了物件的例項欄位在Java程式碼中可以不賦初始值就直接使用，程式能訪問到這些欄位的資料型別所對應的零值。接下來，虛擬機器要對物件進行必要的設定，例如這個物件是哪個類的例項、如何才能找到類的元資料資訊、物件的雜湊碼、物件的GC分代年齡等資訊。這些資訊存放在物件的物件頭中。至此從虛擬機器的角度來看，一個新的物件已經產生了，但從Java程式的角度來看，物件建立才剛剛開始——方法還沒執行，所有的欄位都還為零。

物件的訪問

我們知道Java程式需要通過站上的reference資料來操作堆上的具體物件（可以參考：Java記憶體區域詳解）。Java虛擬機器規範中只規定了一個指向物件的引用，並沒有定義這個引用應該通過何種方式去定位訪問，所有物件的訪問方式是由虛擬機器來決定的，目前主流的訪問方式有使用控制代碼和直接指標兩種。
控制代碼訪問：如果使用控制代碼訪問的話，Java堆中將會劃分出一塊記憶體來作為控制代碼池，reference中儲存的就是物件的控制代碼地址，而控制代碼中包含了物件例項資料與型別資料各自的具體地址資訊。如圖：

直接指標：如果使用直接指標訪問，那麼Java堆物件的佈局中就必須考慮如何放置訪問型別資料的相關資訊，而reference中儲存的直接就是物件地址如圖：

兩種訪問方式各有優勢，使用控制代碼訪問最大的好處就是reference中儲存的是穩定的控制代碼地址，在物件被移動時只會改變控制代碼中的例項資料指標，而reference本身不需要修改。
而是用直接指標訪問方式的最大好處就是速度更快，它節省了一次指標定位的時間開銷，由於物件的訪問在Java中非常頻繁，因此這類開銷積少成多也是非常可觀的執行成本。

物件的存亡

在Java中幾乎所有的例項物件都存在堆空間，垃圾收集器在對堆進行回收前，第一件事情就是要確定這些物件哪些還存活哪些已經死去（即不可能再被任何途徑使用的物件），而判斷物件的存亡有兩種：引用計數演算法和可達性分析演算法

引用計數演算法
給物件中新增一個引用計數器，每當有一個地方引用它時，計數器值就加1；當引用失效時，計數器值就減1；當計數值為0時說明此物件已經不再被使用。引用計數演算法的實現簡單，判定效率高，有一些大型公司使用此方式如微軟。但主流的Java虛擬機器沒有選用此種方式來管理記憶體，其中主要的原因是它很難解決物件之間的相互迴圈引用問題。

public class ReferenceCountingGC {  
    public Object instance = null;  

    private static final int _1MB = 1024 * 1024;  

    /** 
     * 
     */  
    private byte[] bigSize = new byte[2 * _1MB];  

    public static void main(String[] args) {  
        ReferenceCountingGC objA = new ReferenceCountingGC();  
        ReferenceCountingGC objB = new ReferenceCountingGC();  
        objA.instance = objB;  
        objB.instance = objA;  

        objA = null;  
        objB = null;  

        //假設在這行發生了GC，objA和ojbB是否被回收  
        System.gc();  
    }  
}  

可達性分析演算法
在主流的商用程式語言的主流實現中，都是通過可達性分析演算法來判定物件的存活。這個演算法的基本思路是童工一系列稱為“GC Roots”的物件作為起始點，從這些節點開始 向下搜尋，搜尋所走過的路徑稱為引用鏈，當一個物件到GC Roots沒有任何引用鏈相連時，則證明此物件不可用。如圖：雖然物件8、9、10、11、12相互有引用但是它們到GC Roots是不可達的，所以被判定為可回收物件。

在Java語言中，可作為GC Roots的物件包括下面幾種：
虛擬機器棧（棧幀中的本地變量表）中引用的物件
方法區中類靜態屬性引用的物件
方法區中常量引用的物件
本地方方棧中Native方法引用的物件

本文來自《深入理解Java虛擬機器》