【Java面試寶典】深刻理解JAVA虛擬機

1、運行時數據區域

　　線程隔離：線程隔離的意思，就是給不一樣的線程多分配的資源用，以作到不爭用。

　　線程共享：線程共享就是資源只有一個沒有辦法分配更多，只能共享。

　　Java虛擬機管理的內存包括幾個運行時數據內存：方法區、虛擬機棧、本地方法棧、堆、程序計數器，其中方法區和堆是由線程共享的數據區，其餘幾個是線程隔離的數據區。程序計數器，虛擬機棧，本地方法棧，隨線程而生，線程亡而亡

1.1 程序計數器

　　程序計數器是一塊較小的內存，他能夠看作是當前線程所執行的行號指示器。字節碼解釋器工做的時候就是經過改變這個計數器的值來選取下一條須要執行的字節碼的指令，分支、循環、跳轉、異常處理、線程恢復等基礎功能都須要依賴這個計數器來完成。若是線程正在執行的是一個Java方法，這個計數器記錄的是正在執行的虛擬機字節碼指令的地址；若是正在執行的是Native方法，這個計數器則爲空。此內存區域是惟一一個在Java虛擬機規範中沒有規定任何OutOfMemotyError狀況的區域。

• 線程私有的內存：

　　因爲Java虛擬機的多線程是經過線程輪流切換並分配處理器執行時間的方式來實現，在任何一個肯定的時間，一個處理器(對多核處理器來講是一個內核)只會執行一條線程中的指令。所以爲了爲了線程切換可以恢復到正確的執行位置上，每條線程都有一個獨立的線程計數器，各條線程之間計數器互不影響，獨立存儲，咱們叫這類內存區域線程私有的內存。

1.2 Java虛擬機棧

　　虛擬機棧描述的是Java方法執行的內存模型：每一個方法在執行的同時都會建立一個棧幀用於儲存局部變量表、操做數棧、動態連接、方法出口 等信息。每一個方法從調用直至完成的過程，就對應着一個棧幀在虛擬機棧中入棧到出棧的過程。

　　棧內存就是虛擬機棧，或者說是虛擬機棧中局部變量表的部分。

　　局部變量表存放了編輯期可知的各類基本數據類型（boolean、byte、char、short、int、float、long、double）、對象引用（refrence）類型和returnAddress類型（指向了一條字節碼指令的地址）

　　其中64位長度的 long 和 double 類型的數據會佔用兩個局部變量空間，其他的數據類型只佔用1個。

　　局部變量表所需的內存空間在編譯器間完成分配，當進入一個方法時，這個方法須要在幀中分配多大的局部變量空間是徹底肯定的，在方法運行期間不會改變局部變量表的大小。

　　Java虛擬機規範對這個區域規定了兩種異常情況：

1. 若是線程請求的棧深度大於虛擬機所容許的深度，將拋出StackOverflowError異常。
2. 若是虛擬機擴展時沒法申請到足夠的內存，就會拋出OutOfMemoryError異常。

1.3 本地方法棧

　　本地方法棧和虛擬機棧發揮的做用是很是相似的，他們的區別是虛擬機棧爲虛擬機執行Java方法（也就是字節碼）服務，而本地方法棧則爲虛擬機使用到的Native方法（Native Method就是一個Java調用非Java代碼的接口）服務。

　　本地方法棧區域也會拋出StackOverflowError和OutOfMemoryErroy異常。

1.4 Java堆

　　堆是Java虛擬機所管理的內存中最大的一塊。Java堆是被全部線程共享的一塊內存區域，在虛擬機啓動的時候建立，此內存區域的惟一目的是存放對象實例，幾乎全部的對象實例都在這裏分配內存。全部的對象實例和數組都在堆上分配。

　　Java堆是垃圾收集器管理的主要區域。Java堆細分爲新生代和老年代。無論怎樣，劃分的目的都是爲了更好的回收內存，或者更快地分配內存。

