技術文章 » java類物件建立過程與jvm記憶體分佈詳解

java類物件建立過程與jvm記憶體分佈詳解

2020-08-13 16:06:31

jvm記憶體分佈

1. jvm體系結構

在这里插入图片描述

  • Class Loader類載入器
    負責載入 .class檔案，class檔案在檔案開頭有特定的檔案標示，並且ClassLoader負責class檔案的載入等，至於它是否可以執行，則由Execution Engine決定。
    　　① 定位和匯入二進制class檔案
    　　② 驗證匯入類的正確性
    　　③ 爲類分配初始化記憶體
    　　④ 幫助解析符號參照.
  • Native Interface本地介面
    本地介面的作用是融合不同的程式語言爲Java所用，它的初衷是融合C/C++程式，Java誕生的時候C/C++橫行的時候，要想立足，必須有呼叫C/C++程式，於是就在記憶體中專門開闢了一塊區域處理標記爲native的程式碼，它的具體作法是Native Method Stack中登記native方法，在Execution Engine執行時載入native libraies。目前該方法使用的越來越少了，除非是與硬體有關的應用，比如通過Java程式驅動印表機，或者Java系統管理生產裝置，在企業級應用中已經比較少見。因爲現在的異構領域間的通訊很發達，比如可以使用Socket通訊，也可以使用Web Service等。
  • Execution Engine 執行引擎
    執行包在裝載類的方法中的指令，也就是方法。
  • Runtime data area 執行數據區（即：虛擬機器記憶體或者JVM記憶體）
    從整個計算機記憶體中開闢一塊記憶體儲存Jvm需要用到的物件，變數等，分爲：方法區，堆，虛擬機器棧，程式計數器，本地方法棧。

2.JVM記憶體結構

