程式計數器是一塊較小的記憶體，他可以看做是當前執行緒所執行的行號指示器。位元組碼直譯器工作的時候就是通過改變這個計數器的值來選取下一條需要執行的位元組碼的指令，分支、迴圈、跳轉、異常處理、執行緒恢復等基礎功能都需要依賴這個計數器來完成。如果執行緒正在執行的是一個Java方法，這個計數器記錄的是正在執行的虛擬機器位元組碼指令的地址；如果正在執行的是Native方法，這個計數器則為空。此記憶體區域是唯一一個在Java虛擬機器規範中沒有規定任何OutOfMemotyError情況的區域

1.2 Java虛擬機器棧

虛擬機器棧描述的是Java方法執行的記憶體模型：每個方法在執行的同時都會建立一個棧幀用於儲存區域性變量表、運算元棧、動態連結、方法出口等資訊。每個方法從呼叫直至完成的過程，就對應著一個棧幀在虛擬機器棧中入棧到出棧的過程。

棧記憶體就是虛擬機器棧，或者說是虛擬機器棧中區域性變量表的部分

區域性變量表存放了編輯期可知的各種基本資料型別（boolean、byte、char、short、int、float、long、double）、物件引用（refrence）型別和returnAddress型別（指向了一條位元組碼指令的地址）

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

Java虛擬機器規範對這個區域規定了兩種異常狀況：如果執行緒請求的棧深度大於虛擬機器所允許的深度，將丟擲StackOverflowError異常。如果虛擬機器擴充套件時無法申請到足夠的記憶體，就會跑出OutOfMemoryError異常

1.3 本地方法棧

本地方法棧和虛擬機器棧發揮的作用是非常類似的，他們的區別是虛擬機器棧為虛擬機器執行Java方法（也就是位元組碼）服務，而本地方法棧則為虛擬機器使用到的Native方法服務

本地方法棧區域也會丟擲StackOverflowError和OutOfMemoryErroy異常

1.4 Java堆

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

Java堆是垃圾收集器管理的主要區域。Java堆細分為新生代和老年代

不管怎樣，劃分的目的都是為了更好的回收記憶體，或者更快地分配記憶體

Java堆可以處於物理上不連續的記憶體空間中，只要邏輯上是連續的即可。如果在堆中沒有完成例項分配，並且堆也無法在擴充套件時將會丟擲OutOfMemoryError異常

1.5 方法區

方法區它用於儲存已被虛擬機器載入的類資訊、常量、靜態變數、即時編譯器編譯後的程式碼等資料

除了Java堆一樣不需要連續的記憶體和可以選擇固定大小或者可擴充套件外，還可以選擇不實現垃圾收集。這個區域的記憶體回收目標主要是針對常量池的回收和對型別的解除安裝

當方法區無法滿足記憶體分配需求時，將丟擲OutOfMemoryErroy異常

1.6 執行時常量池

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

Java語言並不要求常量一定只有編輯期才能產生，也就是可能將新的常量放入池中，這種特性被開發人員利用得比較多的便是String類的intern()方法

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

二、hotspot虛擬機器物件

2.1 物件的建立

1）.檢查

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

2）.分配記憶體

接下來將為新生物件分配記憶體，為物件分配記憶體空間的任務等同於把一塊確定的大小的記憶體從Java堆中劃分出來。

假設Java堆中記憶體是絕對規整的，所有用過的記憶體放在一遍，空閒的記憶體放在另一邊，中間放著一個指標作為分界點的指示器，那所分配記憶體就僅僅是把那個指標指向空閒空間那邊挪動一段與物件大小相等的距離，這個分配方式叫做“指標碰撞”

如果Java堆中的記憶體並不是規整的，已使用的記憶體和空閒的記憶體相互交錯，那就沒辦法簡單地進行指標碰撞了，虛擬機器就必須維護一個列表，記錄上哪些記憶體塊是可用的，在分配的時候從列表中找到一塊足夠大的空間劃分給物件例項，並更新列表上的記錄，這種分配方式成為“空閒列表”

選擇那種分配方式由Java堆是否規整決定，而Java堆是否規整又由所採用的垃圾收集器是否帶有壓縮整理功能決定。

3）. Init

執行new指令之後會接著執行Init方法，進行初始化，這樣一個物件才算產生出來

2.2 物件的記憶體佈局

在HotSpot虛擬機器中，物件在記憶體中儲存的佈局可以分為3塊區域：物件頭、例項資料和對齊填充

物件頭包括兩部分：

1). 儲存物件自身的執行時資料，如雜湊碼、GC分帶年齡、鎖狀態標誌、執行緒持有的鎖、偏向執行緒ID、偏向時間戳

2). 另一部分是指型別指標，即物件指向它的類元資料的指標，虛擬機器通過這個指標來確定這個物件是那個類的例項

2.3 物件的訪問定位

1).使用控制代碼訪問

Java堆中將會劃分出一塊記憶體來作為控制代碼池，reference中儲存的就是物件的控制代碼地址，而控制代碼中包含了物件例項資料與型別資料各自的具體地址
優勢:reference中儲存的是穩點的控制代碼地址,在物件被移動(垃圾收集時移動物件是非常普遍的行為)時只會改變控制代碼中的例項資料指標，而reference本身不需要修改

2).使用直接指標訪問

Java堆物件的佈局就必須考慮如何訪問型別資料的相關資訊,而refreence中儲存的直接就是物件的地址
優勢：速度更快，節省了一次指標定位的時間開銷，由於物件的訪問在Java中非常頻繁，因此這類開銷積少成多後也是一項非常可觀的執行成本

三、OutOfMemoryError 異常

3.1 Java堆溢位

Java堆用於儲存物件例項，只要不斷的建立物件，並且保證GCRoots到物件之間有可達路徑來避免垃圾回收機制清除這些物件，那麼在數量到達最大堆的容量限制後就會產生記憶體溢位異常

