一、對象的內存布局
HotSpot虛擬機中，對象在內存中存儲的布局可以分為三塊區域：對象頭（Header）、實例數據（Instance Data）和對齊填充（Padding）。
從上面的這張圖里面可以看出，對象在內存中的結構主要包含以下幾個部分：
- Mark Word(標記字段)：對象的Mark Word部分占4個字節，其內容是一系列的標記位，比如輕量級鎖的標記位，偏向鎖標記位等等。
- Klass Pointer（Class對象指針）：Class對象指針的大小也是4個字節，其指向的位置是對象對應的Class對象（其對應的元數據對象）的內存地址
- 對象實際數據：這里面包括了對象的所有成員變量，其大小由各個成員變量的大小決定，比如：byte和boolean是1個字節，short和char是2個字節，int和float是4個字節，long和double是8個字節，reference是4個字節
- 對齊：最后一部分是對齊填充的字節，按8個字節填充。
1.1、對象頭
1.1.1、Mark Word（標記字段）
HotSpot虛擬機的對象頭包括兩部分信息，第一部分是“Mark Word”，用於存儲對象自身的運行時數據， 如哈希碼（HashCode）、GC分代年齡、鎖狀態標志、線程持有的鎖、偏向線程ID、偏向時間戳等等，這部分數據的長度在32位和64位的虛擬機（暫 不考慮開啟壓縮指針的場景）中分別為32個和64個Bits，官方稱它為“Mark Word”。對象需要存儲的運行時數據很多，其實已經超出了32、64位Bitmap結構所能記錄的限度，但是對象頭信息是與對象自身定義的數據無關的額 外存儲成本，考慮到虛擬機的空間效率，Mark Word被設計成一個非固定的數據結構以便在極小的空間內存儲盡量多的信息，它會根據對象的狀態復用自己的存儲空間。例如在32位的HotSpot虛擬機 中對象未被鎖定的狀態下，Mark Word的32個Bits空間中的25Bits用於存儲對象哈希碼（HashCode），4Bits用於存儲對象分代年齡，2Bits用於存儲鎖標志 位，1Bit固定為0，在其他狀態（輕量級鎖定、重量級鎖定、GC標記、可偏向）下對象的存儲內容如下表所示。
但是如果對象是數組類型，則需要三個機器碼，因為JVM虛擬機可以通過Java對象的元數據信息確定Java對象的大小，但是無法從數組的元數據來確認數組的大小，所以用一塊來記錄數組長度。
對象頭信息是與對象自身定義的數據無關的額外存儲成本，但是考慮到虛擬機的空間效率，Mark Word被設計成一個非固定的數據結構以便在極小的空間內存存儲盡量多的數據，它會根據對象的狀態復用自己的存儲空間，也就是說，Mark Word會隨着程序的運行發生變化，變化狀態如下（32位虛擬機）：
表1 HotSpot虛擬機對象頭Mark Word
| 存儲內容 | 標志位 | 狀態 |
| 對象哈希碼、對象分代年齡 | 01 | 未鎖定 |
| 指向鎖記錄的指針 | 00 | 輕量級鎖定 |
| 指向重量級鎖的指針 | 10 | 膨脹（重量級鎖定） |
| 空，不需要記錄信息 | 11 | GC標記 |
| 偏向線程ID、偏向時間戳、對象分代年齡 | 01 | 可偏向 |
注意偏向鎖、輕量級鎖、重量級鎖等都是jdk 1.6以后引入的。
其中輕量級鎖和偏向鎖是Java 6 對 synchronized 鎖進行優化后新增加的，稍后我們會簡要分析。這里我們主要分析一下重量級鎖也就是通常說synchronized的對象鎖，鎖標識位為10，其中指針指向的是monitor對象（也稱為管程或監視器鎖）的起始地址。每個對象都存在着一個 monitor 與之關聯，對象與其 monitor 之間的關系有存在多種實現方式，如monitor可以與對象一起創建銷毀或當線程試圖獲取對象鎖時自動生成，但當一個 monitor 被某個線程持有后，它便處於鎖定狀態。在Java虛擬機(HotSpot)中，monitor是由ObjectMonitor實現的，其主要數據結構如下（位於HotSpot虛擬機源碼ObjectMonitor.hpp文件，C++實現的）
ObjectMonitor() { _header = NULL; _count = 0; //記錄個數 _waiters = 0, _recursions = 0; _object = NULL; _owner = NULL; _WaitSet = NULL; //處於wait狀態的線程，會被加入到_WaitSet _WaitSetLock = 0 ; _Responsible = NULL ; _succ = NULL ; _cxq = NULL ; FreeNext = NULL ; _EntryList = NULL ; //處於等待鎖block狀態的線程，會被加入到該列表 _SpinFreq = 0 ; _SpinClock = 0 ; OwnerIsThread = 0 ; }
ObjectMonitor中有兩個隊列，_WaitSet 和 _EntryList，用來保存ObjectWaiter對象列表( 每個等待鎖的線程都會被封裝成ObjectWaiter對象)，_owner指向持有ObjectMonitor對象的線程，當多個線程同時訪問一段同步代碼時，首先會進入 _EntryList 集合，當線程獲取到對象的monitor 后進入 _Owner 區域並把monitor中的owner變量設置為當前線程同時monitor中的計數器count加1，若線程調用 wait() 方法，將釋放當前持有的monitor，owner變量恢復為null，count自減1，同時該線程進入 WaitSe t集合中等待被喚醒。若當前線程執行完畢也將釋放monitor(鎖)並復位變量的值，以便其他線程進入獲取monitor(鎖)。如下圖所示
由此看來，monitor對象存在於每個Java對象的對象頭中(存儲的指針的指向)，synchronized鎖便是通過這種方式獲取鎖的，也是為什么Java中任意對象可以作為鎖的原因，同時也是notify/notifyAll/wait等方法存在於頂級對象Object中的原因(關於這點稍后還會進行分析)，ok~，有了上述知識基礎后，下面我們將進一步分析synchronized在字節碼層面的具體語義實現。
對象頭的另外一部分是類型指針，即是對象指向它的類的元數據的指針，虛擬機通過這個指針來確定這個對象是哪個類的實例。並不是所有的虛擬機實現都必須在對象數據上保留類型指針，換句話說查找對象的元數據信息並不一定要經過對象本身。另外，如果對象是一個Java數組，那在對象頭中還必須有一塊用於記錄數組長度的數據，因為虛擬機可以通過普通Java對象的元數據信息確定Java對象的大小，但是從數組的元數據中無法確定數組的大小。
以下是HotSpot虛擬機markOop.cpp中的C++代碼（注釋）片段，它描述了32bits下MarkWord的存儲狀態：
// Bit-format of an object header (most significant first, big endian layout below): // // 32 bits: // -------- // hash:25 ------------>| age:4 biased_lock:1 lock:2 (normal object) // JavaThread*:23 epoch:2 age:4 biased_lock:1 lock:2 (biased object) // size:32 ------------------------------------------>| (CMS free block) // PromotedObject*:29 ---------->| promo_bits:3 ----->| (CMS promoted object)
1.2、實例數據（Instance Data）
接下來實例數據部分是對象真正存儲的有效信息，也既是我們在程序代碼里面所定義的各種類型的字段內容，無論是從父類繼承下來的，還是在子類中定義的都需要記錄下來。 這部分的存儲順序會受到虛擬機分配策略參數（FieldsAllocationStyle）和字段在Java源碼中定義順序的影響。HotSpot虛擬機 默認的分配策略為longs/doubles、ints、shorts/chars、bytes/booleans、oops（Ordinary Object Pointers），從分配策略中可以看出，相同寬度的字段總是被分配到一起。在滿足這個前提條件的情況下，在父類中定義的變量會出現在子類之前。如果 CompactFields參數值為true（默認為true），那子類之中較窄的變量也可能會插入到父類變量的空隙之中。
1.3、對齊填充（Padding）
第三部分對齊填充並不是必然存在的，也沒有特別的含義，它僅僅起着占位符的作用。由於HotSpot VM的自動內存管理系統要求對象起始地址必須是8字節的整數倍，換句話說就是對象的大小必須是8字節的整數倍。對象頭正好是8字節的倍數（1倍或者2倍），因此當對象實例數據部分沒有對齊的話，就需要通過對齊填充來補全。
二、對象的創建過程
Java是一門面向對象的編程語言，Java程序運行過程中無時無刻都有對象被創建出來。在語言層面上，創建對象通常（例外：克隆、反序列化）僅僅是一個 new關鍵字而已，而在虛擬機中，對象（本文中討論的對象限於普通Java對象，不包括數組和Class對象等）的創建又是怎樣一個過程呢？
虛擬機遇到一條new指令時，
1、首先jvm要檢查類A是否已經被加載到了內存，即類的符號引用是否已經在常量池中，並且檢查這個符號引用代表的類是否已被加載、解析和初始化過的。如果還沒有，需要先觸發類的加載、解析、初始化。然后在堆上創建對象。
2、為新生對象分配內存。
對象所需內存的大小在類加載完成后便可完全確定，為對象分配空間的任務具體便等同於一塊確定大小 的內存從Java堆中划分出來，怎么划呢？假設Java堆中內存是絕對規整的，所有用過的內存都被放在一邊，空閑的內存被放在另一邊，中間放着一個指針作 為分界點的指示器，那所分配內存就僅僅是把那個指針向空閑空間那邊挪動一段與對象大小相等的距離，這種分配方式稱為“指針碰撞”（Bump The Pointer）。如果Java堆中的內存並不是規整的，已被使用的內存和空閑的內存相互交錯，那就沒有辦法簡單的進行指針碰撞了，虛擬機就必須維護一個列表，記錄上哪些內存塊是可用的，在分配的時候從列表中找到一塊足夠大的空間划分給對象實例，並更新列表上的記錄，這種分配方式稱為“空閑列表”（Free List）。選擇哪種分配方式由Java堆是否規整決定，而Java堆是否規整又由所采用的垃圾收集器是否帶有壓縮整理功能決定。因 此在使用Serial、ParNew等帶Compact過程的收集器時，系統采用的分配算法是指針碰撞，而使用CMS這種基於Mark-Sweep算法的 收集器時（說明一下，CMS收集器可以通過UseCMSCompactAtFullCollection或 CMSFullGCsBeforeCompaction來整理內存），就通常采用空閑列表。
除如何划分可用空間之外，還有另外一個需要考慮的問題是對象創建在虛擬機中是非常頻繁的行為，即使是僅僅修改一個指針所指向的位置，在並發情況下也並不是 線程安全的，可能出現正在給對象A分配內存，指針還沒來得及修改，對象B又同時使用了原來的指針來分配內存。解決這個問題有兩個方案，一種是對分配內存空 間的動作進行同步——實際上虛擬機是采用CAS配上失敗重試的方式保證更新操作的原子性；另外一種是把內存分配的動作按照線程划分在不同的空間之中進行， 即每個線程在Java堆中預先分配一小塊內存，稱為本地線程分配緩沖區，（TLAB ，Thread Local Allocation Buffer），哪個線程要分配內存，就在哪個線程的TLAB上分配，只有TLAB用完，分配新的TLAB時才需要同步鎖定。虛擬機是否使用TLAB，可以通過-XX:+/-UseTLAB參數來設定。
3. 完成實例數據部分的初始化工作（初始化為0值）
內存分配完成之后，虛擬機需要將分配到的內存空間都初始化為零值（不包括對象頭），如果使用TLAB的話，這一個工作也可以提前至TLAB分配時進行。這 步操作保證了對象的實例字段在Java代碼中可以不賦初始值就直接使用，程序能訪問到這些字段的數據類型所對應的零值。
4、 完成對象頭的填充：如對象自身的運行時數據、類型指針等。
接下來，虛擬機要對對象進行必要的設置，例如這個對象是哪個類的實例、如何才能找到類的元數據信息、對象的哈希碼、對象的GC分代年齡等信息。這些信息存放在對象的對象頭（Object Header）之中。根據虛擬機當前的運行狀態的不同，如是否啟用偏向鎖等，對象頭會有不同的設置方式。
在上面工作都完成之后，在虛擬機的視角來看，一個新的對象已經產生了。但是在Java程序的視角看來，初始化才正式開始，開始調用<init>方法完成初始復制和構造函數，所有的字段都為零值。因此一般來說（由字節碼中是否跟隨有invokespecial指令所決定），new指令之后會接着就是執 行<init>方法，把對象按照程序員的意願進行初始化，這樣一個真正可用的對象才算完全創建出來。
下面代碼是HotSpot虛擬機bytecodeInterpreter.cpp中的代碼片段（這個解釋器實現很少機會實際使用，大部分平台上都使用模板 解釋器；當代碼通過JIT編譯器執行時差異就更大了。不過這段代碼用於了解HotSpot的運作過程是沒有什么問題的）。
// 確保常量池中存放的是已解釋的類 if (!constants->tag_at(index).is_unresolved_klass()) { // 斷言確保是klassOop和instanceKlassOop（這部分下一節介紹） oop entry = (klassOop) *constants->obj_at_addr(index); assert(entry->is_klass(), "Should be resolved klass"); klassOop k_entry = (klassOop) entry; assert(k_entry->klass_part()->oop_is_instance(), "Should be instanceKlass"); instanceKlass* ik = (instanceKlass*) k_entry->klass_part(); // 確保對象所屬類型已經經過初始化階段 if ( ik->is_initialized() && ik->can_be_fastpath_allocated() ) { // 取對象長度 size_t obj_size = ik->size_helper(); oop result = NULL; // 記錄是否需要將對象所有字段置零值 bool need_zero = !ZeroTLAB; // 是否在TLAB中分配對象 if (UseTLAB) { result = (oop) THREAD->tlab().allocate(obj_size); } if (result == NULL) { need_zero = true; // 直接在eden中分配對象 retry: HeapWord* compare_to = *Universe::heap()->top_addr(); HeapWord* new_top = compare_to + obj_size; // cmpxchg是x86中的CAS指令，這里是一個C++方法，通過CAS方式分配空間，並發失敗的話，轉到retry中重試直至成功分配為止 if (new_top <= *Universe::heap()->end_addr()) { if (Atomic::cmpxchg_ptr(new_top, Universe::heap()->top_addr(), compare_to) != compare_to) { goto retry; } result = (oop) compare_to; } } if (result != NULL) { // 如果需要，為對象初始化零值 if (need_zero ) { HeapWord* to_zero = (HeapWord*) result + sizeof(oopDesc) / oopSize; obj_size -= sizeof(oopDesc) / oopSize; if (obj_size > 0 ) { memset(to_zero, 0, obj_size * HeapWordSize); } } // 根據是否啟用偏向鎖，設置對象頭信息 if (UseBiasedLocking) { result->set_mark(ik->prototype_header()); } else { result->set_mark(markOopDesc::prototype()); } result->set_klass_gap(0); result->set_klass(k_entry); // 將對象引用入棧，繼續執行下一條指令 SET_STACK_OBJECT(result, 0); UPDATE_PC_AND_TOS_AND_CONTINUE(3, 1); } } }
三、對象的訪問定位
建立對象是為了使用對象，我們的Java程序需要通過棧上的reference數據來操作堆上的具體對象。由於reference類型在Java虛擬機規范里面只規定了是一個指向對象的引用，並沒有定義這個引用應該通過什么種方式去定位、訪問到堆中的對象的具體位置，對象訪問方式也是取決於虛擬機實現而定的。主流的訪問方式有使用句柄和直接指針兩種。
如果使用句柄訪問的話，Java堆中將會划分出一塊內存來作為句柄池，reference中存儲的就是對象的句柄地址，而句柄中包含了對象實例數據與類型數據的具體各自的地址信息。如圖1所示。
圖1 通過句柄訪問對象
如果使用直接指針訪問的話，Java堆對象的布局中就必須考慮如何放置訪問類型數據的相關信息，reference中存儲的直接就是對象地址，如圖2所示。
圖2 通過直接指針訪問對象
這兩種對象訪問方式各有優勢，使用句柄來訪問的最大好處就是reference中存儲的是穩定句柄地址，在對象被移動（垃圾收集時移動對象是非常普遍的行為）時只會改變句柄中的實例數據指針，而reference本身不需要被修改。
使用直接指針來訪問最大的好處就是速度更快，它節省了一次指針定位的時間開銷，由於對象訪問的在Java中非常頻繁，因此這類開銷積小成多也是一項非常可觀的執行成本。從上一部分講解的對象內存布局可以看出，就虛擬機HotSpot而言，它是使用第二種方式進行對象訪問，但在整個軟件開發的范圍來看，各種語言、框架中使用句柄來訪問的情況也十分常見。
四、示例
在Hotspot JVM中，32位機器下，Integer對象的大小是int的幾倍？
我們都知道在Java語言規范已經規定了int的大小是4個字節，那么Integer對象的大小是多少呢？要知道一個對象的大小，那么必須需要知道對象在虛擬機中的結構是怎樣的，根據上面的圖，那么我們可以得出Integer的對象的結構如下：
Integer只有一個int類型的成員變量value，所以其對象實際數據部分的大小是4個字節，然后再在后面填充4個字節達到8字節的對齊，所以可以得出Integer對象的大小是16個字節。
因此，我們可以得出Integer對象的大小是原生的int類型的4倍。
關於對象的內存結構，需要注意數組的內存結構和普通對象的內存結構稍微不同，因為數據有一個長度length字段，所以在對象頭后面還多了一個int類型的length字段，占4個字節，接下來才是數組中的數據，如下圖：
關於對象內存布局更多的內容，可以看這篇文章：Java Objects Memory Structure