在这里插入图片描述

  • 程式計數器 PC Register
    　　每個執行緒都有一個程式計算器，就是一個指針，指向方法區中的方法位元組碼（下一個將要執行的指令程式碼），由執行引擎讀取下一條指令，是一個非常小的記憶體空間，幾乎可以忽略不記。
    　　程式計數器（Program Counter Register）是一塊較小的記憶體空間，它的作用可以看做是當前執行緒所執行的位元組碼的行號指示器。在虛擬機器的概念模型裡（僅是概念模型，各種虛擬機器可能會通過一些更高效的方式去實現），位元組碼直譯器工作時就是通過改變這個計數器的值來選取下一條需要執行的位元組碼指令，分支、回圈、跳轉、例外處理、執行緒恢復等基礎功能都需要依賴這個計數器來完成。由於Java 虛擬機器的多執行緒是通過執行緒輪流切換並分配處理器執行時間的方式來實現的，在任何一個確定的時刻，一個處理器（對於多核處理器來說是一個內核）只會執行一條執行緒中的指令。因此，爲了執行緒切換後能恢復到正確的執行位置，每條執行緒都需要有一個獨立的程式計數器，各條執行緒之間的計數器互不影響，獨立儲存，我們稱這類記憶體區域爲「執行緒私有」的記憶體。如果執行緒正在執行的是一個Java 方法，這個計數器記錄的是正在執行的虛擬機器位元組碼指令的地址；如果正在執行的是Natvie 方法，這個計數器值則爲空（Undefined）。此記憶體區域是唯一一個在Java 虛擬機器規範中沒有規定任何OutOfMemoryError 情況的區域。
  • 本地方法棧 Native Method Stack
    　　Native Method Stack中登記native方法，在Execution Engine執行時載入native libraies
    　　本地方法棧與虛擬機器棧基本類似，區別在於虛擬機器棧爲虛擬機器執行的java方法服務，而本地方法棧則是爲Native方法服務
  • 方法區 Method Area
    　用於儲存虛擬機器載入的：靜態變數+常數+類資訊+執行時常數池 （類資訊：類的版本、欄位、方法、介面、建構函式等描述資訊 ）
    　　預設最小值爲16MB，最大值爲64MB，可以通過-XX:PermSize 和 -XX:MaxPermSize 參數限制方法區的大小
    　　對於習慣在HotSpot 虛擬機器上開發和部署程式的開發者來說，很多人願意把方法區稱爲「永久代」（Permanent Generation），本質上兩者並不等價，僅僅是因爲HotSpot 虛擬機器的設計團隊選擇把GC 分代收集擴充套件至方法區，或者說使用永久代來實現方法區而已。對於其他虛擬機器（如BEA JRockit、IBM J9 等）來說是不存在永久代的概唸的。即使是HotSpot 虛擬機器本身，根據官方發佈的路線圖資訊，現在也有放棄永久代並「搬家」至Native Memory 來實現方法區的規劃了。Java 虛擬機器規範對這個區域的限制非常寬鬆，除了和Java 堆一樣不需要連續的記憶體和可以選擇固定大小或者可延伸外，還可以選擇不實現垃圾收集。相對而言，垃圾收集行爲在這個區域是比較少出現的，但並非數據進入了方法區就如永久代的名字一樣「永久」存在了。這個區域的記憶體回收目標主要是針對常數池的回收和對型別的解除安裝，一般來說這個區域的回收「成績」比較難以令人滿意，尤其是型別的解除安裝，條件相當苛刻，但是這部分割區域的回收確實是有必要的。在Sun 公司的BUG 列表中，曾出現過的若幹個嚴重的BUG 就是由於低版本的HotSpot 虛擬機器對此區域未完全回收而導致記憶體漏失。根據Java 虛擬機器規範的規定，當方法區無法滿足記憶體分配需求時，將拋出OutOfMemoryError 異常。
  • 棧 JVM Stack
    　　編譯器可知的各種基本數據型別(boolean、byte、char、short、int、float、long、double)、物件參照(參照指針，並非物件本身)
    　　棧是java 方法執行的記憶體模型：
    　　每個方法被執行的時候 都會建立一個「棧幀」用於儲存區域性變數表(包括參數)、操作棧、方法出口等資訊。
    　　每個方法被呼叫到執行完的過程，就對應着一個棧幀在虛擬機器棧中從入棧到出棧的過程。
    　　（區域性變數表：存放了編譯器可知的各種基本數據型別(boolean、byte、char、short、int、float、long、double)、物件參照(參照指針，並非物件本身)，
    　　其中64位元長度的long和double型別的數據會佔用2個區域性變數的空間，其餘數據型別只佔1個。
    　　區域性變數表所需的記憶體空間在編譯期間完成分配，當進入一個方法時，這個方法需要在棧幀中分配多大的區域性變數是完全確定的，在執行期間棧幀不會改變區域性變數表的大小空間）
    　　棧的生命期是跟隨執行緒的生命期，執行緒建立時建立，執行緒結束棧記憶體也就釋放，是執行緒私有的。
  • 堆 Java Heap
    　　所有的物件範例以及陣列都要在堆上分配，此記憶體區域的唯一目的就是存放物件範例
    　　堆是Java 虛擬機器所管理的記憶體中最大的一塊。Java 堆是被所有執行緒共用的一塊記憶體區域，在虛擬機器啓動時建立
    　　堆是理解Java GC機制 機製最重要的區域，沒有之一
    　　結構：新生代（Eden區+2個Survivor區） 老年代 永久代（HotSpot有）
    　　新生代：新建立的物件——>Eden區
    　　GC之後，存活的物件由Eden區 Survivor區0進入Survivor區1
    　　再次GC，存活的物件由Eden區 Survivor區1進入Survivor區0
    　　老年代：物件如果在新生代存活了足夠長的時間而沒有被清理掉（即在幾次Young GC後存活了下來），則會被複制到老年代
    　　如果新建立物件比較大（比如長字串或大陣列），新生代空間不足，則大物件會直接分配到老年代上（大物件可能觸發提前GC，應少用，更應避免使用短命的大物件）
    　　老年代的空間一般比新生代大，能存放更多的物件，在老年代上發生的GC次數也比年輕代少
    　　永久代：可以簡單理解爲方法區（本質上兩者並不等價）
    　　如上文所說：對於習慣在HotSpot 虛擬機器上開發和部署程式的開發者來說，很多人願意把方法區稱爲「永久代」，本質上兩者並不等價
    　　僅僅是因爲HotSpot 虛擬機器的設計團隊選擇把GC 分代收集擴充套件至方法區，或者說使用永久代來實現方法區而已
    　　對於其他虛擬機器（如BEA JRockit、IBM J9 等）來說是不存在永久代的概唸的
    　　即使是HotSpot 虛擬機器本身，根據官方發佈的路線圖資訊，現在也有放棄永久代並「搬家」至Native Memory 來實現方法區的規劃了
    　　Jdk1.6及之前：常數池分配在永久代
    　　Jdk1.7：有，但已經逐步「去永久代」
    　　Jdk1.8及之後：沒有永久代(java.lang.OutOfMemoryError: PermGen space,這種錯誤將不會出現在JDK1.8中) 替換爲元數據區(Metaspace),隨着元數據區的引入，方法區記憶體已經不再那麼窘迫，所以相應的 OOM 有所改觀，出現OOM，異常資訊則變成了：「java.lang.OutOfMemoryError: Metaspace」
  • 直接記憶體 Direct Memor
    　　直接記憶體並不是JVM管理的記憶體，可以這樣理解，直接記憶體，就是JVM以外的機器記憶體，比如，你有4G的記憶體，JVM佔用了1G，則其餘的3G就是直接記憶體
    　　JDK中有一種基於通道（Channel）和緩衝區（Buffer）的記憶體分配方式，將由C語言實現的native函數庫分配在直接記憶體中，用儲存在JVM堆中的DirectByteBuffer來參照
    　　由於直接記憶體收到本機器記憶體的限制，所以也可能出現OutOfMemoryError的異常。
