1. 程式人生 > >Java虛擬機器學習筆記(一):記憶體區域與HotSpot虛擬機器物件探祕

Java虛擬機器學習筆記(一):記憶體區域與HotSpot虛擬機器物件探祕

執行時資料區域

Java虛擬機器在執行Java程式的過程中會把它所管理的記憶體劃分為若干個不同的資料區域。這些區域都有各自的用途,以及建立和銷燬的時間,有的區域隨著虛擬機器程序的啟動而存在,有些區域則依賴使用者執行緒的啟動和結束而建立和銷燬。根據《Java虛擬機器規範(Java SE 7版)》的規定,Java虛擬機器所管理的記憶體將會包括以下幾個執行時資料區域: Java虛擬機器執行時資料區

程式計數器(執行緒私有)

程式計數器是一塊較小的記憶體空間,它可以看作是當前執行緒所執行的位元組碼的行號指示器在虛擬機器概念模型中,位元組碼直譯器工作時就是通過改變這個計數器的值來選取下一條需要執行的位元組碼指令,分支、迴圈、跳轉、異常處理、執行緒恢復等基礎功能都需要依賴這個計數器來完成。

由於Java虛擬機器的多執行緒是通過執行緒輪流切換並分配處理器執行時間的方式來實現的,在任何一個確定的時刻,一個處理器都只會執行一條執行緒中的指令。因此,為了執行緒切換後能恢復到正確的執行位置,每條執行緒都需要有一個獨立的程式計數器,各條執行緒之間計數器互不影響,獨立儲存

如果執行緒正在執行的是一個Java方法,這個計數器記錄的是正在執行的虛擬機器位元組碼指令的地址;如果正在執行的是Native方法,這個計數器值則為空。此記憶體區域是唯一一個在Java虛擬機器規範中沒有規定任何OutOfMemoryError情況的區域

Java虛擬機器棧(執行緒私有)

虛擬機器棧描述的是Java方法執行的記憶體模型:每個方法在執行的同時都會建立一個棧幀(Stack Frame)用於儲存區域性變量表、運算元棧、動態連結、方法出口等資訊

。每一個方法從呼叫直至執行完成的過程,就對應著一個棧幀在虛擬機器棧中入棧到出棧的過程。

棧幀是方法執行時的基礎資料結構

經常有人把Java記憶體區分為堆記憶體(Heap)和棧記憶體(Stack),Java記憶體區域實際上比這複雜的多,這種劃分方式的流行只能說明大多數程式設計師最關注的、與物件記憶體分配關係最密切的記憶體區域是這兩塊。其中 “棧”就是現在講的虛擬機器棧,或者說是虛擬機器棧中區域性變量表部分

區域性變量表存放了編譯期可知的各種基本資料型別(boolean、byte、char、short、int、float、long、double)、物件引用(reference型別,他不等同於物件本身,可能是一個指向物件起始地址的應用指標,也可能是指向一個代表物件的控制代碼或其他與此物件相關的位置)和returnAddress型別

(指向了一條位元組碼指令的地址)。

需要注意的是區域性變量表所需的記憶體空間在編譯期間完成分配,當進入一個方法時,這個方法需要在幀中分配多大的區域性變數空間是完全確定的,在方法執行期間不會改變

其中64位長度的long和double型別的資料會佔用2個區域性變數空間(Slot),其餘的資料型別只佔用1個。

在Java虛擬機器規範中,對這個區域規定了兩種異常情況: (1)如果執行緒請求的棧深度大於虛擬機器所允許的深度,將丟擲StackOverflowError異常 (2)如果虛擬機器棧可以動態擴充套件,在擴充套件時無法申請到足夠的記憶體,就會丟擲OutOfMemoryError異常

本地方法棧

本地方法棧為虛擬機器使用到的Native方法服務,也會丟擲StackOverflowError和OutOfMemoryError異常。

Java堆(GC堆)

Java堆是Java虛擬機器所管理的記憶體中最大的一塊。Java堆是被所有執行緒共享的一塊記憶體區域,在虛擬機器啟動時建立。此記憶體區域的唯一目的就是存放物件例項,幾乎所有的物件例項都在這裡分配記憶體。

Java堆是垃圾收集器管理的主要區域,因此很多時候也被稱為“GC堆”。從記憶體回收的角度來看,由於現在收集器基本都採用分代收集演算法,所以Java堆中還可以細分為:新生代和老年代;再細緻一點的有Eden空間、From Survivor空間、To Survivor空間等。從記憶體分配的角度來看,執行緒共享的Java堆中可能劃分出多個執行緒私有的分配緩衝區。

根據Java虛擬機器規範的規定,Java堆可以處於物理上不連續的記憶體空間中,只要邏輯上是連續的即可。當前主流的虛擬機器都是按照可擴充套件來實現的(通過-Xmx和-Xms控制)。如果在堆中沒有記憶體完成例項分配,並且堆也無法再擴充套件時,將會丟擲OutOfMemoryError異常。

方法區(別名Non-Heap)

方法區和Java堆一樣,是各個執行緒共享的記憶體區域,它用於儲存已被虛擬機器載入的類資訊、常量、靜態變數、即時編譯器編譯後的程式碼等資料。

根據Java虛擬機器規範的規定,當方法區無法滿足記憶體分配需求時,將丟擲OutOfMemoryError。

執行時常量池

和Class檔案中的常量池是不同概念

執行時常量池是方法區的一部分。Class檔案中除了有類的版本、欄位、方法、介面等描述資訊外,還有一項資訊是常量池,用於存放編譯期生成的各種字面量和符號引用,這部分內容將在類載入後進入方法區的執行時常量池中存放

