JVM中的對象內存布局？

在 Java 程序中，我們擁有多種新建對象的方式。除了最為常見的 new 語句之外，我們還可以通過反射機制、Object.clone 方法、反序列化以及 Unsafe.allocateInstance 方法來新建對象。

其中，Object.clone 方法和反序列化通過直接複製已有的數據，來初始化新建對象的實例欄位。

Unsafe.allocateInstance 方法則沒有初始化實例欄位，而 new 語句和反射機制，則是通過調用構造器來初始化實例欄位。

我們先來考察new語句，準備一個類，如下圖所示

讓我們編譯他的位元組碼：

可以看到，new語句編譯而成的位元組碼將包含用來請求內存的 new 指令，以及用來調用構造器的 invokespecial 指令。

本文不是專門介紹invoke系列指令的，我會在後面的文章中介紹invoke系列指令。

不過在這裡我多說一嘴，位元組碼中的invokespecial指令通常用於調用私有實例方法、構造器，以及使用super關鍵字調用父類的實例方法或構造器，和所實現介面的默認方法。

提到構造器，就不得不提到 Java 對構造器的諸多約束。首先，如果一個類沒有定義任何構造器的話， Java 編譯器會自動添加一個無參數的構造器。

我們剛才的TestNew類，他的位元組碼編譯出來後，有下面的片段。

在JAVA源碼中，我們沒有定義構造器，但是生成出來的位元組碼，已經自動幫我們添加了一個無參數的構造器。他使用的invokespecial方法最終調用的是其父類Object類的構造器方法。

我將講述JVM的構造器調用原則，那就是，如果子類的構造器需要調用父類的構造器。如果父類存在無參數構造器的話，該調用可以是隱式的。也就是說， Java 編譯器會自動添加對父類構造器的調用。

但是，如果父類沒有無參數構造器，那麼子類的構造器則需要顯式地調用父類帶參數的構造器。

顯式調用有兩種，一是直接使用「super」關鍵字調用父類構造器，二是使用「this」關鍵字調用同一個類中的其他構造器。

無論是直接的顯式調用，還是間接的顯式調用，都需要作為構造器的第一條語句，以便優先初始化繼承而來的父類欄位。

可以不優先初始化繼承來的父類欄位嗎?可以，如果你能使用位元組碼注入工具的話。

當我們調用一個構造器時，它將優先調用父類的構造器，直至 Object 類。這些構造器的調用者皆為同一對象，也就是通過 new 指令新建而來的對象。

事實上，我上面的陳述意味著：通過 new 指令新建出來的對象，它的內存其實涵蓋了所有父類中的實例欄位。

也就是說，雖然子類無法訪問父類的私有實例欄位，或者子類的實例欄位隱藏了父類的同名實例欄位，但是子類的實例還是會為這些父類實例欄位分配內存的。

下面我將介紹壓縮指針技術。在 Java 虛擬機中，每個 Java 對象都有一個對象頭，它由標記欄位和類型指針所構成。

標記欄位用以存儲 Java 虛擬機有關該對象的運行數據，如哈希碼、GC 信息以及鎖信息，而類型指針則指向該對象的類。

在64位的JVM中，對象頭的標記欄位占 64 位，而類型指針又佔了 64 位。也就是說，每一個 Java 對象在內存中的額外開銷就是 16 個位元組。

為了盡量較少對象的內存使用量，64位JVM引入了壓縮指針的概念，將堆中原本64位的Java對象指針壓縮成32位的。

這樣一來，對象頭中的類型指針也會被壓縮成32位，使得對象頭的大小從16位元組降至12位元組。

當然，壓縮指針不僅可以作用於對象頭的類型指針，還可以作用於引用類型的欄位，以及引用類型數組。

它的原理是什麼?答案是內存對齊。

我們規定，默認情況下，JVM堆中對象的起始地址需要對齊至8的倍數，如果一個對象用不到8N 個位元組，那麼空白的那部分空間就浪費掉了，這些浪費掉的空間我們稱之為對象間的填充。

大家知道，指針裡面存放的是地址，由於堆中對象的起始地址是對齊至8的倍數，所以指針存放一個引用(或者對象的類)的內存地址時，根本就不用存放最後的三位二進位數。

因為所有對象或類的內存地址都對齊了8，所以他們的內存地址的最低三位總是0，32位的指針就可以定址到 2 的 35 次方個位元組，也就是 32GB 的地址空間(超過 32GB 則會關閉壓縮指針)。

我們可以通過配置虛擬機的內存對齊選項來進一步提升定址範圍。但是，這同時也可能增加對象間填充，導致壓縮指針沒有達到原本節省空間的效果。

就算是關閉了壓縮指針，Java 虛擬機還是會進行內存對齊。此外，內存對齊不僅存在於對象與對象之間，也存在於對象中的欄位之間。

比如說，Java 虛擬機要求long欄位、double欄位，以及非壓縮指針狀態下的引用欄位地址為8的倍數。

這是為什麼呢?

CPU的緩存行機制大家應該有所耳聞，如果欄位不是對齊的，那麼就有可能出現跨緩存行的欄位。

該欄位的讀取可能需要替換兩個緩存行，而該欄位的存儲也會同時污染兩個緩存行。

我們將在後期文章關於volatile關鍵詞的本質分析的過程中，再次考察到CPU緩存行的相關機制。

最後我要提一句的是，欄位重排列技術，就是我剛才提到的，對象的欄位之間存在的內存對齊。這指的是重新分配欄位的先後順序，以達到內存對齊的目的

它有以下兩個規則：

其一，如果一個欄位佔據C個位元組，那麼該欄位的偏移量需要對齊至NC。這裡的偏移量指的是欄位地址與對象的起始地址差值。

以Long類為例，它僅有一個long類型的實例欄位。在使用了壓縮指針的 64 位虛擬機中，儘管對象頭的大小為12個位元組，該 long 類型欄位的偏移量也只能是16，而中間空著的4個位元組便會被浪費掉

其二，子類所繼承欄位的偏移量，需要與父類對應欄位的偏移量保持一致。

說白了，比如B繼承了A，A是B的父類，A中所有的欄位，在B中都有，而且是先放A的欄位，再放B的欄位。而且B類對象放A類欄位時，需要與父類對應欄位的偏移量保持一致。

接下來我說一個拓展內容吧，什麼是虛共享?

假設兩個線程分別訪問同一對象中不同的 volatile 欄位，邏輯上它們並沒有共享內容，因此不需要同步。

如果這兩個欄位恰好在同一個緩存行中，那麼對這些欄位的寫操作會導致緩存行的寫回，也就造成了實質上的共享。

Java8還引入了一個新的注釋@Contended，用來解決對象欄位之間的虛共享。

Java 虛擬機會讓不同的@Contended欄位處於獨立的緩存行中，因此你會看到大量的空間被浪費掉，避免無謂的緩存行同步操作。

具體的演算法屬於實現細節了，大家有興趣可以去用：

-XX:-RestrictContended

這個虛擬機選項，查看Contended欄位的內存布局。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！