如果是記憶體洩漏，可進一步通過工具檢視洩漏物件到GC Roots的引用鏈。於是就能找到洩露物件是通過怎樣的路徑與GC Roots相關聯並導致垃圾收集器無法自動回收它們的。掌握了洩漏物件的型別資訊及GC Roots引用鏈的資訊，就可以比較準確地定位出洩漏程式碼的位置

如果不存在洩露，換句話說，就是記憶體中的物件確實都還必須存活著，那就應當檢查虛擬機器的堆引數（-Xmx與-Xms），與機器實體記憶體對比看是否還可以調大，從程式碼上檢查是否存在某些物件生命週期過長、持有狀態時間過長的情況，嘗試減少程式執行期的記憶體消耗

3.2 虛擬機器棧和本地方法棧溢位

對於HotSpot來說，雖然-Xoss引數（設定本地方法棧大小）存在，但實際上是無效的，棧容量只由-Xss引數設定。關於虛擬機器棧和本地方法棧，在Java虛擬機器規範中描述了兩種異常：

如果執行緒請求的棧深度大於虛擬機器所允許的最大深度，將丟擲StackOverflowError

如果虛擬機器在擴充套件棧時無法申請到足夠的記憶體空間，則丟擲OutOfMemoryError異常

在單執行緒下，無論由於棧幀太大還是虛擬機器棧容量太小，當記憶體無法分配的時候，虛擬機器丟擲的都是StackOverflowError異常

如果是多執行緒導致的記憶體溢位，與棧空間是否足夠大並不存在任何聯絡，這個時候每個執行緒的棧分配的記憶體越大，反而越容易產生記憶體溢位異常。解決的時候是在不能減少執行緒數或更換64為的虛擬機器的情況下，就只能通過減少最大堆和減少棧容量來換取更多的執行緒

3.3 方法區和執行時常量池溢位

String.intern()是一個Native方法，它的作用是：如果字串常量池中已經包含一個等於此String物件的字串，則返回代表池中這個字串的String物件；否則，將此String物件包含的字串新增到常量池中，並且返回此String物件的引用

由於常量池分配在永久代中，可以通過-XX:PermSize和-XX:MaxPermSize限制方法區大小，從而間接限制其中常量池的容量。

Intern():

JDK1.6 intern方法會把首次遇到的字串例項複製到永久代，返回的也是永久代中這個字串例項的引用，而由StringBuilder建立的字串例項在Java堆上，所以必然不是一個引用

JDK1.7 intern()方法的實現不會再複製例項，只是在常量池中記錄首次出現的例項引用，因此intern()返回的引用和由StringBuilder建立的那個字串例項是同一個

四、垃圾收集

程式計數器、虛擬機器棧、本地方法棧3個區域隨執行緒而生，隨執行緒而滅，在這幾個區域內就不需要過多考慮回收的問題，因為方法結束或者執行緒結束時，記憶體自然就跟隨著回收了

4.1 判斷物件存活

4.1.1 引用計數器法

給物件新增一個引用計數器，每當由一個地方引用它時，計數器值就加1；當引用失效時，計數器值就減1；任何時刻計數器為0的物件就是不可能再被使用的

4.1.2 可達性分析演算法

通過一系列的成為“GC Roots”的物件作為起始點，從這些節點開始向下搜尋，搜尋所走過的路徑成為引用鏈，當一個物件到GC ROOTS沒有任何引用鏈相連時，則證明此物件時不可用的

Java語言中GC Roots的物件包括下面幾種：

1.虛擬機器棧（棧幀中的本地變量表）中引用的物件
2.方法區中類靜態屬性引用的物件
3.方法區中常量引用的物件
4.本地方法棧JNI（Native方法）引用的物件

4.2.引用

強引用就是在程式程式碼之中普遍存在的，類似Object obj = new Object() 這類的引用，只要強引用還存在，垃圾收集器永遠不會回收掉被引用的物件

軟引用用來描述一些還有用但並非必須的元素。對於它在系統將要發生記憶體溢位異常之前，將會把這些物件列進回收範圍之中進行第二次回收，如果這次回收還沒有足夠的記憶體才會丟擲記憶體溢位異常

弱引用用來描述非必須物件的，但是它的強度比軟引用更弱一些，被引用關聯的物件只能生存到下一次垃圾收集發生之前，當垃圾收集器工作時，無論當前記憶體是否足夠都會回收掉只被弱引用關聯的物件

虛引用的唯一目的就是能在這個物件被收集器回收時收到一個系統通知

4.3.Finalize方法

任何一個物件的finalize()方法都只會被系統自動呼叫一次，如果物件面臨下一次回收，它的finalize()方法不會被再次執行，因此第二段程式碼的自救行動失敗了

4.3.1 回收方法區

永久代的垃圾收集主要回收兩部分內容：廢棄常量和無用的類

廢棄常量：

假如一個字串abc已經進入了常量池中，如果當前系統沒有任何一個String物件abc，也就是沒有任何Stirng物件引用常量池的abc常量，也沒有其他地方引用的這個字面量，這個時候發生記憶體回收這個常量就會被清理出常量池

無用的類：

1.該類所有的例項都已經被回收，就是Java堆中不存在該類的任何例項
2.載入該類的ClassLoader已經被回收
3.該類對用的java.lang.Class物件沒有在任何地方被引用，無法再任何地方通過反射訪問該類的方法

4.4.垃圾收集演算法

4.4.1 標記—清除演算法

演算法分為標記和清除兩個階段：
首先標記出所有需要回收的物件，
在標記完成後統一回收所有被標記的物件、

不足:
一個是效率問題，標記和清除兩個過程的效率都不高；
另一個是空間問題，標記清楚之後會產生大量不連續的記憶體碎片，空間碎片太多可能會導致以後再程式執行過程中需要分配較大的物件時，無法找到足夠的連續記憶體而不得不提前觸發另一次垃圾收集動作

4.4.2 複製演算法

