[深入理解Java虛擬機器]第二章 HotSpot虛擬機器物件探祕

介紹完Java虛擬機器的執行時資料區之後,我們大致知道了虛擬機器記憶體的概況,讀者瞭解了記憶體中放了些什麼後,也許就會想更進一步瞭解這些虛擬機器記憶體中的資料的其他細節,譬如它們是如何建立、如何佈局以及如何訪問的。對於這樣涉及細節的問題,必須把討論範圍限定在具體的虛擬機器和集中在某一個記憶體區域上才有意義。基於實用優先的原則,筆者以常 用的虛擬機器HotSpot和常用的記憶體區域Java堆 為 例 ,深入探討HotSpot虛擬機器在Java堆中物件分配、佈局和訪問的全過程。

物件的建立

Java是一門物件導向的程式語言,在Java程式執行過程中無時無刻都有物件被建立出來。在語言層面上,建立物件(例如克隆、反序列化)通常僅僅是一個new關鍵字而已,而在虛擬機器中,物件(文中討論的物件限於普通Java物件,不包括陣列和Class物件等)的建立又是怎樣一個過程呢?

虛擬機器遇到一條new指令時 ,首先將去檢查這個指令的引數是否能在常量池中定位到一個類的符號引用,並且檢查這個符號引用代表的類是否已被載入、解析和初始化過。如果沒有 ,那必須先執行相應的類載入過程。

在類載入檢查通過後,接下來虛擬機器將為新生物件分配記憶體。物件所需記憶體的大小在類載入完成後便可完全確定,為物件分配空間的任務等同於把一塊確定大小的記憶體從Java堆中劃分出來。假設Java堆中記憶體是絕對規整的,所有用過的記憶體都放在一邊,空閒的記憶體放在另一邊,中間放著一個指標作為分界點的指示器,那所分配記憶體就僅僅是把那個指標向空閒空間那邊挪動一段與物件大小相等的距離,這種分配方式稱 為“指標碰撞” ( Bump the Pointer ) 。如果Java堆中的記憶體並不是規整的,已使用的記憶體和空閒的記憶體相互交錯,那就沒有辦法簡單地進行指標碰撞了,虛擬機器就必須維護一個列表,記錄上哪些記憶體塊是可用的,在分配的時候從列表中找到一塊足夠大的空間劃分給物件例項, 並更新列表上的記錄,這種分配方式稱為“空閒列表” ( Free List)。選擇哪種分配方式由 Java堆是否規整決定,而Java堆是否規整又由所採用的垃圾收集器是否帶有壓縮整理功能決定。因此 ,在使用Serial、ParNew等帶Compact過程的收集器時,系統採用的分配演算法是指標碰撞 ,而使用CMS這種基於Mark-Sweep演算法的收集器時,通常採用空閒列表。

除如何劃分可用空間之外,還有另外一個需要考慮的問題是物件建立在虛擬機器中是非常頻繁的行為,即使是僅僅修改一個指標所指向的位置,在併發情況下也並不是執行緒安全的, 可能出現正在給物件A分配記憶體,指標還沒來得及修改,物件B又同時使用了原來的指標來分配記憶體的情況。解決這個問題有兩種方案,一種是對分配記憶體空間的動作進行同步處理——實際上虛擬機器採用CAS配上失敗重試的方式保證更新操作的原子性;另一種是把記憶體分配的動作按照執行緒劃分在不同的空間之中進行,即每個執行緒在Java堆中預先分配一小塊記憶體 ,稱為本地執行緒分配緩衝(Thread Local Allocation Buffer,TLAB ) 。哪個執行緒要分配記憶體 ,就在哪個執行緒的TLAB上分配,只有TLAB用完並分配新的TLAB時 ,才需要同步鎖定。 虛擬機器是否使用TLAB,可以通過-XX : +/-UseTLAB引數來設定。

記憶體分配完成後,虛擬機器需要將分配到的記憶體空間都初始化為零值(不包括物件頭), 如果使用TLAB ,這一工作過程也可以提前至TLAB分配時進行。這一步操作保證了物件的例項欄位在Java程式碼中可以不賦初始值就直接使用,程式能訪問到這些欄位的資料型別所對應的零值。

接下來 ,虛擬機器要對物件進行必要的設定,例如這個物件是哪個類的例項、如何才能找到類的後設資料資訊、物件的雜湊碼、物件的GC分代年齡等資訊。這些資訊存放在物件的物件頭(Object Header ) 之中。根據虛擬機器當前的執行狀態的不同,如是否啟用偏向鎖等,物件頭會有不同的設定方式。關於物件頭的具體內容,稍後再做詳細介紹。

在上面工作都完成之後,從虛擬機器的視角來看,一個新的物件已經產生了,但從Java程式的視角來看,物件建立才剛剛開始——<init>方法還沒有執行,所有的欄位都還為零。 所以,一般來說(由位元組碼中是否跟隨invokespecial指令所決定),執行new指令之後會接著 執行<init>方法,把物件按照程式設計師的意願進行初始化,這樣一個真正可用的物件才算完全產生出來。