　　Java堆能夠處於物理上不連續的內存空間中，只要邏輯上是連續的便可。若是在堆中沒有完成實例分配，而且堆也沒法再擴展時將會拋出OutOfMemoryError異常。

1.5 方法區

　　方法區它用於儲存已被虛擬機加載的類信息、常量、靜態變量、即時編譯器編譯後的代碼等數據。

　　除了Java堆同樣不須要連續的內存和能夠選擇固定大小或者可擴展外，還能夠選擇不實現垃圾收集。這個區域的內存回收目標主要是針對常量池的回收和對類型的卸載。

　　當方法區沒法知足內存分配需求時，將拋出OutOfMemoryErroy異常。

1.6 運行時常量池

　　它是方法區的一部分。Class文件中除了有關的版本、字段、方法、接口等描述信息外、還有一項信息是常量池，用於存放編輯期生成的各類字面量和符號引用，這部份內容將在類加載後進入方法區的運行時常量池中存放。

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

　　當常量池沒法再申請到內存時會拋出OutOfMemoryError異常。

1.7 直接內存

　　直接內存並非虛擬機運行時數據區的一部分，也不是Java虛擬機規範中定義的內存區域。

　　NIO類是一種基於通道和緩衝區的I/O方式，它可使用Native函數庫直接分配堆外內存，而後經過一個儲存在Java堆中的DirectByteBuffer對象做爲這塊直接內存的引用進行操做，這樣避免了Java堆和Navie堆中來回複製數據。

2、HotSpot虛擬機對象

2.1 對象的建立

2.1.1 檢查

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

2.1.2 分配內存

　　接下來將爲新生對象分配內存，對象所需內存在類加載完畢以後就能夠徹底肯定，爲對象分配內存空間的任務等同於把一塊肯定的大小的內存從Java堆中劃分出來。

　　假設Java堆中內存是絕對規整的，全部用過的內存放在一遍，空閒的內存放在另外一邊，中間放着一個指針做爲分界點的指示器，那所分配內存就僅僅是把那個指針指向空閒空間那邊挪動一段與對象大小相等的距離，這個分配方式叫作「指針碰撞」。

　　若是Java堆中的內存並非規整的，已使用的內存和空閒的內存相互交錯，那就沒辦法簡單地進行指針碰撞了，虛擬機就必須維護一個列表，記錄上哪些內存塊是可用的，在分配的時候從列表中找到一塊足夠大的空間劃分給對象實例，並更新列表上的記錄，這種分配方式成爲「空閒列表」。

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

　　在分配內存的時候會出現併發的問題，好比在給A對象分配內存的時候，指針尚未來得及修改，對象B又同時使用了原來的指針進行了內存的分片。

　　有兩個解決方案：

1. 對分配的內存進行同步處理：CAS配上失敗重試的方式保證更新操做的原子性。
2. 把內存分配的動做按照線程劃分在不一樣的空間之中進行，即每一個線程在Java堆中分配一塊小內存，稱爲本地緩衝區，哪一個線程須要分配內存，就須要在本地緩衝區上進行，只有當緩衝區用完並分配新的緩衝區的時候，才須要同步鎖定。

2.1.3 Init

　　執行new指令以後會接着執行Init方法，進行初始化，這樣一個對象纔算產生出來。

2.2 對象的內存佈局

　　在HotSpot虛擬機中，對象在內存中儲存的佈局能夠分爲3塊區域：對象頭、實例數據、對齊填充。

　　對象頭包括兩部分：

　　a) 儲存對象自身的運行時數據，如哈希碼、GC分帶年齡、鎖狀態標誌、線程持有的鎖、偏向線程ID、偏向時間戳。

　　b) 另外一部分是指類型指針，即對象指向它的類元數據的指針，虛擬機經過這個指針來肯定這個對象是哪一個類的實例。

　　實例數據：

