java虛拟機彙總

part1會提到的問題：

深入了解虛拟機之Java記憶體區域：

1. 介紹下Java記憶體區域（運作時資料區）。
2. 對象的通路定位的兩種方式。

深入了解虛拟機之垃圾回收

1. 如何判斷對象是否死亡（兩種方法）。
2. 簡單的介紹一下強引用、軟引用、弱引用、虛引用（虛引用與軟引用和弱引用的差別、使用軟引用能帶來的好處）。
3. 垃圾收集有哪些算法，各自的特點？
4. HotSpot為什麼要分為新生代和老年代？
5. 常見的垃圾回收器有那些？
6. 介紹一下CMS,G1收集器。
7. Minor Gc和Full GC 有什麼不同呢？

虛拟機性能監控和故障處理工具

1. JVM調優的常見指令行工具有哪些？

深入了解虛拟機之類檔案結構

1. 簡單介紹一下Class類檔案結構（常量池主要存放的是那兩大常量？Class檔案的繼承關系是如何确定的？字段表、方法表、屬性表主要包含那些資訊？）

深入了解虛拟機之虛拟機類加載機制

1. 簡單說說類加載過程，裡面執行了哪些操作？
2. 對類加載器有了解嗎？
3. 什麼是雙親委派模型？
4. 雙親委派模型的工作過程以及使用它的好處。

part2重點看的：

• JDK 是什麼
• JRE 是什麼
• Java曆史版本的特性
  • • Java Version SE 50
    • Java Version SE 6
    • Java Version SE 7
    • Java 8
• 運作時資料區域包括哪些
  • • 程式計數器線程私有
    • Java 虛拟機棧線程私有
    • 本地方法棧線程私有
    • Java 堆線程共享
    • 方法區線程共享
    • 運作時常量池
• Java 中對象通路是如何進行的
• 如何判斷對象是否死去
  • 什麼是引用計數法
    • 引用計數法的缺點
  • 什麼是根搜尋算法
• Java 的4種引用方式
  • • 強引用
    • 軟引用
    • 弱引用
    • 虛引用
• 有哪些垃圾收集算法
  • 标記-清除算法Mark-Sweep
    • 什麼是标記-清除算法
    • 有什麼缺點
  • 複制算法Copying- 新生代
    • 優點
    • 缺點
    • 應用
  • 标記-整理算法Mark-Compact-老年代
  • 分代收集算法
• Minor GC 和 Full GC有什麼差別
• Java 記憶體
  • 為什麼要将堆記憶體分區
  • 堆記憶體分為哪幾塊
  • 分代收集算法
    • 記憶體配置設定有哪些原則
    • Young Generation Space 采用複制算法
    • Tenure Generation Space采用标記-整理算法
    • Permanent Space
• Class檔案
  • • Java虛拟機的平台無關性
    • Class檔案的組成
    • 魔數與Class檔案的版本
• 類加載器
  • • 類加載器的作用是什麼
    • 類加載器有哪些
• 類加載機制
  • • 什麼是雙親委派模型
    • 為什麼要使用雙親委派模型組織類加載器之間的關系
    • 什麼是類加載機制
• 虛拟機和實體機的差別是什麼
• 運作時棧幀結構
• Java 方法調用
  • • 什麼是方法調用
    • Java的方法調用有什麼特殊之處
    • Java虛拟機調用位元組碼指令有哪些
    • 虛拟機是如何執行方法裡面的位元組碼指令的
    • 解釋執行
• 基于棧的指令集和基于寄存器的指令集
  • • 什麼是基于棧的指令集
    • 什麼是基于寄存器的指令集
    • 基于棧的指令集的優缺點
• Javac編譯過程分為哪些步驟
• 什麼是即時編譯器
• 解釋器和編譯器
  • • 為什麼要采用分層編譯
    • 分層編譯器有哪些層次
• 編譯對象與觸發條件
  • • 熱點代碼有哪些
    • 如何判斷一段代碼是不是熱點代碼
    • HotSpot虛拟機使用第二種有兩個計數器
    • 方法調用計數器統計方法
• 有哪些經典的優化技術即時編譯器
  • • 公共子表達式消除
    • 數組邊界檢查消除
    • 方法内聯
    • 逃逸分析
• 如果對象不會逃逸到方法或線程外可以做什麼優化
• Java與CC的編譯器對比
• 實體機如何處理并發問題
• Java 記憶體模型
  • 什麼是Java記憶體模型
  • Java記憶體模型的目标
    • 主記憶體與工作記憶體
    • 記憶體間的互動操作
    • 原子性可見性有序性