他將可用記憶體按照容量劃分為大小相等的兩塊，每次只使用其中的一塊。當這塊的記憶體用完了，就將還存活著的物件複製到另外一塊上面，然後再把已使用過的記憶體空間一次清理掉。這樣使得每次都是對整個半區進行記憶體回收，記憶體分配時也就不用考慮記憶體碎片等複雜情況，只要移動堆頂指標，按順序分配記憶體即可

不足：將記憶體縮小為了原來的一半

實際中我們並不需要按照1:1比例來劃分記憶體空間，而是將記憶體分為一塊較大的Eden空間和兩塊較小的Survivor空間，每次使用Eden和其中一塊Survivor

當另一個Survivor空間沒有足夠空間存放上一次新生代收集下來的存活物件時，這些物件將直接通過分配擔保機制進入老年代

4.4.3 標記整理演算法

讓所有存活的物件都向一端移動，然後直接清理掉端邊界以外的記憶體

4.4.4 分代收集演算法

只是根據物件存活週期的不同將記憶體劃分為幾塊。一般是把java堆分為新生代和老年代，這樣就可以根據各個年代的特點採用最適當的收集演算法。在新生代中，每次垃圾收集時都發現有大批物件死去，只有少量存活，那就選用複製演算法，只需要付出少量存活物件的複製成本就可以完成收集。而老年代中因為物件存活率高、沒有額外空間對它進行分配擔保，就必須使用標記清理或者標記整理演算法來進行回收

4.5 垃圾收集器

a) Serial收集器：

這個收集器是一個單執行緒的收集器，但它的單執行緒的意義不僅僅說明它會只使用一個COU或一條收集執行緒去完成垃圾收集工作，更重要的是它在進行垃圾收集時，必須暫停其他所有的工作執行緒，直到它手機結束

b) ParNew 收集器：

Serial收集器的多執行緒版本，除了使用了多執行緒進行收集之外，其餘行為和Serial收集器一樣

並行：指多條垃圾收集執行緒並行工作，但此時使用者執行緒仍然處於等待狀態

併發：指使用者執行緒與垃圾收集執行緒同時執行（不一定是並行的，可能會交替執行），使用者程式在繼續執行，而垃圾收集程式運行於另一個CPU上

c) Parallel Scavenge

收集器是一個新生代收集器，它是使用複製演算法的收集器，又是並行的多執行緒收集器。

吞吐量：就是CPU用於執行使用者程式碼的時間與CPU總消耗時間的比值。即吞吐量=執行使用者程式碼時間/（執行使用者程式碼時間+垃圾收集時間）

d) Serial Old 收集器：

是Serial收集器的老年代版本,是一個單執行緒收集器，使用標記整理演算法

e) Parallel Old 收集器：

Parallel Old是Paraller Seavenge收集器的老年代版本，使用多執行緒和標記整理演算法

f) CMS收集器：

CMS收集器是基於標記清除演算法實現的，整個過程分為4個步驟：

1.初始標記
2.併發標記
3.重新標記
4.併發清除

優點： 併發收集、低停頓

缺點：

1.CMS收集器對CPU資源非常敏感，CMS預設啟動的回收執行緒數是（CPU數量+3）/4，
2.CMS收集器無法處理浮動垃圾，可能出現Failure失敗而導致一次Full G場地產生
3.CMS是基於標記清除演算法實現的

g) G1收集器：

它是一款面向伺服器應用的垃圾收集器

1.並行與併發：利用多CPU縮短STOP-The-World停頓的時間
2.分代收集
3.空間整合：不會產生記憶體碎片
4.可預測的停頓

運作方式： 初始標記，併發標記，最終標記，篩選回收

4.6.記憶體分配與回收策略

4.6.1 物件優先在Eden分配：

大多數情況物件在新生代Eden區分配，當Eden區沒有足夠空間進行分配時，虛擬機器將發起一次Minor GC

4.6.2 大物件直接進入老年代：

所謂大物件就是指需要大量連續記憶體空間的Java物件，最典型的大物件就是那種很長的字串以及陣列。這樣做的目的是避免Eden區及兩個Servivor之間發生大量的記憶體複製

4.6.3 長期存活的物件將進入老年代

如果物件在Eden區出生並且盡力過一次Minor GC後仍然存活，並且能夠被Servivor容納，將被移動到Servivor空間中，並且把物件年齡設定成為1.物件在Servivor區中每熬過一次Minor GC，年齡就增加1歲，當它的年齡增加到一定程度（預設15歲），就將會被晉級到老年代中

4.6.4 動態物件年齡判定

為了更好地適應不同程式的記憶體狀況，虛擬機器並不是永遠地要求物件的年齡必須達到了MaxTenuringThreshold才能晉級到老年代，如果在Servivor空間中相同年齡所有物件的大小總和大於Survivor空間的一半，年齡大於或等於該年齡的物件就可以直接進入到老年代，無須登到MaxTenuringThreshold中要求的年齡

4.6.4 空間分配擔保：

在發生Minor GC 之前，虛擬機器會檢查老年代最大可用的連續空間是否大於新生代所有物件總空間，如果這個條件成立，那麼Minor DC可以確保是安全的。如果不成立，則虛擬機器會檢視HandlePromotionFailure設定值是否允許擔保失敗。如果允許那麼會繼續檢查老年代最大可用的連續空間是否大於晉級到老年代物件的平均大小，如果大於，將嘗試進行一次Minor GC，儘管這次MinorGC 是有風險的：如果小於，或者HandlePromotionFailure設定不允許冒險，那這時也要改為進行一次Full GC

五、虛擬機器類載入機制

虛擬機器吧描述類的資料從Class檔案載入到記憶體，並對資料進行校驗、轉換解析和初始化，最終形成可以被虛擬機器直接使用的Java型別，這就是虛擬機器的類載入機制

在Java語言裡面，型別的載入。連線和初始化過程都是在程式執行期間完成的

5.1 類載入的時機

