【Java面试宝典】深入理解JAVA虚拟机
一、運行時數據區域
線程隔離：線程隔離的意思，就是給不同的線程多分配的資源用，以做到不爭用。
線程共享：線程共享就是資源只有一個沒有辦法分配更多，只能共享。
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.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堆中來回復制數據。
二、HotSpot虛擬機對象
2.1?對象的創建
2.1.1 檢查
虛擬機遇到一條new指令時，首先將去檢查這個指令的參數是否能在常量池中定位到一個類的符號引用，并且檢查這個符號引用代表的類是否已經被加載、解析和初始化過。如果沒有，那必須先執行相應的類加載過程。
2.1.2 分配內存
接下來將為新生對象分配內存，對象所需內存在類加載完畢之后就可以完全確定，為對象分配內存空間的任務等同于把一塊確定的大小的內存從Java堆中劃分出來。
假設Java堆中內存是絕對規整的，所有用過的內存放在一遍，空閑的內存放在另一邊，中間放著一個指針作為分界點的指示器，那所分配內存就僅僅是把那個指針指向空閑空間那邊挪動一段與對象大小相等的距離，這個分配方式叫做“指針碰撞”。
如果Java堆中的內存并不是規整的，已使用的內存和空閑的內存相互交錯，那就沒辦法簡單地進行指針碰撞了，虛擬機就必須維護一個列表，記錄上哪些內存塊是可用的，在分配的時候從列表中找到一塊足夠大的空間劃分給對象實例，并更新列表上的記錄，這種分配方式成為“空閑列表”。
選擇那種分配方式由Java堆是否規整決定，而Java堆是否規整又由所采用的垃圾收集器是否帶有壓縮整理功能決定。
在分配內存的時候會出現并發的問題，比如在給A對象分配內存的時候，指針還沒有來得及修改，對象B又同時使用了原來的指針進行了內存的分片。
有兩個解決方案：
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中非常頻繁，因此這類開銷積少成多后也是一項非常可觀的執行成本。
三、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創建的那個字符串實例是同一個。
四、垃圾收集
程序計數器、虛擬機棧、本地方法棧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。
五、虛擬機類加載機制
虛擬機把描述類的數據從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的類達到替換的攻擊方式。
六、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.結束：已終止線程的線程狀態，線程已經結束執行
七、線程安全
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操作都不做了。
如果在接下倆的執行過程中，該鎖沒有被其他線程獲取，則持有偏向鎖的線程將永遠不需要在進行同步。
八、逃逸分析
逃逸分析的基本行為就是分析對象動態作用域：當一個對象在方法中被定義后，它可能被外部方法所引用，例如作為調用參數傳遞到其他方法中，成為方法逃逸。甚至還可能被外部線程訪問到，比如賦值給類變量或可以在其他線程中訪問的實例變量，稱為線程逃逸。
如果一個對象不會逃逸到方法或線程之外，也就是別的方法或線程無法通過任何途徑訪問到這個對象，則可能為這個變量進行一些高效的優化。
棧上分配：如果確定一個對象不會逃逸出方法外，那讓這個對象在棧上分配內存將會是一個不錯的注意，對象所占用的內存空間就可以隨棧幀出棧而銷毀。如果能使用棧上分配，那大量的對象就隨著方法的結束而銷毀了，垃圾收集系統的壓力將會小很多。
同步消除：如果確定一個變量不會逃逸出線程，無法被其他線程訪問，那這個變量的讀寫肯定就不會有競爭，對這個變量實施的同步措施也就可以消除掉。
標量替換：標量就是指一個數據無法在分解成更小的數據表示了，int、long等及refrence類型等都不能在進一步分解，它們稱為標量。
如果一個數據可以繼續分解，就稱為聚合量，Java中的對象就是最典型的聚合量。
如果一個對象不會被外部訪問，并且這個對象可以被拆散的化，那程序正整執行的時候將可能不創建這個對象，而改為直接創建它的若干個被這個方法使用到的成員變量來代替。
作者：郭耀華
出處：http://www.guoyaohua.com
微信：guoyaohua167
郵箱：guo.yaohua@foxmail.com
本文版權歸作者和博客園所有，歡迎轉載，轉載請標明出處。
總結
以上是生活随笔為你收集整理的【Java面试宝典】深入理解JAVA虚拟机的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 必须知道的八大种排序算法【java实现】
- 下一篇： 一文看懂Transformer内部原理（