• volatile
  • • 什麼是volatile
    • 為什麼基于volatile變量的運算在并發下不一定是安全的
    • 為什麼使用volatile
• 并發與線程
  • • 并發與線程的關系
    • 什麼是線程
    • 實作線程有哪些方式
    • Java線程的實作
• Java線程排程
  • • 什麼是線程排程
    • 線程排程有哪些方法
• 線程安全的定義
• Java語言操作的共享資料包括哪些
  • • 不可變
• 如何實作線程安全
  • • 阻塞同步互斥同步
    • 非阻塞同步
• 鎖優化是在JDK的那個版本
  • • 為什麼要提出自旋鎖
    • 自旋鎖的原理
    • 自旋的缺點
    • 什麼是自适應自旋
    • 鎖消除
    • 鎖粗化
    • 輕量級鎖
    • 偏向鎖

part3精華總結：

一.運作時資料區域 

　　Java虛拟機管理的記憶體包括幾個運作時資料記憶體：方法區、虛拟機棧、堆、本地方法棧、程式計數器，其中方法區和堆是由線程共享的資料區，其他幾個是線程隔離的資料區。 

　　1.1程式計數器 

　　程式計數器是一塊較小的記憶體，他可以看做是目前線程所執行的行号訓示器。位元組碼解釋器工作的時候就是通過改變這個計數器的值來選取下一條需要執行的位元組碼的指令，分支、循環、跳轉、異常處理、線程恢複等基礎功能都需要依賴這個計數器來完成。如果線程正在執行的是一個Java方法，這個計數器記錄的是正在執行的虛拟機位元組碼指令的位址；如果正在執行的是Native方法（native關鍵字說明其修飾的方法是一個原生态方法，方法對應的實作不是在目前檔案，而是在用其他語言（如C和C++）實作的檔案中。Java語言本身不能對作業系統底層進行通路和操作，但是可以通過JNI接口調用其他語言來實作對底層的通路。JNI是Java本機接口（Java Native Interface），JNI允許Java代碼使用以其他語言編寫的代碼和代碼庫），這個計數器則為空。此記憶體區域是唯一 一個在Java虛拟機規範中沒有規定任何OutOfMemoryError情況的區域。 

　　1.2Java虛拟機棧 

　　虛拟機棧描述的是Java方法執行的記憶體模型：每個方法在執行的同時都會建立一個棧幀用于儲存局部變量表、操作數棧、動态連結、方法出口等資訊。每個方法從調用直至完成的過程，就對應着一個棧幀在虛拟機棧中入棧到出棧的過程。 

　　棧記憶體就是虛拟機棧，或者說是虛拟機棧中局部變量表的部分。局部變量表存放了編輯期可知的各種基本資料類型（boolean、byte、char、short、int、long、double、float）、對象引用（reference）類型和returnAddress類型（指向了一條位元組碼指令的位址） 

　　其中64位長度的long和double類型的資料會占用兩個局部變量空間，其餘的資料類型隻占用1個。 

　　Java虛拟機規範對這個區域規定了兩種異常狀況：如果線程請求的棧深度大于虛拟機所允許的深度，将抛出StackOverflowError異常。如果虛拟機擴充時無法申請到足夠的記憶體，就會抛出OutOfMemoryError異常。 

　　1.3本地方法棧 

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

　　本地方法棧區域也會抛出StackOverflowError和OutOfMemoryError異常。 

　　1.4Java堆 

　　堆是Java虛拟機所管理的記憶體中最大的一塊。Java堆是被所有線程共享的一塊記憶體區域，在虛拟機啟動的時候建立，此記憶體區域的唯一目的是存放對象執行個體，幾乎所有的對象執行個體都在這裡配置設定記憶體。所有的對象執行個體和數組都在堆上配置設定。 

　　Java堆是垃圾收集器管理的主要區域。Java堆細分為新生代和老年代。不管怎樣，劃分的目的都是為了更好的回收記憶體，或者更快的配置設定記憶體。 

　　Java堆可以處于實體上不連續的記憶體空間中，隻要邏輯上連續是連續的即可。若在堆中沒有完成執行個體配置設定，并且堆也無法再擴充時，将會抛出OutOfMemoryError異常。 

　　1.5方法區 

　　方法區用于儲存已被虛拟機加載的類資訊、常量、靜态變量、即時編譯器編譯後的代碼等資料。 

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

　　當方法區無法滿足記憶體配置設定需求時，将抛出OutOfMemoryError異常。 

　　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塊區域：對象頭、執行個體資料和對齊填充。 

　　對象頭包括兩個部分： 