　　是對象正常儲存的有效信息，也是程序代碼中所定義的各類類型的字段內容。不管是從父類繼承下來的，仍是在子類中定義的，都須要記錄下來。

　　對齊填充:

　　不是必然存在的，僅僅是起到佔位符的做用。對象的大小必須是8字節的整數倍，而對象頭恰好是8字節的整數倍(1倍或者2倍)，當實例數據沒有對齊的時候，就須要經過對齊填充來補全

2.3 對象的訪問定位

2.3.1 使用句柄訪問

　　Java堆中將會劃分出一塊內存來做爲句柄池，reference中存儲的就是對象的句柄地址，而句柄中包含了對象實例數據與類型數據各自的具體地址。

　　優點：reference中存儲的是穩定的句柄地址，在對象被移動（垃圾收集時移動對象是很是廣泛的行爲）時只會改變句柄中的實例數據指針，而reference自己不須要修改。

2.3.2 使用直接指針訪問

　　Java堆對象的佈局就必須考慮如何訪問類型數據的相關信息，而refreence中存儲的直接就是對象的地址。

　　優點：速度更快，節省了一次指針定位的時間開銷，因爲對象的訪問在Java中很是頻繁，所以這類開銷聚沙成塔後也是一項很是可觀的執行成本。

3、OutOfMemoryError 異常（OOM）

3.1 Java堆溢出

　　Java堆用於存儲對象實例，只要不斷的建立對象，而且保證GC Roots到對象之間有可達路徑來避免垃圾回收機制清除這些對象，那麼在數量到達最大堆的容量限制後就會產生內存溢出異常。

　　若是是內存泄漏，可進一步經過工具查看泄漏對象到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建立的那個字符串實例是同一個。

4、垃圾收集

　　程序計數器、虛擬機棧、本地方法棧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」，也就是沒有任何String對象引用常量池的"abc"常量，也沒有其餘地方引用的這個字面量，這個時候發生內存回收這個常量就會被清理出常量池。

　　無用的類：

　　1.該類全部的實例都已經被回收，就是Java堆中不存在該類的任何實例；

　　2.加載該類的ClassLoader已經被回收；

　　3.該類對用的java.lang.Class對象沒有在任何地方被引用，沒法再任何地方經過反射訪問該類的方法；

4.4 垃圾收集算法

4.4.1 標記—清除算法(mark-sweep)

　　算法分爲標記和清除兩個階段：首先標記出全部須要回收的對象，在標記完成後統一回收全部被標記的對象。

　　不足：一個是效率問題，標記和清除兩個過程的效率都不高；另外一個是空間問題，標記清除以後會產生大量不連續的內存碎片，空間碎片太多可能會致使之後再程序運行過程當中須要分配較大的對象時，沒法找到足夠的連續內存而不得不提早觸發另外一次垃圾收集動做。

4.4.2 複製算法(copying)

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

　　不足：將內存縮小爲了原來的一半。

　　實際中咱們並不須要按照1:1比例來劃份內存空間，而是將內存分爲一塊較大的Eden空間和兩塊較小的Survivor空間，每次使用Eden和其中一塊Survivor，當另外一個Survivor空間沒有足夠空間存放上一次新生代收集下來的存活對象時，這些對象將直接經過分配擔保機制進入老年代。

4.4.3 標記整理算法(mark-compact)

　　讓全部存活的對象都向一端移動，而後直接清理掉端邊界之外的內存。

4.4.4 分代收集算法

　　只是根據對象存活週期的不一樣將內存劃分爲幾塊。通常是把java堆分爲新生代和老年代，這樣就能夠根據各個年代的特色採用最適當的收集算法。在新生代中，每次垃圾收集時都發現有大批對象死去，只有少許存活，那就選用複製算法，只須要付出少許存活對象的複製成本就能夠完成收集。而老年代中由於對象存活率高、沒有額外空間對它進行分配擔保，就必須使用標記清理或者標記整理算法來進行回收。

4.5 垃圾收集器