類被載入到虛擬機器記憶體中開始，到解除安裝為止，整個生命週期包括：載入、驗證、準備、解析、初始化、使用和解除安裝7個階段

載入、驗證、準備、初始化和解除安裝這5個階段的順序是確定的，類的載入過程必須按照這種順序按部就班地開始，而解析階段則不一定：它在某些情況下可以再初始化階段之後再開始，這個是為了支援Java語言執行時繫結（也成為動態繫結或晚期繫結）

虛擬機器規範規定有且只有5種情況必須立即對類進行初始化：

1.遇到new、getstatic、putstatic或invokestatic這4條位元組碼指令時，如果類沒有進行過初始化，則需要觸發其初始化。生成這4條指令的最常見的Java程式碼場景是：使用new關鍵字例項化物件的時候、讀取或設定一個類的靜態欄位（被final修飾、已在編譯期把結果放入常量池的靜態欄位除外）的時候，以及呼叫一個類的靜態方法的時候
2.使用java.lang.reflect包的方法對類進行反射呼叫的時候，如果類沒有進行過初始化，則需要先觸發其初始化
3.當初始化一個類的時候，如果發現其父類還沒有進行過初始化，則需要先觸發其父類的初始化
4.當虛擬機器啟動時候，使用者需要指定一個要執行的主類（包含main()方法的那個類），虛擬機器會先初始化這個主類
5.當使用JDK1.7的動態語言支援時，如果一個java.lang.invoke.MethodHandle例項最後的解析結果REF_getStatic、REF_putStatic、REF_invokeStatic的方法控制代碼，並且這個方法控制代碼所對應的類沒有進行過初始化，則需要先觸發其初始化

被動引用：

1.通過子類引用父類的靜態欄位，不會導致子類初始化
2.通過陣列定義來引用類，不會觸發此類的初始化
3.常量在編譯階段會存入呼叫類的常量池中，本質上並沒有直接引用到定義常量的類，因此不會觸發定義常量的類的初始化

介面的初始化： 介面在初始化時，並不要求其父介面全部完成類初始化，只有在正整使用到父介面的時候（如引用介面中定義的常量）才會初始化

5.2 類載入的過程

5.2.1 載入

1)通過一個類的全限定名類獲取定義此類的二進位制位元組流
2)將這位元組流所代表的靜態儲存結構轉化為方法區執行時資料結構
3)在記憶體中生成一個代表這個類的java.lang.Class物件，作為方法區這個類的各種資料的訪問入口

怎麼獲取二進位制位元組流？

1)從ZIP包中讀取，這很常見，最終成為日後JAR、EAR、WAR格式的基礎
2)從網路中獲取，這種場景最典型的應用就是Applet
3)執行時計算生成，這種常見使用得最多的就是動態代理技術
4)由其他檔案生成，典型場景就是JSP應用
5)從資料庫中讀取，這種場景相對少一些（中介軟體伺服器）
陣列類本身不通過類載入器建立，它是由Java虛擬機器直接建立的

陣列類的建立過程遵循以下規則：

1)如果陣列的元件型別(指的是陣列去掉一個維度的型別)是引用型別，那就遞迴採用上面的載入過程去載入這個元件型別，陣列C將在載入該元件型別的類載入器的類名稱空間上被標識
2)如果陣列的元件型別不是引用型別(列如int[]組數)，Java虛擬機器將會把陣列C標識為與引導類載入器關聯
3)陣列類的可見性與它的元件型別的可見性一致，如果元件型別不是引用型別，那陣列類的可見性將預設為public

5.2.2 驗證

驗證階段會完成下面4個階段的檢驗動作：檔案格式驗證，元資料驗證，位元組碼驗證，符號引用驗證

1.檔案格式驗證

第一階段要驗證位元組流是否符合Class檔案格式的規範，並且能被當前版本的虛擬機器處理。這一階段可能包括：

1.是否以魔數oxCAFEBABE開頭
2.主、次版本號是否在當前虛擬機器處理範圍之內
3.常量池的常量中是否有不被支援的常量型別(檢查常量tag標誌)
4.指向常量的各種索引值中是否有指向不存在的常量或不符合型別的常量
5.CONSTANT_Itf8_info 型的常量中是否有不符合UTF8編碼的資料
6.Class檔案中各個部分及檔案本身是否有被刪除的或附加的其他資訊

這個階段的驗證時基於二進位制位元組流進行的，只有通過類這個階段的驗證後，位元組流才會進入記憶體的方法區進行儲存，所以後面的3個驗證階段全部是基於方法區的儲存結構進行的，不會再直接操作位元組流

2.元資料驗證

1.這個類是否有父類(除了java.lang.Object之外,所有的類都應當有父類)
2.這個類的父類是否繼承了不允許被繼承的類（被final修飾的類）
3.如果這個類不是抽象類，是否實現類其父類或介面之中要求實現的所有方法
4.類中的欄位、方法是否與父類產生矛盾(列如覆蓋類父類的final欄位,或者出現不符合規則的方法過載，列如方法引數都一致，但返回值型別卻不同等)

第二階段的主要目的是對類元資料資訊進行語義校驗，保證不存在不符合Java語言規範的元資料資訊

3.位元組碼驗證

第三階段是整個驗證過程中最複雜的一個階段，主要目的似乎通過資料流和控制流分析，確定程式語言是合法的、符合邏輯的。在第二階段對元資料資訊中的資料型別做完校驗後，這個階段將對類的方法體進行校驗分析，保證被校驗類的方法在執行時不會做出危害虛擬機器安全的事件。

1.保證任意時刻運算元棧的資料型別與指令程式碼序列都能配合工作，列如，列如在運算元棧放置類一個int型別的資料，使用時卻按long型別來載入入本地變量表中
2.保證跳轉指令不會跳轉到方法體以外的位元組碼指令上
3.保證方法體中的型別轉換時有效的，列如可以把一個子類物件賦值給父類資料型別，這個是安全的，但是吧父類物件賦值給子類資料型別，甚至把物件賦值給與它毫無繼承關係、完全不相干的一個數據型別，則是危險和不合法的