　　a)儲存對象自身的運作時資料，如哈希碼，GC分帶、鎖狀态标志、線程持有的鎖、遍向線程ID、偏向時間戳。 

　　b)另一部分是指類型指針，即對象指向它的類中繼資料的指針，虛拟機通過這麼指針來确定這個對象是哪個類的執行個體。 

　　2.3對象的通路定位 

　　1）.使用句柄通路 

　　Java堆中将會劃分出一塊記憶體來作為句柄池，reference中存儲的就是對象的句柄位址，而句柄中包含了對象執行個體資料與類型資料各自的具體位址。 

　　優勢：reference中存儲的是穩點的句柄位址，在對象被移動（垃圾收集時對象是非常普遍的行為）時，隻會改變句柄中的執行個體資料指針，而reference本身不需要修改。 

　　2）使用直接指針通路 

　　Java堆對象的布局就必須考慮如何通路類型資料的相關資訊，而reference中存儲的直接就是對象的位址。 

　　優勢：速度更快，節省了一次指針定位的時間開銷，由于對象的通路在Java中非常頻繁，是以這類開銷積少成多後也是一項非常可觀的執行成本。

三.OutOfMemoryError異常

如果這種虛拟機不支援動态擴充，那麼将會抛出StackOverflow異常。如果支援動态擴充，那麼這個棧會請求再擴充部分空間。當然記憶體不是無窮的，如果頻繁擴充記憶體，以至于無法再繼續擴充了，這時候會抛出OutOfMemory異常。

　　3.1Java堆溢出 

　　StringBuilder 建立的字元串執行個體在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沒有任何引用鍊相連時（用圖論的話來說就是從GC Roots到這個對象不可達），則證明此對象是不可用的。 

　Java語言中GC Roots的對象包括下面幾種： 

　1.虛拟機棧（棧幀中的本地變量表）中引用的對象 

　2.方法區中類靜态屬性引用的對象 

　3.方法區中常量引用的對象 

　4.本地方法棧JNI（Native方法）引用的對象

　2）.引用 

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

　 軟引用是用來描述一些還有用但并非必須的元素。對于它在系統将要發生記憶體溢出異常之前，将會把這些對象列進回收範圍之中進行第二回收，如果這次回收還沒有足夠的記憶體才會抛出記憶體溢出異常。 

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

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

　３).Finalize()方法 

　任何一個對象的finalize()方法都隻會被系統自動調用一次，如果對象面臨下一次回收，它的finalize()方法不會被再次執行，是以第二段代碼的自救行動失敗了。 

　4.3.1 回收方法區 

　　對于習慣在HotSpot虛拟機上開發、 部署程式的開發者來說，很多人都更願意把方法區稱為“永久代”（Permanent Generation），本質上兩者并不等價，僅僅是因為HotSpot虛拟機的設計團隊選擇把GC分代收集擴充至方法區，或者說使用永久代來實作方法區而已，這樣HotSpot的垃圾收集器可以像管理Java堆一樣管理這部分記憶體，能夠省去專門為方法區編寫記憶體管理代碼的工作。 

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

　　廢棄常量：假如一個字元串abc已經進入常量池中，如果目前系統沒有任何一個String對象abc，也就是沒有任何String對象引用常量池的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收集器： 

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

　　　b)ParNew收集器： 

　　　Serial收集器的多線程版本，除了使用了多線程進行收集以外，其餘行為和Serial收集器一樣 

　　　并行：指多條垃圾收集線程并行工作，但此時使用者線程仍然處于等待狀态 

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

　　　c)Parallel Scanvenge 

　　　該收集器是一個新生代收集器，它是使用複制算法的收集器，又是并行的多線程收集器。 

　　　吞吐量：就是CPU用于運作使用者代碼的時間與CPU總消耗時間的比值。即吞吐量=運作使用者代碼時間/（運作使用者代碼時間+垃圾收集時間） 

　　　d)Serial old收集器: 

　　　是Serial收集器的老年代版本，是一個單線程收集器，使用标記整理算法。 

　　　e)Parallel Old收集器： 

　　　是Parallel Scavenge收集器的老年代版本，使用多線程和标記整理算法。 

　　　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才能晉級到老年代，如果在Survivor空間中相同年齡所有對象的大小總和大于Survivor空間的一半，年齡大于或等于該年齡的對象就可以直接進入到老年代，無須登到MaxTenuringThreshold中要求的年齡。 

　空間配置設定擔保： 

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

　五.虛拟機類加載機制 

　　虛拟機把描述類的資料從class檔案加載到記憶體，并對資料進行校驗、轉換解析和初始化，最終形成可以被虛拟機直接使用的Java類型，這就是虛拟機的類加載機制，在Java語言裡面，類型的加載、連接配接和初始化過程都是在程式運作期間完成的。 

