一、運行時數據區域
Java虛擬機管理的內存包括幾個運行時數據內存：方法區、虛擬機棧、本地方法棧、堆、程序計數器，其中方法區和堆是由線程共享的數據區，其他幾個是線程隔離的數據區
1.1 程序計數器
程序計數器是一塊較小的內存，他可以看做是當前線程所執行的行號指示器。字節碼解釋器工作的時候就是通過改變這個計數器的值來選取下一條需要執行的字節碼的指令，分支、循環、跳轉、異常處理、線程恢復等基礎功能都需要依賴這個計數器來完成。如果線程正在執行的是一個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個區域隨線程而生，隨線程而滅，在這幾個區域內就不需要過多考慮回收的問題，因爲方法結束或者線程結束時，內存自然就跟隨着回收了
1.判斷對象存活
4.1.1 引用計數器法
給對象添加一個引用計數器，每當由一個地方引用它時，計數器值就加1；當引用失效時，計數器值就減1；任何時刻計數器爲0的對象就是不可能再被使用的
4.1.2 可達性分析算法
通過一系列的成爲“GC Roots”的對象作爲起始點，從這些節點開始向下搜索，搜索所走過的路徑成爲引用鏈，當一個對象到GC ROOTS沒有任何引用鏈相連時，則證明此對象時不可用的
Java語言中GC Roots的對象包括下面幾種：
1.虛擬機棧（棧幀中的本地變量表）中引用的對象
2.方法區中類靜態屬性引用的對象
3.方法區中常量引用的對象
4.本地方法棧JNI（Native方法）引用的對象
2.引用
強引用就是在程序代碼之中普遍存在的，類似Object obj = new Object() 這類的引用，只要強引用還存在，垃圾收集器永遠不會回收掉被引用的對象
軟引用用來描述一些還有用但並非必須的元素。對於它在系統將要發生內存溢出異常之前，將會把這些對象列進回收範圍之中進行第二次回收，如果這次回收還沒有足夠的內存纔會拋出內存溢出異常
弱引用用來描述非必須對象的，但是它的強度比軟引用更弱一些，被引用關聯的對象只能生存到下一次垃圾收集發生之前，當垃圾收集器工作時，無論當前內存是否足夠都會回收掉只被弱引用關聯的對象
虛引用的唯一目的就是能在這個對象被收集器回收時收到一個系統通知
3.Finalize方法
任何一個對象的finalize()方法都只會被系統自動調用一次，如果對象面臨下一次回收，它的finalize()方法不會被再次執行，因此第二段代碼的自救行動失敗了
4.3.1 回收方法區
永久代的垃圾收集主要回收兩部分內容：廢棄常量和無用的類
廢棄常量：假如一個字符串abc已經進入了常量池中，如果當前系統沒有任何一個String對象abc，也就是沒有任何Stirng對象引用常量池的abc常量，也沒有其他地方引用的這個字面量，這個時候發生內存回收這個常量就會被清理出常量池
無用的類：
1.該類所有的實例都已經被回收，就是Java堆中不存在該類的任何實例
2.加載該類的ClassLoader已經被回收
3.該類對用的java.lang.Class對象沒有在任何地方被引用，無法再任何地方通過反射訪問該類的方法
4.垃圾收集算法
4.4.1 標記—清除算法
算法分爲標記和清除兩個階段：首先標記出所有需要回收的對象，在標記完成後統一回收所有被標記的對象、
不足:一個是效率問題，標記和清除兩個過程的效率都不高；另一個是空間問題，標記清楚之後會產生大量不連續的內存碎片，空間碎片太多可能會導致以後再程序運行過程中需要分配較大的對象時，無法找到足夠的連續內存而不得不提前觸發另一次垃圾收集動作
4.4.2 複製算法
他將可用內存按照容量劃分爲大小相等的兩塊，每次只使用其中的一塊。當這塊的內存用完了，就將還存活着的對象複製到另外一塊上面，然後再把已使用過的內存空間一次清理掉。這樣使得每次都是對整個半區進行內存回收，內存分配時也就不用考慮內存碎片等複雜情況，只要移動堆頂指針，按順序分配內存即可
不足：將內存縮小爲了原來的一半
實際中我們並不需要按照1:1比例來劃分內存空間，而是將內存分爲一塊較大的Eden空間和兩塊較小的Survivor空間，每次使用Eden和其中一塊Survivor
當另一個Survivor空間沒有足夠空間存放上一次新生代收集下來的存活對象時，這些對象將直接通過分配擔保機制進入老年代
4.4.3 標記整理算法
讓所有存活的對象都向一端移動，然後直接清理掉端邊界以外的內存
4.4.4 分代收集算法
只是根據對象存活週期的不同將內存劃分爲幾塊。一般是把java堆分爲新生代和老年代，這樣就可以根據各個年代的特點採用最適當的收集算法。在新生代中，每次垃圾收集時都發現有大批對象死去，只有少量存活，那就選用複製算法，只需要付出少量存活對象的複製成本就可以完成收集。而老年代中因爲對象存活率高、沒有額外空間對它進行分配擔保，就必須使用標記清理或者標記整理算法來進行回收
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.可預測的停頓
運作方式：初始標記，併發標記，最終標記，篩選回收
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指令是程序被編譯後，存放於類構造器<clinit>()方法之中，所以把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 線程安全的實現方法
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方法即可
2.非阻塞同步
3.無同步方案
可重入代碼：也叫純代碼，可以在代碼執行的任何時刻中斷它，轉而去執行另外一段代碼（包括遞歸調用它本身）而在控制權返回後，原來的程序不會出現任何錯誤。所有的可重入代碼都是線程安全的，但是並非所有的線程安全的代碼都是可重入的。
判斷一個代碼是否具備可重入性：如果一個方法，它的返回結果是可預測的，只要輸入了相同的數據，就都能返回相同的結果，那它就滿足可重入性的要求，當然也就是線程安全的
線程本地存儲：如果一段代碼中所需要的數據必須與其他代碼共享，那就看看這些共享數據的代碼是否能保證在同一個線程中執行？如果能保障，我們就可以把共享數據的可見範圍限制在同一個線程之內，這樣，無須同步也能保證線程之間不出現數據爭用的問題
7.2鎖優化
適應性自旋、鎖消除、鎖粗化、輕量級鎖和偏向鎖
7.2.1 自旋鎖與自適應自旋
自旋鎖：如果物理機器上有一個以上的處理器，能讓兩個或以上的線程同時並行執行，我們就可以讓後面請求鎖的那個線程稍等一下，但不放棄處理器的執行時間，看看持有鎖的線程是否很快就會釋放鎖。爲了讓線程等待，我們只需讓線程執行一個忙循環（自旋），這項技術就是所謂的自旋鎖
自適應自旋轉：是由前一次在同一個鎖對象上，自旋等待剛剛成功獲得過鎖，並且持有鎖的線程正在運行中，那麼虛擬機就會認爲這次自旋也很有可能再次成功，進而它將允許自旋等待持續相對更長的時間。如果對於某個鎖，自旋很少成功獲得過，那在以後要獲取這個鎖時將可能省略掉自過程，以避免浪費處理器資源。
7.2.2 鎖消除
鎖消除是指虛擬機即時編輯器在運行時，對一些代碼上要求同步，但是被檢測到不可能存在共享數據競爭的鎖進行消除。如果在一段代碼中。推上的所有數據都不會逃逸出去從而被其他線程訪問到，那就可以把它們當作棧上數據對待，認爲它們是線程私有的，同步加鎖自然就無須進行
7.2.3鎖粗化
如果虛擬機檢測到有一串零碎的操作都是對同一對象的加鎖，將會把加鎖同步的範圍擴展（粗化）到整個操作序列的外部
7.2.4 輕量級鎖
7.2.5 偏向鎖
它的目的是消除無競爭情況下的同步原語，進一步提高程序的運行性能。如果輕量級鎖是在無競爭的情況下使用CAS操作去消除同步使用的互斥量，那偏向鎖就是在無競爭的情況下把這個同步都消除掉，CAS操作都不做了
如果在接下倆的執行過程中，該鎖沒有被其他線程獲取，則持有偏向鎖的線程將永遠不需要在進行同步
八、逃逸分析
逃逸分析的基本行爲就是分析對象動態作用域：當一個對象在方法中被定義後，它可能被外部方法所引用，例如作爲調用參數傳遞到其他方法中，成爲方法逃逸。甚至還可能被外部線程訪問到，比如賦值給類變量或可以在其他線程中訪問的實例變量，稱爲線程逃逸
如果一個對象不會逃逸到方法或線程之外，也就是別的方法或線程無法通過任何途徑訪問到這個對象，則可能爲這個變量進行一些高效的優化
棧上分配：如果確定一個對象不會逃逸出方法外，那讓這個對象在棧上分配內存將會是一個不錯的注意，對象所佔用的內存空間就可以隨棧幀出棧而銷燬。如果能使用棧上分配，那大量的對象就隨着方法的結束而銷燬了，垃圾收集系統的壓力將會小很多
同步消除：如果確定一個變量不會逃逸出線程，無法被其他線程訪問，那這個變量的讀寫肯定就不會有競爭，對這個變量實施的同步措施也就可以消除掉
標量替換：標量就是指一個數據無法在分解成更小的數據表示了，int、long等及refrence類型等都不能在進一步分解，它們稱爲標量。
如果一個數據可以繼續分解，就稱爲聚合量，Java中的對象就是最典型的聚合量
如果一個對象不會被外部訪問，並且這個對象可以被拆散的化，那程序正在執行的時候將可能不創建這個對象，而改爲直接創建它的若干個被這個方法使用到的成員變量來代替。