4.符號引用驗證

發生在虛擬機器將符號引用轉化為直接引用的時候，這個轉化動作將在連線的第三階段——解析階段中發生。

1.符號引用中通過字串描述的全限定名是否能找到相對應的類
2.在指定類中是否存在符合方法的欄位描述符以及簡單名稱所描述的方法和欄位
3.符號引用中的類、欄位、方法的訪問性是否可被當前類訪問

對於虛擬機器的類載入機制來說，驗證階段是非常重要的，但是不一定必要（因為對程式執行期沒有影響）的階段。如果全部程式碼都已經被反覆使用和驗證過，那麼在實施階段就可以考慮使用Xverify：none引數來關閉大部分的類驗證措施，以縮短虛擬機器類載入的時間

5.2.3 準備

準備階段是正式為類變數分配記憶體並設定類變數初始值的階段，這些變數都在方法區中進行分配。這個時候進行記憶體分配的僅包括類變數(被static修飾的變數)，而不包括例項變數，例項變數將會在物件例項化時隨著物件一起分配在Java堆中。其次，這裡說的初始值通常下是資料型別的零值。

假設public static int value = 123；

那變數value在準備階段過後的初始值為0而不是123，因為這時候尚未開始執行任何Java方法，而把value賦值為123的putstatic指令是程式被編譯後，存放於類構造器()方法之中，所以把value賦值為123的動作將在初始化階段才會執行，但是如果使用final修飾，則在這個階段其初始值設定為123

5.2.4 解析

解析階段是虛擬機器將常量池內符號引用替換為直接引用的過

5.2.5 初始化

類的初始化階段是類載入過程的最後一步，前面的類載入過程中，除了在載入階段使用者應用程式可以通過自定義類載入器參與之外，其餘動作完全由虛擬機器主導和控制。到了初始化階段，才正真開始執行類中定義的Java程式程式碼(或者說是位元組碼)

5.3 類的載入器

5.3.1 雙親委派模型：

只存在兩種不同的類載入器：啟動類載入器（Bootstrap ClassLoader），使用C++實現，是虛擬機器自身的一部分。另一種是所有其他的類載入器，使用JAVA實現，獨立於JVM，並且全部繼承自抽象類java.lang.ClassLoader.

啟動類載入器（Bootstrap ClassLoader），負責將存放在<JAVA+HOME>\lib目錄中的，或者被-Xbootclasspath引數所制定的路徑中的，並且是JVM識別的（僅按照檔名識別，如rt.jar，如果名字不符合，即使放在lib目錄中也不會被載入），載入到虛擬機器記憶體中，啟動類載入器無法被JAVA程式直接引用。

擴充套件類載入器，由 sun.misc.Launcher$ExtClassLoader 實現，負責載入<JAVA_HOME>\lib\ext目錄中的，或者被 java.ext.dirs 系統變數所指定的路徑中的所有類庫，開發者可以直接使用擴充套件類載入器。

應用程式類載入器（Application ClassLoader），由sun.misc.Launcher$AppClassLoader來實現。由於這個類載入器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般稱它為系統類載入器。負責載入使用者類路徑（ClassPath）上所指定的類庫，開發者可以直接使用這個類載入器，如果應用程式中沒有自定義過自己的類載入器，一般情況下這個就是程式中預設的類載入器。

這張圖表示類載入器的雙親委派模型（Parents Delegation model）。雙親委派模型要求除了頂層的啟動載入類外，其餘的類載入器都應當有自己的父類載入器。，這裡類載入器之間的父子關係一般不會以繼承的關係來實現，而是使用組合關係來複用父類載入器的程式碼。

5.3.2 雙親委派模型的工作過程是：

如果一個類載入器收到了類載入的請求，它首先不會自己去嘗試載入這個類，而是把這個請求委派給父類載入器去完成，每一個層次的類載入器都是如此，因此所有的載入請求最終都是應該傳送到頂層的啟動類載入器中，只有當父類載入器反饋自己無法完成這個載入請求（它的搜尋範圍中沒有找到所需的類）時，子載入器才會嘗試自己去載入。

5.3.3 這樣做的好處就是：

Java類隨著它的類載入器一起具備了一種帶有優先順序的層次關係。例如類java.lang.Object,它存放在rt.jar中，無論哪一個類載入器要載入這個類，最終都是委派給處於模型最頂端的啟動類載入器進行載入，因此Object類在程式的各種類載入器環境中都是同一個類。相反，如果沒有使用雙親委派模型，由各個類載入器自行去載入的話，如果使用者自己編寫了一個稱為java.lang.object的類，並放在程式的ClassPath中，那系統中將會出現多個不同的Object類，Java型別體系中最基礎的行為也就無法保證，應用程式也將會變得一片混亂

就是保證某個範圍的類一定是被某個類載入器所載入的，這就保證在程式中同一個類不會被不同的類載入器載入。這樣做的一個主要的考量，就是從安全層面上，杜絕通過使用和JRE相同的類名冒充現有JRE的類達到替換的攻擊方式

六、Java記憶體模型與執行緒

6.1 記憶體間的互動操作

關於主記憶體與工作記憶體之間的具體互動協議，即一個變數如何從主記憶體拷貝到工作記憶體、如何從工作記憶體同步到主記憶體之間的實現細節，Java記憶體模型定義了以下八種操作來完成：

lock（鎖定）：作用於主記憶體的變數，把一個變數標識為一條執行緒獨佔狀態。

unlock（解鎖）：作用於主記憶體變數，把一個處於鎖定狀態的變數釋放出來，釋放後的變數才可以被其他執行緒鎖定。

read（讀取）：作用於主記憶體變數，把一個變數值從主記憶體傳輸到執行緒的工作記憶體中，以便隨後的load動作使用

load（載入）：作用於工作記憶體的變數，它把read操作從主記憶體中得到的變數值放入工作記憶體的變數副本中。