方法區詳解

在这里插入图片描述
圖例（方法區中都儲存什麼）
型別資訊

  • 類的完整名稱（比如，java.long.String）
  • 類的直接父類別的完整名稱
  • 類的直接實現介面的有序列表（因爲一個類直接實現的介面可能不止一個，因此放到一個有序表中）
  • 類的修飾符
  • 可以看做是，對一個類進行登記，這個類的名字叫啥，他粑粑是誰、有沒有實現介面， 許可權是啥；

型別的常數池 （即執行時常數池）

  • 每一個Class檔案中，都維護着一個常數池（這個儲存在類檔案裏面，不要與方法區的執行時常數池搞混），裏面存放着編譯時期生成的各種字面值和符號參照；這個常數池的內容，在類載入的時候，被複制到方法區的執行時常數池 ；

  • 字面值：就是像string, 基本數據型別，以及它們的包裝類的值，以及final修飾的變數，簡單說就是在編譯期間，就可以確定下來的值；

  • 符號參照：不同於我們常說的參照，它們是對型別，域和方法的參照，類似於程序導向語言使用的前期系結，對方法呼叫產生的參照；

存在這裏面的數據，類似於儲存在陣列中，外部根據索引來獲得它們 ；

欄位資訊

  • 宣告的順序

  • 修飾符

  • 型別

  • 名字

方法資訊

  • 宣告的順序

  • 修飾符

  • 返回值型別

  • 名字

  • 參數列表（有序儲存）

  • 異常表（方法拋出的異常）

  • 方法位元組碼（native、abstract方法除外，）

  • 運算元棧和區域性變數表大小