物件的記憶體佈局

在HotSpot虛擬機器中,物件在記憶體中儲存的佈局可以分為3塊區域:物件頭( Header )、例項資料( Instance Data ) 和對齊填充( Padding )。

HotSpot虛擬機器的物件頭包括兩部分資訊,第一部分用於儲存物件自身的執行時資料, 如雜湊碼(HashCode)、GC分代年齡、鎖狀態標誌、執行緒持有的鎖、偏向執行緒ID、偏向時間戳等 ,這部分資料的長度在32位和64位的虛擬機器(未開啟壓縮指標)中分別為32bit和64bit,官方稱它為“Mark Word”。物件需要儲存的執行時資料很多,其實已經超出了32位、 64位BitMap結構所能記錄的限度,但是物件頭資訊是與物件自身定義的資料無關的額外儲存成本,考慮到虛擬機器的空間效率, Mark Word被設計成一個非固定的資料結構以便在極小的空間記憶體儲儘量多的資訊,它會根據物件的狀態複用自己的儲存空間。例如 ,在32位的HotSpot虛擬機器中,如果物件處於未被鎖定的狀態下,那麼Mark Word的32bit空間中的25bit用於儲存物件雜湊碼,4bit用於儲存物件分代年齡,2bit用於儲存鎖標誌位,1bit固定為0 ,而在其他狀態(輕量級鎖定、重量級鎖定、GC標記、可偏向)下物件的儲存內容見表2-1。

物件頭的另外一部分是型別指標,即物件指向它的類後設資料的指標,虛擬機器通過這個指標來確定這個物件是哪個類的例項。並不是所有的虛擬機器實現都必須在物件資料上保留型別指標,換句話說,查詢物件的後設資料資訊並不一定要經過物件本身,這點將在2.3.3節討論。 另外 ,如果物件是一個Java陣列 ,那在物件頭中還必須有一塊用於記錄陣列長度的資料,因為虛擬機器可以通過普通Java物件的後設資料資訊確定Java物件的大小,但是從陣列的後設資料中卻無法確定陣列的大小。

程式碼清單2-2為HotSpot虛擬機器markOop.cpp中的程式碼(註釋 )片 段 ,它描述了32bit下MarkWord的儲存狀態。
程式碼清單2-2 markOop.cpp片段

接下來的例項資料部分是物件真正儲存的有效資訊,也是在程式程式碼中所定義的各種型別的欄位內容。無論是從父類繼承下來的,還是在子類中定義的,都需要記錄起來。這部分的儲存順序會受到虛擬機器分配策略引數( FieldsAllocationStyle ) 和欄位在Java原始碼中定義順序的影響。HotSpot虛擬機器預設的分配策略為longs/doubles、ints、shorts/chars、bytes/booleans、 oops ( Ordinary Object Pointers ) , 從分配策略中可以看出,相同寬度的欄位總是被分配到一起。在滿足這個前提條件的情況下,在父類中定義的變數會出現在子類之前。如果CompactFields引數值為true ( 預設為true ) ,那麼子類之中較窄的變數也可能會插入到父類變數的空隙之中。

第三部分對齊填充並不是必然存在的,也沒有特別的含義,它僅僅起著佔位符的作用。 由於HotSpot VM的自動記憶體管理系統要求物件起始地址必須是8位元組的整數倍,換句話說, 就是物件的大小必須是8位元組的整數倍。而物件頭部分正好是8位元組的倍數(1倍或者2倍 ), 因此 ,當物件例項資料部分沒有對齊時,就需要通過對齊填充來補全。

物件的訪問定位

建立物件是為了使用物件,我們的Java程式需要通過棧上的reference資料來操作堆上的具體物件。由於reference型別在Java虛擬機器規範中只規定了一個指向物件的引用,並沒有定義這個引用應該通過何種方式去定位、訪問堆中的物件的具體位置,所以物件訪問方式也是取決於虛擬機器實現而定的。目前主流的訪問方式有使用控制程式碼和直接指標兩種。

如果使用控制程式碼訪問的話,那麼Java堆中將會劃分出一塊記憶體來作為句池,reference中儲存的就是物件的控制程式碼地址,而控制程式碼中包含了物件例項資料與型別資料各自的具體地址資訊 ,如圖2-2所示。

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

這兩種物件訪問方式各有優勢,使用控制程式碼來訪問的最大好處就是reference中儲存的是穩定的控制程式碼地址,在物件被移動(垃圾收集時移動物件是非常普遍的行為)時只會改變控制程式碼中的例項資料指標,而reference本身不需要修改。

使用直接指標訪問方式的最大好處就是速度更快,它節省了一次指標定位的時間開銷, 由於物件的訪問在Java中非常頻繁,因此這類開銷積少成多後也是一項非常可觀的執行成本。就本書討論的主要虛擬機器Sun HotSpot而言,它是使用第二種方式進行物件訪問的,但從整個軟體開發的範圍來看,各種語言和框架使用控制程式碼來訪問的情況也十分常見。