4.5.1 Serial 收集器

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

4.5.2 ParNew 收集器

　　Serial 收集器的多線程版本，除了使用了多線程進行收集以外，其他行爲和Serial收集器同樣。

　　並行：指多條垃圾收集線程並行工做，但此時用戶線程仍然處於等待狀態。

　　併發：指用戶線程與垃圾收集線程同時執行（不必定是並行的，可能會交替執行），用戶程序在繼續執行，而垃圾收集程序運行於另外一個CPU上。

4.5.3 Parallel Scavenge

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

　　吞吐量：就是CPU用於運行用戶代碼的時間與CPU總消耗時間的比值。吞吐量 = 運行用戶代碼時間 /（運行用戶代碼時間+垃圾收集時間）

4.5.4 Serial Old 收集器

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

4.5.5 Parallel Old 收集器

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

4.5.6 CMS收集器

　　CMS並不是沒有暫停，而是用兩次短暫停來替代串行標記整理算法的長暫停，它的收集週期是這樣：

　　初始標記(CMS-initial-mark) -> 併發標記(CMS-concurrent-mark) -> 從新標記(CMS-remark) -> 併發清除(CMS-concurrent-sweep) ->併發重設狀態等待下次CMS的觸發(CMS-concurrent-reset)。

　　其中的1，3兩個步驟須要暫停全部的應用程序線程的。第一次暫停從root對象開始標記存活的對象，這個階段稱爲初始標記；第二次暫停是在併發標記以後， 暫停全部應用程序線程，從新標記併發標記階段遺漏的對象（在併發標記階段結束後對象狀態的更新致使）。第一次暫停會比較短，第二次暫停一般會比較長，而且 remark這個階段能夠並行標記。
　　而併發標記、併發清除、併發重設階段的所謂併發，是指一個或者多個垃圾回收線程和應用程序線程併發地運行，垃圾回收線程不會暫停應用程序的執行，若是你有多於一個處理器，那麼併發收集線程將與應用線程在不一樣的處理器上運行，顯然，這樣的開銷就是會下降應用的吞吐量。Remark階段的並行，是指暫停了全部應用程序後，啓動必定數目的垃圾回收進程進行並行標記，此時的應用線程是暫停的。

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

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

　　優勢：併發收集、低停頓。

　　缺點：

　　1.CMS收集器對CPU資源很是敏感，CMS默認啓動的回收線程數是（CPU數量+3）/4；

　　2.CMS收集器沒法處理浮動垃圾，可能會出現「Concurrent Mode Failure(併發模式故障)」失敗而致使Full GC產生；

　　3.CMS是基於標記清除算法實現的。

4.5.7 G1收集器

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

　　1.並行與併發：利用多CPU縮短STOP-The-World停頓的時間；

　　2.分代收集；

　　3.空間整合：不會產生內存碎片；

　　4.可預測的停頓；

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

4.6 內存分配與回收策略

　　MinorGC:清理新生代

　　MajorGC:清理老年代

　　FullGC:清理整個堆空間

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.5 空間分配擔保

　　在發生Minor GC以前，虛擬機會檢查老年代最大可用的連續空間是否大於新生代全部對象總空間，若是這個條件成立，那麼Minor GC能夠確保是安全的。若是不成立，則虛擬機會查看HandlePromotionFailure設置值是否容許擔保失敗。若是容許那麼會繼續檢查老年代最大可用的連續空間是否大於晉級到老年代對象的平均大小，若是大於，將嘗試進行一次Minor GC，儘管此次MinorGC 是有風險的：若是小於，或者HandlePromotionFailure設置不容許冒險，那這時也要改成進行一次Full GC。

5、虛擬機類加載機制

　　虛擬機把描述類的數據從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.常量在編譯階段會存入調用類的常量池中，本質上並無直接引用到定義常量的類，所以不會觸發定義常量的類的初始化；