類變數(即static變數）

  • 非final類變數
    在java虛擬機器使用一個類之前，它必須在方法區中爲每個非final類變數分配空間。非final類變數儲存在定義它的類中；
    final類變數（不儲存在這裏）由於final的不可改變性，因此，final類變數的值在編譯期間，就被確定了，因此被儲存在類的常數池裏面，然後在載入類的時候，複製進方法區的執行時常數池裏面 ；
    final類變數儲存在執行時常數池裏面，每一個使用它的類儲存着一個對其的參照；

對類載入器的參照

jvm必須知道一個型別是由啓動載入器載入的還是由使用者類載入器載入的。如果一個型別是由使用者類載入器載入的，那麼jvm會將這個類載入器的一個參照作爲型別資訊的一部分儲存在方法區中。

對Class類的參照
jvm爲每個載入的類都建立一個java.lang.Class的範例（儲存在堆上）。而jvm必須以某種方式把Class的這個範例和儲存在方法區中的型別數據（類的元數據）聯繫起來， 因此，類的元數據裏面儲存了一個Class物件的參照；

方法表
爲了提高存取效率，必須仔細的設計儲存在方法區中的數據資訊結構。除了以上討論的結構，jvm的實現者還可以新增一些其他的數據結構，如方法表。jvm對每個載入的非虛擬類的型別資訊中都新增了一個方法表，方法表是一組對類實體方法的直接參照(包括從父類別繼承的方法。jvm可以通過方法錶快速啓用實體方法。(譯者：這裏的方法表與C++中的虛擬函數表一樣，但java方法全都 是virtual的，自然也不用虛擬二字了。正像java宣稱沒有 指針了，其實java裡全是指針。更安全只是加了更完備的檢查機制 機製，但這都是以犧牲效率爲代價的,個人認爲java的設計者 始終是把安全放在效率之上的，所有java才更適合於網路開發)

java類物件詳解

物件的記憶體佈局

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 未鎖定
指向鎖記錄的指針 01 輕量級鎖定
指向重量級鎖的指針 10 膨脹（重量級鎖定
空，不需要記錄資訊 11 GC標記
偏向執行緒ID、偏向時間戳、物件分代年齡 01 可偏向

其中輕量級鎖和偏向鎖是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中的原因(關於這點稍後還會進行分析) 有了上述知識基礎後，下面 下麪我們將進一步分析synchronized在位元組碼層面的具體語意實現。

物件頭的另外一部分是型別指針，即是物件指向它的類的元數據的指針，虛擬機器通過這個指針來確定這個物件是哪個類的範例。並不是所有的虛擬機器實現都必須在物件數據上保留型別指針，換句話說查詢物件的元數據資訊並不一定要經過物件本身。另外，如果物件是一個Java陣列，那在物件頭中還必須有一塊用於記錄陣列長度的數據，因爲虛擬機器可以通過普通Java物件的元數據資訊確定Java物件的大小，但是從陣列的元數據中無法確定陣列的大小。

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程式的視角看來，初始化才正式開始，開始呼叫方法完成初始複製和建構函式，所有的欄位都爲零值。因此一般來說（由位元組碼中是否跟隨有invokespecial指令所決定），new指令之後會接着就是執 行方法，把物件按照程式設計師的意願進行初始化，這樣一個真正可用的物件纔算完全建立出來。

物件的存取定位

建立物件是爲了使用物件，我們的Java程式需要通過棧上的reference數據來操作堆上的具體物件。由於reference型別在Java虛擬機器規範裏面只規定了是一個指向物件的參照，並沒有定義這個參照應該通過什麼種方式去定位、存取到堆中的物件的具體位置，物件存取方式也是取決於虛擬機器實現而定的。主流的存取方式有使用控制代碼和直接指針兩種。
　　如果使用控制代碼存取的話，Java堆中將會劃分出一塊記憶體來作爲控制代碼池，reference中儲存的就是物件的控制代碼地址，而控制代碼中包含了物件範例數據與型別數據的具體各自的地址資訊。如圖1所示。
在这里插入图片描述
圖1 通過控制代碼存取物件

如果使用直接指針存取的話，Java堆物件的佈局中就必須考慮如何放置存取型別數據的相關資訊，reference中儲存的直接就是物件地址，如圖2所示。
在这里插入图片描述
圖2 通過直接指針存取物件

這兩種物件存取方式各有優勢，使用控制代碼來存取的最大好處就是reference中儲存的是穩定控制代碼地址，在物件被移動（垃圾收集時移動物件是非常普遍的行爲）時只會改變控制代碼中的範例數據指針，而reference本身不需要被修改。
　　使用直接指針來存取最大的好處就是速度更快，它節省了一次指針定位的時間開銷，由於物件存取的在Java中非常頻繁，因此這類開銷積小成多也是一項非常可觀的執行成本。從上一部分講解的物件記憶體佈局可以看出，就虛擬機器HotSpot而言，它是使用第二種方式進行物件存取，但在整個軟件開發的範圍來看，各種語言、框架中使用控制代碼來存取的情況也十分常見。

參考:
https://www.cnblogs.com/duanxz/p/4967042.html
https://www.csdn.net/gather_2b/NtjaUg1sODk0LWJsb2cO0O0O.html