use（使用）：作用於工作記憶體的變數，把工作記憶體中的一個變數值傳遞給執行引擎，每當虛擬機器遇到一個需要使用變數的值的位元組碼指令時將會執行這個操作。

assign（賦值）：作用於工作記憶體的變數，它把一個從執行引擎接收到的值賦值給工作記憶體的變數，每當虛擬機器遇到一個給變數賦值的位元組碼指令時執行這個操作。

store（儲存）：作用於工作記憶體的變數，把工作記憶體中的一個變數的值傳送到主記憶體中，以便隨後的write的操作。

write（寫入）：作用於主記憶體的變數，它把store操作從工作記憶體中一個變數的值傳送到主記憶體的變數中。

如果要把一個變數從主記憶體中複製到工作記憶體，就需要按順尋地執行read和load操作，如果把變數從工作記憶體中同步回主記憶體中，就要按順序地執行store和write操作。Java記憶體模型只要求上述操作必須按順序執行，而沒有保證必須是連續執行。也就是read和load之間， store和write之間是可以插入其他指令的，如對主記憶體中的變數a、b進行訪問時，可能的順序是read a，read b，load b， load a。

Java記憶體模型還規定了在執行上述八種基本操作時，必須滿足如下規則：

不允許read和load、store和write操作之一單獨出現
不允許一個執行緒丟棄它的最近assign的操作，即變數在工作記憶體中改變了之後必須同步到主記憶體中。
不允許一個執行緒無原因地（沒有發生過任何assign操作）把資料從工作記憶體同步回主記憶體中。

一個新的變數只能在主記憶體中誕生，不允許在工作記憶體中直接使用一個未被初始化（load或assign）的變數。即就是對一個變數實施use和store操作之前，必須先執行過了assign和load操作。

一個變數在同一時刻只允許一條執行緒對其進行lock操作，但lock操作可以被同一條執行緒重複執行多次，多次執行lock後，只有執行相同次數的unlock操作，變數才會被解鎖。lock和unlock必須成對出現

如果對一個變數執行lock操作，將會清空工作記憶體中此變數的值，在執行引擎使用這個變數前需要重新執行load或assign操作初始化變數的值

如果一個變數事先沒有被lock操作鎖定，則不允許對它執行unlock操作；也不允許去unlock一個被其他執行緒鎖定的變數。

對一個變數執行unlock操作之前，必須先把此變數同步到主記憶體中（執行store和write操作）。

6.2 重排序

在執行程式時為了提高效能，編譯器和處理器經常會對指令進行重排序。重排序分成三種類型：

1.編譯器優化的重排序。編譯器在不改變單執行緒程式語義放入前提下，可以重新安排語句的執行順序。
2.指令級並行的重排序。現代處理器採用了指令級並行技術來將多條指令重疊執行。如果不存在資料依賴性，處理器可以改變語句對應機器指令的執行順序。
3.記憶體系統的重排序。由於處理器使用快取和讀寫緩衝區，這使得載入和儲存操作看上去可能是在亂序執行。

從Java原始碼到最終實際執行的指令序列，會經過下面三種重排序：

為了保證記憶體的可見性，Java編譯器在生成指令序列的適當位置會插入記憶體屏障指令來禁止特定型別的處理器重排序。Java記憶體模型把記憶體屏障分為LoadLoad、LoadStore、StoreLoad和StoreStore四種：

6.3 對於volatile型變數的特殊規則

當一個變數定義為volatile之後，它將具備兩種特性：

第一：保證此變數對所有執行緒的可見性，這裡的可見性是指當一條執行緒修改了這個變數的值，新值對於其他執行緒來說是可以立即得知的。普通變數的值線上程間傳遞需要通過主記憶體來完成

由於valatile只能保證可見性，在不符合一下兩條規則的運算場景中，我們仍要通過加鎖來保證原子性：

1.運算結果並不依賴變數的當前值，或者能夠確保只有單一的執行緒修改變數的值。
2.變數不需要與其他的狀態變數共同參與不變約束

第二：禁止指令重排序，普通的變數僅僅會保證在該方法的執行過程中所有依賴賦值結果的地方都能獲取到正確的結果，而不能保證變數賦值操作的順序與程式程式碼中執行順序一致，這個就是所謂的執行緒內表現為序列的語義

Java記憶體模型中對volatile變數定義的特殊規則。假定T表示一個執行緒，V和W分別表示兩個volatile變數，那麼在進行read、load、use、assign、store、write操作時需要滿足如下的規則：

1.只有當執行緒T對變數V執行的前一個動作是load的時候，執行緒T才能對變數V執行use動作；並且，只有當執行緒T對變數V執行的後一個動作是use的時候，執行緒T才能對變數V執行load操作。執行緒T對變數V的use操作可以認為是與執行緒T對變數V的load和read操作相關聯的，必須一起連續出現。這條規則要求在工作記憶體中，每次使用變數V之前都必須先從主記憶體重新整理最新值，用於保證能看到其它執行緒對變數V所作的修改後的值。
2.只有當執行緒T對變數V執行的前一個動是assign的時候，執行緒T才能對變數V執行store操作；並且，只有當執行緒T對變數V執行的後一個動作是store操作的時候，執行緒T才能對變數V執行assign操作。執行緒T對變數V的assign操作可以認為是與執行緒T對變數V的store和write操作相關聯的，必須一起連續出現。這一條規則要求在工作記憶體中，每次修改V後都必須立即同步回主記憶體中，用於保證其它執行緒可以看到自己對變數V的修改。
3.假定操作A是執行緒T對變數V實施的use或assign動作，假定操作F是操作A相關聯的load或store操作，假定操作P是與操作F相應的對變數V的read或write操作；型別地，假定動作B是執行緒T對變數W實施的use或assign動作，假定操作G是操作B相關聯的load或store操作，假定操作Q是與操作G相應的對變數V的read或write操作。如果A先於B，那麼P先於Q。這條規則要求valitile修改的變數不會被指令重排序優化，保證程式碼的執行順序與程式的順序相同。