　　4.接口的初始化：接口在初始化時，並不要求其父接口所有完成類初始化，只有在正整使用到父接口的時候（如引用接口中定義的常量）纔會初始化；

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個階段的檢驗動做：文件格式驗證，元數據驗證，字節碼驗證，符號引用驗證

• 文件格式驗證

　　第一階段要驗證字節流是否符合Class文件格式的規範，而且能被當前版本的虛擬機處理。這一階段可能包括：

　　1) 是否以魔數oxCAFEBABE開頭；

　　2) 主、次版本號是否在當前虛擬機處理範圍以內；

　　3) 常量池的常量中是否有不被支持的常量類型(檢查常量tag標誌)；

　　4) 指向常量的各類索引值中是否有指向不存在的常量或不符合類型的常量；

　　5) CONSTANT_Itf8_info 型的常量中是否有不符合UTF8編碼的數據；

　　6) Class文件中各個部分及文件自己是否有被刪除的或附加的其餘信息；

　　這個階段的驗證時基於二進制字節流進行的，只有經過類這個階段的驗證後，字節流纔會進入內存的方法區進行存儲，因此後面的3個驗證階段所有是基於方法區的存儲結構進行的，不會再直接操做字節流。

• 元數據驗證

　　1) 這個類是否有父類(除了java.lang.Object以外,全部的類都應當有父類)；

　　2) 這個類的父類是否繼承了不容許被繼承的類（被final修飾的類）；

　　3) 若是這個類不是抽象類，是否實現類其父類或接口之中要求實現的全部方法；

　　4) 類中的字段、方法是否與父類產生矛盾(列如覆蓋類父類的final字段,或者出現不符合規則的方法重載，列如方法參數都一致，但返回值類型卻不一樣等)；

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

• 字節碼驗證

　　第三階段是整個驗證過程當中最複雜的一個階段，主要目的彷佛經過數據流和控制流分析，肯定程序語言是合法的、符合邏輯的。在第二階段對元數據信息中的數據類型作完校驗後，這個階段將對類的方法體進行校驗分析，保證被校驗類的方法在運行時不會作出危害虛擬機安全的事件。

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

　　2) 保證跳轉指令不會跳轉到方法體之外的字節碼指令上；

　　3) 保證方法體中的類型轉換時有效的，列如能夠把一個子類對象賦值給父類數據類型，這個是安全的，可是吧父類對象賦值給子類數據類型，甚至把對象賦值給與它毫無繼承關係、徹底不相干的一個數據類型，則是危險和不合法的；

• 符號引用驗證

發生在虛擬機將符號引用轉化爲直接引用的時候，這個轉化動做將在鏈接的第三階段——解析階段中發生。

　　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的類達到替換的攻擊方式。

6、Java內存模型與線程

6.1 內存間的交互操做

　　Java內存模型的主要目標是定義程序中各個變量的訪問規則，即在虛擬機中將變量存儲到內存和從內存中取出變量這樣底層細節。此處的變量與Java編程時所說的變量不同，指包括了實例字段、靜態字段和構成數組對象的元素，可是不包括局部變量與方法參數，後者是線程私有的，不會被共享。

　　Java內存模型中規定了全部的變量都存儲在主內存中，每條線程還有本身的工做內存（能夠與前面將的處理器的高速緩存類比），線程的工做內存中保存了該線程使用到的變量到主內存副本拷貝，線程對變量的全部操做（讀取、賦值）都必須在工做內存中進行，而不能直接讀寫主內存中的變量。不一樣線程之間沒法直接訪問對方工做內存中的變量，線程間變量值的傳遞均須要在主內存來完成，線程、主內存和工做內存的交互關係以下圖所示。

　　關於主內存與工做內存之間的具體交互協議，即一個變量如何從主內存拷貝到工做內存、如何從工做內存同步到主內存之間的實現細節，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.結束：已終止線程的線程狀態，線程已經結束執行

7、線程安全