Java虛擬機器對Class檔案每一部分(包括常量池)的格式都有嚴格規定,每一個位元組用於儲存哪種資料都必須符合規範上的要求才會被虛擬機器認可、裝載和執行,但對於執行時常量池,Java虛擬機器規範沒有做任何細節的要求,不同的提供商實現的虛擬機器可以按照自己的需求來實現這個記憶體區域。不過,一般來說,除了儲存Class檔案中描述的符號引用外,還會把翻譯出來的直接引用也儲存在執行時常量池中

執行時常量池相對於Class檔案常量池的另外一個重要特徵是具備動態性,Java語言並不要求常量一定只有編譯期才能生成,也就是並非預置入Class檔案中常量池的內容才能進入方法區執行時常量池,執行期間也可能將新的常量放入池中。

當常量池無法再申請到記憶體時會丟擲OutOfMemoryError異常。

直接記憶體

在JDK 1.4中新加入了NIO(New Input/Output)類,引入了一種基於通道(Channel)與緩衝區(Buffer)的I/O方式,它可以使用Native函式庫直接分配堆外記憶體,然後通過一個儲存在Java堆中的DirectByteBuffer物件作為這塊記憶體的引用進行操作。本機直接記憶體的分配不受Java堆大小的限制,但是,既然是記憶體,肯定還是會受到本機總記憶體大小以及處理器定址空間的限制。

HotSpot虛擬機器物件探祕

物件的建立通常僅僅是一個new關鍵字而已,而在虛擬機器中,物件(限於普通Java物件,不包括陣列和Class物件等)的建立一般包含5個步驟: (1)檢查這個指令的引數是否能在常量池中定位到一個類的符號引用,並且檢查這個符號引用代表的類是否已被載入、解析和初始化過。如果沒有,那必須先執行相應的類載入過程。 (2)在類載入檢查通過後,虛擬機器將為新生物件分配記憶體。物件所需記憶體的大小在類載入完成後便可完全確定,為物件分配空間的任務等同於把一塊確定大小的記憶體從Java堆中劃分出來。

指標碰撞:假設Java堆中記憶體是絕對規整的,所有用過的記憶體都放在一邊,空閒的記憶體放在另一邊,中間放著一個指標作為分界點的指示器,那所分配記憶體就僅僅是把那個指標向空閒空間那邊挪動一段與物件大小相等的距離。 空閒列表:如果Java堆中的記憶體並不是規整的,已使用的記憶體和空閒的記憶體相互交錯,虛擬機器必須維護一個列表,記錄哪些記憶體塊是可用的,在分配的時候從列表中找到一塊足夠大的空間劃分給物件例項,並更新列表上的記錄。

選擇哪種分配方式由Java堆是否規整決定,而Java堆是否規整又由所採用的垃圾收集器是否帶有壓縮整理功能決定。因此,Serial、ParNew等帶Compact過程的收集器採用的分配演算法是指標碰撞,而CMS這種基於Mark-Sweep演算法的收集器通常採用空閒列表。

除了空間的劃分,我們還需要處理一下併發情況。解決方案有兩種:

  • 一種是對分配記憶體空間的動作進行同步處理–實際上虛擬機器採用CAS配上失敗重試的方式保證更新操作的原子性;
  • 另一種是把記憶體分配的動作按照執行緒劃分在不同的空間之中進行,即每個執行緒在Java堆中預先分配一小塊記憶體,稱為本地執行緒分配緩衝(Thread Local Allocation Buffer,TLAB)。只有TLAB用完並分配新的TLAB時,才需要同步鎖定,虛擬機器是否使用TLAB,可以通過-XX:+/-UseTLAB引數來設定

(3)將分配到的記憶體空間都初始化為零值(不包括物件頭),如果使用TLAB,這一工作過程也可以提前至TLAB分配時進行。這一步操作保證了物件例項欄位在Java程式碼中可以不賦初始值就直接使用。 (4)對物件進行必要的設定,例如這個物件是哪個類的例項、如何才能找到類的元資料資訊、物件的雜湊嗎、物件的GC分代年齡等資訊。這些資訊存放在物件的物件頭之中。 (5)執行new指令之後會接著執行< init>方法,把物件按照程式設計師的意願進行初始化,這樣一個真正可用的物件才算完全產生出來。即所有欄位先全部初始化為對應零值,再通過init初始化為所設定的對應值。

物件的記憶體佈局

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

物件頭

物件頭包括兩部分資訊:

  • 用於儲存物件自身的執行時資料,如雜湊碼、GC分代年齡、鎖狀態標誌、執行緒持有的鎖、偏向執行緒ID、偏向時間戳等。
  • (非必須)型別指標,即物件指向它的類元資料的指標,虛擬機器通過這個指標來確定這個物件是哪個類的例項。如果物件是Java陣列,那在物件頭中還必須有一塊用於記錄陣列長度的資料,因為虛擬機器可以通過普通Java物件的元資料資訊確定Java物件的大小,但是從陣列的元資料卻無法確定陣列的大小。

例項資料

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

對齊填充

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

物件的訪問定位

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

使用控制代碼

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

直接指標

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

  • 使用控制代碼來訪問的最大好處: reference中儲存的是穩定的控制代碼地址,在物件被移動(垃圾收集時移動物件是非常普遍的行為)時只會改變控制代碼中的例項資料指標,而reference本身不需要修改。
  • 使用直接指標訪問方式的最大好處: 速度更快,它節省了一次指標定位的時間開銷,由於物件的訪問在Java中非常頻繁,因此這類開銷積少成多後也是一項非常可觀的執行成本。Sun HotSpot是使用的直接指標的方式進行物件的訪問。