6.4 對於long和double型變數的特殊規則

Java模型要求lock、unlock、read、load、assign、use、store、write這8個操作都具有原子性，但是對於64為的資料型別（long和double），在模型中特別定義了一條相對寬鬆的規定：允許虛擬機器將沒有被volatile修飾的64位資料的讀寫操作分為兩次32為的操作來進行，即允許虛擬機器實現選擇可以不保證64位資料型別的load、store、read和write這4個操作的原子性

6.5 原子性、可見性和有序性

原子性： 即一個操作或者多個操作要麼全部執行並且執行的過程不會被任何因素打斷，要麼就都不執行。Java記憶體模型是通過在變數修改後將新值同步會主記憶體，在變數讀取前從主記憶體重新整理變數值這種依賴主記憶體作為傳遞媒介的方式來實現可見性，valatile特殊規則保障新值可以立即同步到祝記憶體中。Synchronized是在對一個變數執行unlock之前，必須把變數同步回主記憶體中（執行store、write操作）。被final修飾的欄位在構造器中一旦初始化完成，並且構造器沒有吧this的引用傳遞出去，那在其他執行緒中就能看見final欄位的值

可見性： 可見性是指當多個執行緒訪問同一個變數時，一個執行緒修改了這個變數的值，其他執行緒能夠立即看得到修改的值。

有序性： 即程式執行的順序按照程式碼的先後順序執行。

6.6 先行發生原則

這些先行發生關係無須任何同步就已經存在，如果不再此列就不能保障順序性，虛擬機器就可以對它們任意地進行重排序

1.程式次序規則：在一個執行緒內，按照程式程式碼順序，書寫在前面的操作先行發生於書寫在後面的操作。準確的說，應該是控制順序而不是程式程式碼順序，因為要考慮分支。迴圈等結構
2.管程鎖定規則：一個unlock操作先行發生於後面對同一個鎖的lock操作。這裡必須強調的是同一個鎖，而後面的是指時間上的先後順序
3.volatile變數規則：對一個volatile變數的寫操作先行發生於後面對這個變數的讀操作，這裡的後面同樣是指時間上的先後順序
4.執行緒啟動規則：Thread物件的start()方法先行發生於此執行緒的每一個動作
5.執行緒終止規則：執行緒中的所有操作都先行發生於對此執行緒的終止檢測，我們可以通過Thread.join()方法結束、ThradisAlive()的返回值等手段檢測到執行緒已經終止執行
6.執行緒中斷規則：對執行緒interrupt()方法的呼叫先行發生於被中斷執行緒的程式碼檢測到中斷時間的發生，可以通過Thread.interrupted()方法檢測到是否有中斷髮生
7.物件終結規則：一個物件的初始化完成(建構函式執行結束)先行發生於它的finalize()方法的開始
8.傳遞性：如果操作A先行發生於操作B，操作B先行發生於操作C，那就可以得出操作A先行發生於操作C的結論

6.7 Java執行緒排程

協同式排程：執行緒的執行時間由執行緒本身控制

搶佔式排程：執行緒的執行時間由系統來分配

6.8 狀態轉換

1.新建

2.執行：可能正在執行。可能正在等待CPU為它分配執行時間

3.無限期等待：不會被分配CUP執行時間，它們要等待被其他執行緒顯式喚醒

4.限期等待：不會被分配CUP執行時間，它們無須等待被其他執行緒顯式喚醒，一定時間會由系統自動喚醒

5.阻塞：阻塞狀態在等待這獲取到一個排他鎖，這個時間將在另一個執行緒放棄這個鎖的時候發生；等待狀態就是在等待一段時間，或者喚醒動作的發生

6.結束：已終止執行緒的執行緒狀態，執行緒已經結束執行

七、執行緒安全

1、不可變：不可變的物件一定是執行緒安全的、無論是物件的方法實現還是方法的呼叫者，都不需要再採取任何的執行緒安全保障。例如：把物件中帶有狀態的變數都宣告為final，這樣在建構函式結束之後，它就是不可變的。

2、絕對執行緒安全

3、相對執行緒安全：相對的執行緒安全就是我們通常意義上所講的執行緒安全，它需要保證對這個物件單獨的操作是執行緒安全的，我們在呼叫的時候不需要做額外的保障措施，但是對於一些特定順序的連續呼叫，就可能需要在呼叫端使用額外的同步手段來保證呼叫的正確性

4、執行緒相容：物件本身並不是執行緒安全的，但是可以通過在呼叫端正確地使用同步手段來保證物件在併發環境中可以安全使用

5、執行緒對立：是指無論呼叫端是否採取了同步措施，都無法在多執行緒環境中併發使用的程式碼

7.1 執行緒安全的實現方法

7.1.1.互斥同步：

同步是指在多個執行緒併發訪問共享資料時，保證共享資料在同一個時刻只被一個（或者是一些，使用訊號量的時候）執行緒使用。

而互斥是實現同步的一種手段，臨界區、互斥量和訊號量都是主要的互斥實現方式。

互斥是因，同步是果：互斥是方法，同步是目的。

在Java中，最基本的互斥同步手段就是synchronized關鍵字，它經過編譯之後，會在同步塊的前後分別形成monitorenter和monitorexit這兩個位元組碼指令，這兩個位元組碼都需要一個reference型別的引數來指明要鎖定和解鎖的物件。如果Java程式中的synchronized明確指定了物件引數，那就是這個物件的reference；如果沒有指明，那就根據synchronized修飾的是例項方法還是類方法，去取對應的物件例項或Class物件來作為鎖物件。在執行monitorenter指令時，首先要嘗試獲取物件的鎖。如果這個物件沒有被鎖定，或者當前執行緒已經擁有了那個物件的鎖，把鎖的計數器加1，對應的在執行monitorexit指令時會將鎖計數器減1，當計數器為0時，鎖就被釋放。如果獲取物件鎖失敗，哪當前執行緒就要阻塞等待，直到物件鎖被另外一個執行緒釋放為止