　　5.1類加載的時機 

　　類被加載到虛拟機記憶體中開始，到解除安裝為止，整個生命周期包括：加載、驗證、準備、解析、初始化、使用和解除安裝7個階段。加載、驗證、準備、初始化和解除安裝這5個階段的順序是确定的，類的加載過程必須按照這種順序按部就班的開始，而解析階段則不一定，它在某些情況下可以在初始化階段之後再開始，這個是為了支援Java語言運作時綁定（也成為動态綁定或晚期綁定）。 

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

　　1.遇到new、gesture、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.是否以0xCAFEBABA開頭。2.主、次版本号是否在目前虛拟機處理範圍内。3.常量池的常量中是否有不被支援的常量類型（檢驗常量tag标志）。4.指向常量的各種索引值中是否有指向不存在的常量或不符合類型的常量。5.CONSTANT_Itf8_info型的常量中是否有不符合UTF8編碼的資料。6.Class檔案中各個部分及檔案本身是否有被删除的或附加的其他資訊 

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

　　2.中繼資料驗證 

　　　　1.這個類是否有父類(除了java.lang.Object之外,所有的類都應當有父類) 

　　　　２.這個類的父類是否繼承了不允許被繼承的類（被final修飾的類） 

　　　　３.如果這個類不是抽象類，是否實作類其父類或接口之中要求實作的所有方法 

　　　　４.類中的字段、方法是否與父類産生沖突(列如覆寫類父類的final字段,或者出現不符合規則的方法重載，列如方法參數都一緻，但傳回值類型卻不同等) 

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

　　３.位元組碼驗證 

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

　　　１．保證任意時刻操作數棧的資料類型與指令代碼序列都能配合工作，列如在操作數棧放置類一個int類型的資料，使用時卻按long類型來加載入本地變量表中。 

　　　２.保證跳轉指令不會跳轉到方法體以外的位元組碼指令上 

　　　3.保證方法體中的類型轉換時有效的，例如可以把一個子類對象指派給父類資料類型，這個是安全的，但是吧父類對象指派給子類資料類型，甚至把對象指派給與它毫無繼承關系、完全不相幹的一個資料類型，則是危險和不合法的。 

　　4.符号引用驗證 

　　發生在虛拟機将符号引用轉化為直接引用的時候，這個轉化動作将在連接配接的第三階段——解析階段中發生。

　　　1.符号引用中通過字元串描述的全限定名是否能找到相對應的類

　　　2.在指定類中是否存在符合方法的字段描述符以及簡單名稱所描述的方法和字段

　　　3.符号引用中的類、字段、方法的通路性是否可被目前類通路

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

　　５.2.3準備 

　　準備階段是正式為類變量配置設定記憶體并設定類變量初始值的階段，這些變量都在方法區中進行配置設定。這個時候進行記憶體配置設定的僅包括類變量(被static修飾的變量)，而不包括執行個體變量，執行個體變量将會在對象執行個體化時随着對象一起配置設定在Java堆中。其次，這裡說的初始值通常下是資料類型的零值。

假設public static int value = 123；

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

　　5.2.4解析

　　解析階段是虛拟機将常量池内符号引用替換為直接引用的過 

　　５.2.5初始化 

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

　　 

　　5.3類的加載器 

　　5.3.1雙親委派模型： 

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

　　啟動類加載器（Bootstrap ClassLoader），負責将存放在lib目錄中的，或者被-Xbootclasspath系統變量所指定的路徑中的,并且是虛拟機識别的類庫加載到虛拟機記憶體中 

　　擴充類加載器（Extension ClassLoader），負責加載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類型體系中最基礎的行為也就無法保證，應用程式也将會變得一片混亂

實作雙親委派模型的代碼都集中在java.lang.ClassLoader的loadClass()方法中，邏輯清晰：先檢查是否已經被加載過，若沒有加載則調用父加載器的loadClass()方法，若父加載器為空則預設使用啟動類加載器作為父加載器，如果父類加載失敗，抛出ClassNotFoundException異常後，再調用自己的findClass()方法進行加載。

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

六.Java記憶體模型與線程 

　　６.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.joke()方法結束、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中的對象就是最典型的聚合量

如果一個對象不會被外部通路，并且這個對象可以被拆散的化，那程式正整執行的時候将可能不建立這個對象，而改為直接建立它的若幹個被這個方法使用到的成員變量來代替

其他部落格推薦：https://segmentfault.com/u/hugogao ， https://blog.csdn.net/maydaysar