　　1）不可變：不可變的對象必定是線程安全的、不管是對象的方法實現仍是方法的調用者，都不須要再採起任何的線程安全保障。例如：把對象中帶有狀態的變量都聲明爲final，這樣在構造函數結束以後，它就是不可變的。

　　2）絕對線程安全

　　3）相對線程安全：相對的線程安全就是咱們一般意義上所講的線程安全，它須要保證對這個對象單獨的操做是線程安全的，咱們在調用的時候不須要作額外的保障措施，可是對於一些特定順序的連續調用，就可能須要在調用端使用額外的同步手段來保證調用的正確性。

　　4）線程兼容：對象自己並非線程安全的，可是能夠經過在調用端正確地使用同步手段來保證對象在併發環境中能夠安全使用。

　　5）線程對立：是指不管調用端是否採起了同步措施，都沒法在多線程環境中併發使用的代碼。

7.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.2 鎖優化

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

7.2.1 自旋鎖與自適應自旋

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

　　自適應自旋轉：是由前一次在同一個鎖對象上，自旋等待剛剛成功得到過鎖，而且持有鎖的線程正在運行中，那麼虛擬機就會認爲此次自旋也頗有可能再次成功，進而它將容許自旋等待持續相對更長的時間。若是對於某個鎖，自旋不多成功得到過，那在之後要獲取這個鎖時將可能省略掉自過程，以免浪費處理器資源。

7.2.2 鎖消除

　　鎖消除是指虛擬機即時編輯器在運行時，對一些代碼上要求同步，可是被檢測到不可能存在共享數據競爭的鎖進行消除。若是在一段代碼中。推上的全部數據都不會逃逸出去從而被其餘線程訪問到，那就能夠把它們看成棧上數據對待，認爲它們是線程私有的，同步加鎖天然就無須進行。

7.2.3 鎖粗化

　　若是虛擬機檢測到有一串零碎的操做都是對同一對象的加鎖，將會把加鎖同步的範圍擴展（粗化）到整個操做序列的外部。

7.2.4 輕量級鎖

7.2.5 偏向鎖

　　它的目的是消除無競爭狀況下的同步原語，進一步提升程序的運行性能。若是輕量級鎖是在無競爭的狀況下使用CAS操做去消除同步使用的互斥量，那偏向鎖就是在無競爭的狀況下把這個同步都消除掉，CAS操做都不作了。

　　若是在接下倆的執行過程當中，該鎖沒有被其餘線程獲取，則持有偏向鎖的線程將永遠不須要在進行同步。

8、逃逸分析

　　逃逸分析的基本行爲就是分析對象動態做用域：當一個對象在方法中被定義後，它可能被外部方法所引用，例如做爲調用參數傳遞到其餘方法中，成爲方法逃逸。甚至還可能被外部線程訪問到，好比賦值給類變量或能夠在其餘線程中訪問的實例變量，稱爲線程逃逸。

　　若是一個對象不會逃逸到方法或線程以外，也就是別的方法或線程沒法經過任何途徑訪問到這個對象，則可能爲這個變量進行一些高效的優化。

棧上分配：若是肯定一個對象不會逃逸出方法外，那讓這個對象在棧上分配內存將會是一個不錯的注意，對象所佔用的內存空間就能夠隨棧幀出棧而銷燬。若是能使用棧上分配，那大量的對象就隨着方法的結束而銷燬了，垃圾收集系統的壓力將會小不少。

　　同步消除：若是肯定一個變量不會逃逸出線程，沒法被其餘線程訪問，那這個變量的讀寫確定就不會有競爭，對這個變量實施的同步措施也就能夠消除掉。

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

　　若是一個數據能夠繼續分解，就稱爲聚合量，Java中的對象就是最典型的聚合量。

　　若是一個對象不會被外部訪問，而且這個對象能夠被拆散的化，那程序正整執行的時候將可能不建立這個對象，而改成直接建立它的若干個被這個方法使用到的成員變量來代替。