Synchronized，ReentrantLock增加了一些高階功能：

1.等待可中斷：是指當持有鎖的執行緒長期不釋放鎖的時候，正在等待的執行緒可以選擇放棄等待，改為處理其他事情，可中斷特性對處理執行時間非常長的同步塊很有幫助

2.公平鎖：是指多個執行緒在等待同一個鎖時，必須按照申請鎖的時間順序來依次獲得鎖；非公平鎖則不能保證這一點，在鎖被釋放時，任何一個等待鎖的執行緒都有機會獲得鎖。Synchronized中的鎖是非公平的，ReentrantLock預設情況下也是非公平的，但可以通過帶布林值的建構函式要求使用公平鎖

3.鎖繫結多個條件是指一個ReentrantLock物件可以同時繫結多個Condition物件，而在synchronized中，鎖物件的wait()和notify()或notifyAll()方法可以實現一個隱含的條件，如果要和多餘一個的條件關聯的時候，就不得不額外地新增一個鎖，而ReentrantLock則無須這樣做，只需要多次呼叫newCondition方法即可

7.1.2.非阻塞同步

無

7.1.3.無同步方案

可重入程式碼：也叫純程式碼，可以在程式碼執行的任何時刻中斷它，轉而去執行另外一段程式碼（包括遞迴呼叫它本身）而在控制權返回後，原來的程式不會出現任何錯誤。所有的可重入程式碼都是執行緒安全的，但是並非所有的執行緒安全的程式碼都是可重入的。

判斷一個程式碼是否具備可重入性：如果一個方法，它的返回結果是可預測的，只要輸入了相同的資料，就都能返回相同的結果，那它就滿足可重入性的要求，當然也就是執行緒安全的

執行緒本地儲存：如果一段程式碼中所需要的資料必須與其他程式碼共享，那就看看這些共享資料的程式碼是否能保證在同一個執行緒中執行？如果能保障，我們就可以把共享資料的可見範圍限制在同一個執行緒之內，這樣，無須同步也能保證執行緒之間不出現資料爭用的問題

7.2 鎖優化

適應性自旋、鎖消除、鎖粗化、輕量級鎖和偏向鎖

7.2.1 自旋鎖與自適應自旋

自旋鎖：如果物理機器上有一個以上的處理器，能讓兩個或以上的執行緒同時並行執行，我們就可以讓後面請求鎖的那個執行緒稍等一下，但不放棄處理器的執行時間，看看持有鎖的執行緒是否很快就會釋放鎖。為了讓執行緒等待，我們只需讓執行緒執行一個忙迴圈（自旋），這項技術就是所謂的自旋鎖

自適應自旋轉：是由前一次在同一個鎖物件上，自旋等待剛剛成功獲得過鎖，並且持有鎖的執行緒正在執行中，那麼虛擬機器就會認為這次自旋也很有可能再次成功，進而它將允許自旋等待持續相對更長的時間。如果對於某個鎖，自旋很少成功獲得過，那在以後要獲取這個鎖時將可能省略掉自過程，以避免浪費處理器資源。

7.2.2 鎖消除

鎖消除 是指虛擬機器即時編輯器在執行時，對一些程式碼上要求同步，但是被檢測到不可能存在共享資料競爭的鎖進行消除。如果在一段程式碼中。推上的所有資料都不會逃逸出去從而被其他執行緒訪問到，那就可以把它們當作棧上資料對待，認為它們是執行緒私有的，同步加鎖自然就無須進行

7.2.3 鎖粗化

如果虛擬機器檢測到有一串零碎的操作都是對同一物件的加鎖，將會把加鎖同步的範圍擴充套件（粗化）到整個操作序列的外部

7.2.4 輕量級鎖

7.2.5 偏向鎖

它的目的是消除無競爭情況下的同步原語，進一步提高程式的執行效能。如果輕量級鎖是在無競爭的情況下使用CAS操作去消除同步使用的互斥量，那偏向鎖就是在無競爭的情況下把這個同步都消除掉，CAS操作都不做了

如果在接下倆的執行過程中，該鎖沒有被其他執行緒獲取，則持有偏向鎖的執行緒將永遠不需要在進行同步

八、逃逸分析

逃逸分析的基本行為就是分析物件動態作用域：當一個物件在方法中被定義後，它可能被外部方法所引用。

例如作為呼叫引數傳遞到其他方法中，成為方法逃逸。甚至還可能被外部執行緒訪問到，比如賦值給類變數或可以在其他執行緒中訪問的例項變數，稱為執行緒逃逸。

如果一個物件不會逃逸到方法或執行緒之外，也就是別的方法或執行緒無法通過任何途徑訪問到這個物件，則可能為這個變數進行一些高效的優化

棧上分配：如果確定一個物件不會逃逸出方法外，那讓這個物件在棧上分配記憶體將會是一個不錯的注意，物件所佔用的記憶體空間就可以隨棧幀出棧而銷燬。如果能使用棧上分配，那大量的物件就隨著方法的結束而銷燬了，垃圾收集系統的壓力將會小很多

同步消除：如果確定一個變數不會逃逸出執行緒，無法被其他執行緒訪問，那這個變數的讀寫肯定就不會有競爭，對這個變數實施的同步措施也就可以消除掉

標量替換：標量就是指一個數據無法在分解成更小的資料表示了，int、long等及refrence型別等都不能在進一步分解，它們稱為標量。

如果一個數據可以繼續分解，就稱為聚合量，Java中的物件就是最典型的聚合量

如果一個物件不會被外部訪問，並且這個物件可以被拆散的化，那程式正在執行的時候將可能不建立這個物件，而改為直接建立它的若干個被這個方法使用到的成員變數來代替。

《深入理解java虛擬機器》 精華總結（面試）

文章目錄

一、執行時資料區域

1.1 程式計數器