1.1 概述

Java優(yōu)點：

1、結構嚴謹，面向對象

2、擺脫硬件平臺束縛，實現(xiàn)了“一次編寫，到處運行”的理想;

3、提供了一個相對安全的內(nèi)存管理和訪問機制，避免了絕大部分的內(nèi)存泄漏和指針越界問題；

4、實現(xiàn)了熱點代碼檢測和運行時編譯和優(yōu)化，使得Java應用隨著運行時間的增加而獲得更高的性能；

5、它有一套完善份應用程序接口，還有無數(shù)商業(yè)機構和開源社區(qū)的第三方類庫幫助它實現(xiàn)各種各樣的功能；

Java的這些好處使得開發(fā)的效率得到極大的提高！

1.2 Java技術體系

Sun官方定義的Java技術體系包括以下幾個組成部分：

1、Java程序設計語言

2、各種硬件平臺上的Java虛擬機

3、Class文件格式

4、Java API類庫

5、來自商業(yè)機構和開源社區(qū)的第三方Java類庫

JDK：

我們可以把 Java程序設計語言，Java虛擬機，API類庫這三部分統(tǒng)稱為JDK，JDK是用于支持Java程序開發(fā)的最小環(huán)境。

JRE:

我們可以把Java API類庫中的Java SE API子集和Java虛擬機這兩部分統(tǒng)稱為JRE，JRE是支持Java程序運行的標準環(huán)境。

- 下圖展示Java技術體系包含的內(nèi)容，及JDK、JRE涵蓋的范圍：

若按技術服務領域劃分，Java技術體系可分為4個平臺：

1、Java Card：支持一些Java小程序（Applets）運行在小內(nèi)存設備（如智能卡）上的平臺。

2、Java ME：支持Java程序運行在移動終端（手機、PDA）上的平臺，對Java API有所精簡，并加入了針對移動終端的支持，這個版本以前稱為J2ME。

3、Java SE：支持面向桌面及應用（如Windows下的應用程序）的Java平臺，提供了完整的Java核心API，這個版本以前稱為J2SE。

4、Java EE：支持使用多層架構的企業(yè)應用（如ERP、CRM應用）的Java平臺，除了提供Java SE API以外，還對其做了大量的擴充并提供了相關的部署支持，這個版本以前稱為J2EE。

2、Java內(nèi)存區(qū)域與內(nèi)存溢出異常

2.1、運行時數(shù)據(jù)區(qū)域

2.1.1、程序計數(shù)器

Java虛擬機規(guī)范中沒有任何OutOfMemoryError情況的區(qū)域

程序計數(shù)器是一塊較小的內(nèi)存空間，它可以看作是當前線程所執(zhí)行的字節(jié)碼的行號指示器。在虛擬機的概念模型（僅在模型概念里，各種虛擬機可能通過更高效的方式去實現(xiàn)）里，字節(jié)碼解釋器工作時就是通過改變這個計數(shù)器的值來選取下一條需要執(zhí)行的字節(jié)碼指令，分支、循環(huán)、跳轉、異常處理、線程恢復等基礎功能都需要依賴這個計數(shù)器來完成。

由于Java虛擬機的多線程是通過 線程輪流切換并分配處理器執(zhí)行時間的方式來實現(xiàn)的，在任何一個確定的時刻，一個處理器（對于多核處理器來說是一個內(nèi)核），都會只執(zhí)行一條線程中的指令。因此，為了線程切換后能恢復到正確的執(zhí)行位置，每條線程都需要一個獨立的程序計數(shù)器，各條線程之間計數(shù)器互不影響，獨立存儲，我們稱這類內(nèi)存區(qū)域為“線程私有”的內(nèi)存。

如果線程正在執(zhí)行一個是一個Java方法，這個計數(shù)器記錄的是正在執(zhí)行的虛擬機字節(jié)碼指令的地址；如果正在執(zhí)行的是Native方法，這個計數(shù)器值則為空（Undefined）。

2.1.2、Java虛擬機棧

與程序計數(shù)器一樣，Java虛擬機棧也是線程私有的，它的生命周期與線程相同。虛擬機棧描述的是Java方法執(zhí)行的內(nèi)存模型：每個方法在執(zhí)行的同時都會創(chuàng)建一個棧幀（Stack Frame）用于存儲?局部變量表、操作數(shù)棧、動態(tài)鏈接、方法出口 ?等信息。每一個方法從調(diào)用直至執(zhí)行完成的過程，就對應著一個棧幀在虛擬機棧中入棧到出棧的過程。

經(jīng)常有人把Java內(nèi)存區(qū)分為堆內(nèi)存（Heap）和棧內(nèi)存（Stack），這種分法比較粗糙，Java內(nèi)存區(qū)域的劃分實際上遠閉著復雜。這里所指的“?！本褪?/b>虛擬機棧，或者說是虛擬機棧中的局部變量表部分。

局部變量表存放了編譯期可知的各種基本數(shù)據(jù)類型（boolean、byte、char、short、int、float、long、double）、對象引用（reference類型，它不等于對象本身，可能是一個指向對象起止地址的引用指針，也可能是指向一個代表對象的句柄或者其他與此對象相關的位置）和returnAddress（指向一條字節(jié)碼指令的地址）。

其中64位長度的 long 和 double 類型的數(shù)據(jù)會占用2個局部變量空間（Slot），其余數(shù)據(jù)類型只占用1個。局部變量所需的內(nèi)存空間在編譯期間完成分配，當進入一個方法時，這個方法需要的在幀中分配的局部變量空間是完全確定的，在方法運行期間不會改變局部變量表的大小。

在Java虛擬機規(guī)范中，對這個區(qū)域規(guī)定了兩種異常情況：如果線程請求的棧深度大于虛擬機所允許的深度，將拋出StackOverflowError異常；如果虛擬機棧可以動態(tài)擴展（當前大部分虛擬機都可以動態(tài)擴展，只不過Java虛擬機規(guī)范中也允許固定長度的虛擬機棧），如果擴展時無法申請到足夠的內(nèi)存，就會拋出OutOfMemoryError異常。

2.1.3、本地方法棧

本地方法棧與虛擬機棧所發(fā)揮的作用非常相似，它們間的區(qū)別是虛擬機棧為執(zhí)行Java方法（也就是字節(jié)碼）服務，兒本地方法棧則為虛擬機棧使用到的Native方法服務。

在虛擬機規(guī)范中對本地方法棧中方法使用的語言、使用方式與數(shù)據(jù)結構并沒有強制規(guī)定，因此具體的虛擬機可以自由的實現(xiàn)它。甚至有的虛擬機（如Sun HotSpot虛擬機）直接把本地方法棧和虛擬機棧合二為一。

與虛擬機棧一樣，本地方法棧也會拋出 StackOverflowError 和 OutOfMemoryError異常。

2.1.4、Java堆

對于大多數(shù)應用來說，Java堆是Java虛擬機所管理的內(nèi)存中最大的一塊。Java堆是被所有線程共享的一塊內(nèi)存區(qū)域，在虛擬機啟動時創(chuàng)建。此內(nèi)存區(qū)域的唯一目的是為了存放對象實例，幾乎所有的對象實例都在這里分配內(nèi)存。這一點在Java虛擬機規(guī)范中的描述是：所有的對象實例以及數(shù)組都要在堆上分配。

Java堆是垃圾收集器管理的主要區(qū)域，因此很多時候也被稱為“GC堆”。

從內(nèi)存回收的角度來看，由于現(xiàn)在收集器基本都采用分代收集算法，所以Java堆中還可以細分為：新生代和老年代；再細致一點可以分為Eden空間，F(xiàn)rom Survivor空間、To Survivor空間等。

從內(nèi)存分配的角度來看，線程共享的Java堆中可能劃分出多個線程私有的分配緩沖區(qū)。

不過無論怎么劃分，都與存放的內(nèi)容無關，存儲的都依然是對象實例，進一步劃分的目的是為了更好的地回收內(nèi)存，或者更快的分配內(nèi)存。

根據(jù)Java虛擬機規(guī)范中的規(guī)定，Java堆可以處于物理上的不連續(xù)的內(nèi)存空間中，只要邏輯上是連續(xù)的即可，就像我們的磁盤空間一樣，在實現(xiàn)時，既可以實現(xiàn)為固定大小的，也可以是可拓展的，不過當前主流的虛擬機都是按照可拓展來實現(xiàn)的通過（-Xmx和-Xms控制）。如果堆中沒有內(nèi)存完成實例分配，并且堆也無法再擴展時，將會拋出OutOfMemoryError異常。

2.1.5 方法區(qū)

方法區(qū)與Java堆一樣，是各個線程共享的內(nèi)存區(qū)域，它用于存儲已被虛擬機加載的類信息、常量、靜態(tài)變量，即時編譯器編譯的代碼等數(shù)據(jù)。雖然Java虛擬機規(guī)范把方法區(qū)描述為堆的一個邏輯部分，但它還有一個別名Non-Heap（非堆），目的是為了和Java堆區(qū)分開來。

Java虛擬機規(guī)范對方法區(qū)的限制十分寬松，除了像堆一樣不需要連續(xù)的內(nèi)存和可以固定大小或者可拓展外，還可以選擇不實現(xiàn)垃圾收集。相對而言垃圾收集行為在這個區(qū)域比較少出現(xiàn)，但并非數(shù)據(jù)進入了方法區(qū)就永久存在了。這個區(qū)域的內(nèi)存回收目標主要針對常量池的回收和對類型的卸載，一般來說，這個區(qū)域的回收比較難以令人滿意，尤其是類型的卸載，條件相當苛刻，但這部分區(qū)域的回收確實是必要的。

根據(jù)Java虛擬機規(guī)范規(guī)定，當方法區(qū)無法滿足內(nèi)存分配需求時，將會拋出OutOfMemoryError異常。

2.1.6運行時常量池

運行時常量池（Runtime Constant Pool）是方法區(qū)的一部分。Class文件中除了有類的版本信息、字段、方法、接口等描述信息外，還有一項信息是常量池（Constant Pool Table），用于存放編譯期生成的各種字面量和符號引用，這部分內(nèi)容將在類加載進入方法區(qū)的運行時常量池存放。

Java虛擬機對Class文件的每一部分（包括常量池）的格式都有嚴格的規(guī)定，每一個字節(jié)用于存儲哪種數(shù)據(jù)都必須符合規(guī)范上的需求才會被虛擬機認可、裝載和執(zhí)行，但對于運行時常量池，Java虛擬機沒有做任何細節(jié)的要求。一般來說，除了保存Class文件中描述的符號引用外，還會把翻譯出來的直接引用也存儲在運行時常量池中。

運行時常量池相對于Class文件常量池的的另外一個重要特征是具備動態(tài)性，Java語言并不要求常量一定只有編譯期才產(chǎn)生，也就是并非預置入Class文件中常量池的內(nèi)容才能進入方法區(qū)運行時常量池，運行期間也可能將新的常量放入池中，這種特性被開發(fā)人員利用的比較多的便是String類的intern()方法。

運行時常量池是方法區(qū)的一部分，自然受到方法區(qū)內(nèi)存的限制，當常量無法再申請到內(nèi)存時會拋出OutOfMemoryError異常。

2.1.7 直接內(nèi)存

直接內(nèi)存（Direct Memory）并不是虛擬機運行時數(shù)據(jù)區(qū)的一部分，也不是Java虛擬機規(guī)范中定義的內(nèi)存區(qū)域。但這部分內(nèi)存也被頻繁地使用，而且也可能導致OutOfMemoryError異常。

在JDK1.4中新加入NIO（New Input/Output）類，引入了一種基于通道（Channel）與緩沖區(qū)（Buffer）的I/O方式，它可以使用Native函數(shù)庫直接分配堆外內(nèi)存，然后通過一個存儲在Java堆中的DirectByBuffer對象作為這塊內(nèi)存的引用進行操作。這樣能在一些場景中顯著提高性能，因為避免了Java堆和Native堆中來回復制數(shù)據(jù)。

顯然，本機直接內(nèi)存的分配不受Java堆的大小限制，但是既然是內(nèi)存，肯定還是受到本機總內(nèi)存（包括RAM以及SWAP區(qū)或者分頁文件）大小以及處理器尋址空間的限制。服務器管理員在配置虛擬機參數(shù)時，會根據(jù)實際內(nèi)存設置-Xmx等參數(shù)信息，但經(jīng)常忽略直接內(nèi)存，使得各個內(nèi)存區(qū)域內(nèi)存總和大于物理內(nèi)存限制（包括物理的和操作系統(tǒng)級的限制），從而導致動態(tài)擴展時出現(xiàn)OutOfMemoryError異常。

2.2 對象探秘

2.2.1 對象的創(chuàng)建

Java是一門面向對象的編程語言，在Java程序運行過程中無時無刻都有對象被創(chuàng)建出來。在語言層面上通常僅僅是一個new關鍵字而已，而在虛擬機中 ，當虛擬機遇到一條new指令時，首先將去檢查這個符號的引用是否已被加載、解析和初始化過。如果沒有那必須先執(zhí)行相應的類加載過程。

在類加載檢查通過后，接下來虛擬機將為新生的對象分配內(nèi)存。對象所需內(nèi)存大小在類加載完成后便可以完全確定，為對象分配空間的任務等同于把一塊確定大小的內(nèi)存從Java堆中劃分出來。劃分方式有兩種：指針碰撞 、空閑列表

指針碰撞：假設Java堆中內(nèi)存是絕對規(guī)整的，所有用過的內(nèi)存都放在一邊，空閑的內(nèi)存放在一邊，中間放著一個指針作為分界點的指示器，那所分配內(nèi)存就僅僅是把那個指針向空閑空間那邊挪動一段與對象大小相等的距離，這種分配方式稱為“指針碰撞”（Bump the Pointer）。

空閑列表： 假設Java堆中的內(nèi)存并不是規(guī)整的，已使用的內(nèi)存和空閑的內(nèi)存相互交錯，那就沒辦法進行簡單的指針碰撞了，虛擬機就必須維護一個列表，記錄上哪塊內(nèi)存是可用的，在分配的時候從列表中找出一塊足夠大的空間劃分給對象實例，并更新列表上的記錄，這種方式稱為“空閑列表”（Free List）

除如何劃分可用空間外，還有另外一種需要考慮的問題是對象創(chuàng)建在虛擬機中是非常頻繁的行為，即使是僅僅修改一個指針所指向的位置，在并發(fā)情況下也并不是線程安全的，可能出現(xiàn)正在給對象A分配內(nèi)存，指針還沒來得及修改，對象B又同時使用了原來的指針來分配內(nèi)存的情況。解決這個問題的實際方案有兩種，一種是對分配內(nèi)存的動作進行同步處理----實際上虛擬機采用CAS配上失敗重試的方式保證重新操作的原子性；另一種是把內(nèi)存分配的的動作按照線程劃分在不同的空間內(nèi)進行，即每個線程在Java堆中預先分配一小塊內(nèi)存，稱為本地線程緩沖（Thread Local Allocation Buffer，TLAB）。哪個線程要分配內(nèi)存，就在哪個線程的TLAB上分配，只有TLAB用完并分配新的TLAB時，才需要同步鎖定。虛擬機是否使用TLAB，可以通過-XX:+/-UserTLAB參數(shù)來設定。

內(nèi)存分配完畢后，虛擬機需要將分配到的內(nèi)存空間都初始化為零值（不包括對象頭），如果使用TLAB，這一工作過程也可以提前至TLAB分配時進行。這一步操作保證了對象的實例字段在Java代碼中可以不賦初始值就直接使用，程序能訪問到這些字段的數(shù)據(jù)類型所對應的零值。

接下來，虛擬機要對對象進行必要的設置，例如這個對象是哪個類的實例，如何才能找到類的元數(shù)據(jù)信息，對象的哈希碼，對象的GC分代年齡等信息。這些信息存放在對象頭（Object Header）中，根據(jù)虛擬機當前的運行狀態(tài)的不同，如是否啟用偏向鎖等，對象頭會有不同的設置方式。

在上面工作都完成之后，從虛擬機的視角來看，一個新的對象已經(jīng)產(chǎn)生了，但從Java程序的視角來看，對象創(chuàng)建才剛剛開始-----<init>方法還沒有執(zhí)行，所有字段都還為零。所以，一般來說，執(zhí)行new指令之后會接著執(zhí)行<init>方法，把對象按照程序員的意愿進行初始化，這樣一個真正可用的對象才算真正產(chǎn)生出來。

2.2.2 對象的內(nèi)存布局

在HotSpot虛擬機中，對象在內(nèi)存中的存儲布局可以分為3塊區(qū)域：對象頭（Header）、實例數(shù)據(jù)（Instance Data）和對齊填充（Padding）。

HotSpot虛擬機的對象頭包括兩部分信息，第一部分用于存儲對象自身的運行時數(shù)據(jù)，如哈希碼（HashCode）、GC分代年齡、鎖狀態(tài)標志、線程持有的鎖、偏向線程ID、偏向時間戳等，這部分數(shù)據(jù)的長度在32位和64位的虛擬機（未開啟壓縮指針）中分別為32bit和64bit，官方稱它為“Mark Word”。對象需要存儲的運行時數(shù)據(jù)很多，其實已經(jīng)超出了32位、 64位Bitmap結構所能記錄的限度，但是對象頭信息是與對象自定義的數(shù)據(jù)無關的額外存儲成本，考慮到虛擬機的空間效率，Mark Word被設計成一個非固定的數(shù)據(jù)結構以便在極小的空間內(nèi)存儲盡量多的信息，它會根據(jù)對象的狀態(tài)復用自己的存儲空間。

對象頭的另一部分是類型指針，即對象指向它的類元素數(shù)據(jù)的指針，虛擬機通過這個指針來確定這個對象是哪個類的實例。并不是所有的虛擬機實現(xiàn)都必須在對象數(shù)據(jù)上保留類型指針，換句話說，查找對象的元數(shù)據(jù)信息并不是一定要經(jīng)過對象本身。

實例數(shù)據(jù)部分是對象真正存儲的有效信息，也是在程序代碼中所定義的各種類型的字段的內(nèi)容。無論是從父類繼承下來的，還是在子類中定義的，都需要記錄起來。這部分的存儲順序會受到虛擬機分配策略參數(shù)（FieldAllocationStyle）和字段在Java源碼中定義順序的影響。HotSpot虛擬機默認的分配策略為longs/doubles、ints、shorts/chars、bytes/booleans、opps(Ordinary Object Pointers)、從分配策略中可以看出，相同寬度的字段總是被分配到一起。在滿足這個前提條件的情況下，在父類中定義的變量會出現(xiàn)在子類之前。如果CompactFields參數(shù)值為true（默認情況下），那么子類之中較窄的變量也可能會插入到父類變量的空隙中。

第三部分對齊填充并不是必然存在的，也沒有特別的含義，它僅僅起著占位符的作用。由于HotSpot VM的自動內(nèi)存管理系統(tǒng)要求對象起止地址必須是8字節(jié)的整數(shù)倍，換句話說，對象的大小必須是8字節(jié)的整數(shù)倍。而對象頭部分正好是8字節(jié)的倍數(shù)（1倍或者2倍），因此，當對象實例數(shù)據(jù)部分沒有對齊時，就需要通過對齊填充來補全。

2.2.3對象的訪問定位

建立對象是為了使用對象，Java程序通過棧上的reference數(shù)據(jù)來操作堆上的具體對象。由于reference類型在Java虛擬機規(guī)范中只規(guī)定了一個指向對象的引用，并沒有定義這個引用應該通過何種方式去定位、訪問堆中對象的具體位置，所以對象的訪問方式也是取決于虛擬機實現(xiàn)而定的。面前主流的訪問方式有使用句柄和直接使用指針兩種。

如果使用句柄訪問的話，那么Java堆中將會劃分出一塊內(nèi)存來作為句柄池，reference中存儲的就是對象的句柄地址，而句柄中包含了對象實例數(shù)據(jù)與類型數(shù)據(jù)各自的具體地址信息。

如果是使用指針直接訪問，那么Java堆對象的布局就必須考慮如何放置訪問類型數(shù)據(jù)的相關信息，而reference中直接存儲的就是對象地址：

這兩種對象的訪問方式各有優(yōu)勢，使用句柄來訪問的最大好處就是reference中存儲的是穩(wěn)定的句柄地址，在對象被移動（垃圾收集時移動對象是非常普遍的行為）時只會改變句柄中的實例數(shù)據(jù)指針，而reference本身不需要修改。

使用指針訪問方式的最大好處就是速度更快，它節(jié)省了一次指針定位的時間開銷，由于對象的訪問在Java中非常頻繁，因此這類開銷積少成多后也是一項非常可觀的執(zhí)行成本。就HotSpot而言，它使用的是第二種方式進行對象訪問的，但從整個軟件開發(fā)的范圍來看，各種語言和框架使用句柄來訪問的情況也十分常見。

2.3 ?OutOfMemoryError異常

在Java虛擬機規(guī)范的描述中，除了程序計數(shù)器外，虛擬機內(nèi)存的其他幾個運行時區(qū)域都有發(fā)生OutofMemoryErro異常的可能。

2.3.1 Java堆溢出

Java堆用于存儲對象實例，只要不斷地創(chuàng)建對象，并且保證GC Roots到對象之間有可達路徑來避免垃圾回收機制清除這些對象，那么在對象數(shù)量達到最大堆的容量限制后就會產(chǎn)生內(nèi)存溢出。

2.3.2 虛擬機棧和本地方法棧溢出

如果線程請求的棧的深度大于虛擬機所允許的最大深度，將會拋出StackOverflowError異常。

如果虛擬機在擴展棧時無法申請到足夠的空間，則拋出OutOfMemoryError異常。

這里把異常分為兩種情況，看似更加嚴謹，但存在著一些相互重疊的地方：當?？臻g無法繼續(xù)分配時，到底是內(nèi)存太小，還是已使用的占空間太大，其本質(zhì)只是對統(tǒng)計一件事的兩種描述而已。

在單線程下無論是由于棧太大還是虛擬機棧容量太小，當內(nèi)存無法分配時，虛擬機拋出的都是StackOverflowError異常。

通過不斷建立線程的方式倒是可以產(chǎn)生內(nèi)存溢出異常，但是這樣產(chǎn)生的內(nèi)存溢出異常與?？臻g是否足夠大并不存在任何聯(lián)系，或者準確地說，在這種情況下，為每個線程分配的內(nèi)存越大，反而越容易產(chǎn)生內(nèi)存溢出異常。

其實不難理解，操作系統(tǒng)分配給每個進程的內(nèi)存是有限制的，譬如32位的Windows限制為2GB,虛擬機提供了參數(shù)來控制Java堆和方法區(qū)的這兩部分內(nèi)存的最大值。剩余的內(nèi)存為2GB（操作系統(tǒng)限制）減去Xmx（最大堆容量），再減去MaxPermSize（最大方法區(qū)容量），程序計數(shù)器消耗內(nèi)存很小，可以忽略掉。如果虛擬機進程本身耗費的內(nèi)存不計算在內(nèi)，剩下的內(nèi)存就有虛擬機棧和本地方法棧“瓜分”了。每個線程分配到的棧容量越大，可以建立的線程數(shù)量自然越少，建立線程時就越容易把剩下的內(nèi)存耗盡。

如果建立過多線程導致的內(nèi)存溢出，在不能減少線程數(shù)或者更換64位虛擬機的情況下，就只能通過減少最大堆和減少棧容量來換取更多的線程。

3 垃圾收集器與內(nèi)存分配策略

3.1 對象已死嗎？

在堆中存放著Java世界中幾乎所有的實例對象，垃圾收集器在堆進行回收以前，第一件事就是要確定這些對象之中哪些還“存活”著，哪些已經(jīng)“死去”（即不可能再被任何途徑的對象使用的對象）。

3.2.1 引用計數(shù)法

很多教科書判斷對象是否存活的算法是這樣的：給對象中添加一個引用計數(shù)器，每當有一個地方引用它時，計數(shù)器值就加1；當引用失效時，計數(shù)器值就減1；任何時刻計數(shù)器為0的對象就不能再被使用。

客觀地說，引用計數(shù)法（Reference Counting）的實現(xiàn)簡單，判定效率也很高，在大部分情況下它都是一個不錯的算法，但是主流的Java虛擬機里面沒有選用引用計數(shù)算法來管理內(nèi)存，其中最主要的原因是它很難解決對象之間相互循環(huán)引用的問題；

舉個例子：對象objA和對象objB都有字段instance，賦值令objA.instance=objB 及 objB.instance =objA,除此之外，這兩個對象再無任何引用，實際上這兩個對象已經(jīng)不可能再被訪問，但是它們因為互相引用著對方，導致它們的引用計數(shù)都不為0，于是引用計算算法無法通知GC收集器回收它們。

3.2.2 可達性算法分析

在主流的商用語言程序（Java、C#等）的主流實現(xiàn)中，都是通過可達性分析（Reachability Analysis）來判斷對象是否存活的。這個算法的基本思路就是通過一系列的稱為“GC Roots”的對象作為起始點，從這些節(jié)點開始向下搜索，搜索所走過的路徑稱為引用鏈（Reference Chain），當一個對象到GC Roots 沒有任何引用鏈相連，則證明此對象是不可用的。

在Java語言中，可作為GC Roots的對象包括下面幾種：

1、虛擬機棧（棧幀中的本地變量表）中引用的對象。

2、方法區(qū)中類靜態(tài)屬性引用的對象。

3、方法區(qū)中常量引用的對象

4、本地方法棧中JNI（即一般說的Native方法）引用的對象

3.2.3 再談引用

無論是通過引用計數(shù)算法判斷對象的引用數(shù)量，還是通過可達性分析算法判斷對象的引用鏈是否可達，判斷對象是否“存活”都與“引用”有關。在JDK1.2以前，Java中的引用的定義很傳統(tǒng)：如果reference類型的數(shù)據(jù)中存儲的數(shù)值代表的是另一塊內(nèi)存的起止地址值，就稱這塊內(nèi)存代表著一個引用。這種定義很純粹，但是過于狹隘，一個對象在這種定義下只有被引用或者沒有被引用兩種狀態(tài)，對于描述一些“食之無味，用之可惜”的對象就顯得無能為力了。我們希望能描述這樣一類對象：當內(nèi)存空間還足夠時，則能保留在內(nèi)存中；如果內(nèi)存空間在垃圾收集后，還是非常緊張，則可以拋棄這些對象。很多系統(tǒng)的緩存功能都符合這樣的場景。

在JDK1.2之后，Java對引用的概念進行了擴充，將引用分為強引用（Strong Reference）、軟引用（Soft Reference）、弱引用（Weak Reference）、虛引用（Phantom Reference）4種，這4種引用的強度依次逐漸減弱。

強引用：在代碼中普遍存在的，類似“Object object = new Object（）”這類的引用，只要強引用還在，垃圾回收器永遠不會回收掉被引用的對象。

軟引用：用來描述一些還有但并非必須的對象。對于軟引用關聯(lián)的對象，在系統(tǒng)將要發(fā)生內(nèi)存溢出異常之前，將會把這些對象列進回收范圍之中進行第二次回收。如果這次回收還沒有足夠的內(nèi)存，才會拋出內(nèi)存溢出異常。

弱引用：用來描述非必需對象，但是它的強度比軟引用更弱一些，被弱引用關聯(lián)的對象只能生存到下一次垃圾收集發(fā)生之前。在垃圾收集器工作時，無論當前內(nèi)存是否足夠，都會回收掉只被弱引用關聯(lián)的對象。

虛引用也稱為幽靈引用，或者幻影引用，它是最弱的一種引用關系。一個對象是否有虛引用的存在，完全不會對其生存時間構成影響，也無法通過虛引用來取得一個對象實例。為一個對象設置虛引用關聯(lián)的唯一目的就是能在這個對象被收集器回收時收到一個系統(tǒng)通知。

3.2.4 生存還是死亡

即使在可達性分析算法中不可達的對象，也并非是“非死不可”的，這時候它們暫時處于“緩刑”階段，要真正宣告一個對象死亡，至少要經(jīng)歷兩次標記過程：如果對象在進行可達性分析后發(fā)現(xiàn)沒有與GC Roots相連接的引用鏈，那它將會被第一次標記并且進行一次篩選，篩選的條件是此對象是否有必要執(zhí)行的finalize()方法。當對象沒有覆蓋finaliza()方法，或者finalize()方法已經(jīng)被虛擬機調(diào)用過，虛擬機將這兩種情況都視為“沒有必要執(zhí)行”。

如果這個對象被判定有必要執(zhí)行finalize()方法，那么這個對象將會放置在一個叫做F-Queue的隊列中，并在稍后由一個虛擬機自動機建立的、低優(yōu)先級的Finalizer線程去執(zhí)行它，這里所謂的“執(zhí)行”是指虛擬機會觸發(fā)這個方法，但并不承諾會等待它運行結束，這樣做的原因是，如果一個對象在finalize()方法中執(zhí)行緩慢，或者發(fā)生了死循環(huán)（更極端的情況），將很可能會導致F-Queue隊列中其他的對象永久處于等待，甚至導致整個內(nèi)存回收系統(tǒng)奔潰。finalize()方法是對象逃脫死亡命運的最后一次機會，稍后GC將會對F-Queue中的對象進行第二次小規(guī)模的標記，如果對象要在finalize()中成功拯救自己——只要重新與引用鏈上的任何一個對象建立關聯(lián)即可，譬如把自己（this關鍵字）賦值給某個變量或者對象的成員變量，那在第二次標記時它將會被移除出“即將回收”的集合；如果對象這時候還沒有逃脫，那基本上它就真的被回收了。

3.2.5 回收方法區(qū)

很多人認為方法區(qū)（或者HotSpot虛擬機中的永久代）是沒有垃圾回收的，Java虛擬機規(guī)范中確實說過可以不要求虛擬機在方法區(qū)實現(xiàn)垃圾收集，而且在方法區(qū)中進行垃圾收集的“性價比”一般比較低：在堆中，尤其在新生代中，常規(guī)應用進行一次垃圾收集一般可以回收70% ~ 95%的空間，而在永久代的垃圾收集效率遠低于此。

永久代的垃圾收集主要分為兩部分內(nèi)容：廢棄常量和無用的類?；厥諒U棄常量與回收Java堆中的對象非常類似。以常量池中字面量的回收為例，假如一個字符串“abc”已經(jīng)進入了常量池中，但是當前系統(tǒng)沒有任何一個String對象是叫做“abc”，換句話說，就是沒有任何String對象引用常量池中的“abc”常量，也沒有其他地方引用這個字面量，如果這時發(fā)生內(nèi)存回收，而且必要的話，這個“abc”常量就會被系統(tǒng)清理出常量池。常量池中的其他類（接口）、方法、字段的符號引用也類似于此；

判定一個常量是否是“廢棄常量”比較簡單，而要判定一個類是否是“無用的類”的條件則相對苛刻許多。類需要同時，滿足下面3個條件才能算是“無用的類”：

該類所有的實例都已經(jīng)被回收，也就是Java堆中不存在該類的任何實例。

加載該類的ClassLoader已經(jīng)被回收。

該類對應的java.lang.Class對象沒有在任何地方被引用，無法在任何地方通過反射訪問該類的方法。

虛擬機可以對滿足上述3個條件的無用類進行回收，這里說的僅僅是“可以”，而并不是和對象一樣，不使用了就必然會回收。是否對類進行回收，HotSpot虛擬機提供了-Xnoclassgc參數(shù)進行控制，還可以使用-verbose:class 以及-XX：+TraceClassLoading、-XX：+TraceClassUnLoading查看類加載和卸載信息，其中-verbose：class和-XX：+TraceClassLoading可以在Product版的虛擬機中使用，-XX：+TraceClassUnLoading參數(shù)需要FastDebug版的虛擬機支持。

在大量使用反射、動態(tài)代理、CGLib等ByteCode框架、動態(tài)生成JSP以及OSGi這類頻繁定義ClassLoader的場景都需要虛擬機具備卸載的功能、以保證永久代不會溢出。

3.3 垃圾收集算法

以下介紹幾種算法的思想及其發(fā)展過程

3.3.1 標記--清除算法

最基礎的收集算法是“標記--清除”（Mark-Sweep）算法，如同它的名字一樣，算法分為“標記”和“清除”兩個階段：

階段一：標記出所有需要回收的對象

階段二：標記完成后，統(tǒng)一回收所有被標記的對象

之所以說它是最基礎的算法，是因為后續(xù)的收集算法都是基于這種思路并對其不足進行改進而得到的。它主要有兩個不足：

不足一：效率問題，標記和清除兩個過程的效率都不高

不足二：空間問題，標記清除后會產(chǎn)生大量的不連續(xù)的內(nèi)存碎片，空間碎片太多可能會導致以后在程序運行過程中需要分配較大對象時，無法找到足夠的連續(xù)內(nèi)存而不得不提前觸發(fā)另一次垃圾收集動作。

標記--清除算法的執(zhí)行過程如下圖：

3.3.2 復制算法

為了解決效率問題，一種稱為“復制”（Copying）的收集算法出現(xiàn)了，它將可用內(nèi)存按容量劃分為大小相等的兩塊，每次使用其中的一塊。當這一塊內(nèi)存用完了，就將還存活著的對象復制到另外一塊上面，然后把已經(jīng)使用過的內(nèi)存空間一次清除掉。

優(yōu)點：這樣使得每次都是對整個半?yún)^(qū)進行內(nèi)存回收，內(nèi)存分配時就不用考慮內(nèi)存碎片的復雜情況，只要移動堆頂指針，按順序分配內(nèi)存即可，實現(xiàn)簡單，運行高效。

缺點：這種算法將內(nèi)存縮小為原來的一般，代價太高。

復制算法執(zhí)行過程如下圖所示：

現(xiàn)在的商業(yè)虛擬機都采用這種收集算法來回收新生代，IBM公司的專門研究表明，新生代中的對象98%是“朝生夕死”的，所以并不需要按照1:1的比例來劃分內(nèi)存空間，而是將內(nèi)存分為一塊較大的Eden空間和兩塊較小的Survivor空間，每次使用Eden和其中一塊Survivor。當回收時，將Eden和Survivor中還存活著的對象一次性的復制到另一塊Survivor空間上，最后清理掉Eden和剛才用過的Survivor空間。HotSpot虛擬機默認Eden和Survivor的大小比例是8:1，也就是每次新生代中可用空間為整個新生代容量的90%（80%+10%），只有10%的內(nèi)存會被“浪費”。

當然，98%的對象可回收只是一般場景下的數(shù)據(jù)，我們沒法保證每次回收都只有不多于10%的對象存活，當Survivor空間不夠時，需要依賴其他內(nèi)存（這里指老年代）進行分配擔保（Handle Promotion）。

3.3.3 標記--整理算法

復制收集算法在對象存活率比較高時就要進行比較多的復制操作，效率將會變低。更關鍵的是，如果不想浪費50%的空間，就需要額外的空間進行分配擔保，以應對被使用的內(nèi)存中所有對象都是100%存活的極端情況，所以在老年代一般不能直接選用這種算法。

根據(jù)老年代的特點，有人提出了另外一種“標記--整理”（Mark-Compact）算法，標記過程仍然與“標記--清除”算法一樣，但后續(xù)步驟不是直接對可回收對象進行整理，而是讓所有存貨你的對象都向一端移動，然后直接清理掉端邊界以外的內(nèi)存。

“標記--整理”算法的示意圖如下：

3.3.4 分代收集算法

當前商業(yè)虛擬機的垃圾收緊都采用“分代收集”（Generational Collection）算法，這種算法并沒有什么新思想，只是根據(jù)對象存活周期的不同將內(nèi)存劃分為幾塊。一般是把Java堆分為新生代和老年代，這樣就可以根據(jù)各個年代的特點采用適當?shù)氖占惴?。在新生代中，每次垃圾收集時都發(fā)現(xiàn)有大批對象死去，只有少量存活，那就選用復制算法，只需要付出少量存活對象的復制成本就可以完成收集。而老年代中因為對象的存活率高，沒有額外空間對它進行分配擔保，就必須使用“標記--清理”或者“標記--整理”算法來進行回收。

3.4 HotSpot的算法實現(xiàn)

HotSpot上實現(xiàn)算法時，必須對算法的執(zhí)行效率有嚴格的考量，才能保證虛擬機高效執(zhí)行。

3.4.1 枚舉根節(jié)點

從可達性分析中從GC Roots節(jié)點找引用鏈這個操作為例，可作為GC Roots的節(jié)點主要是在全局性的引用（例如常量或者靜態(tài)屬性）與執(zhí)行上下文（例如棧幀中的本地變量表）中，現(xiàn)在很多應用僅僅方法區(qū)就有數(shù)百兆，如果要逐個檢索里面的引用，那么必然會消耗很多時間。

另外，可達性分析對執(zhí)行時間的敏感還體現(xiàn)在GC停頓上，因為這項分析工作必須在一個能確保一致性的快照中進行-----這里的“一致性”的意思是指在整個分析期間整個執(zhí)行系統(tǒng)看起來就像被凍結在某個時間點上，不可以出現(xiàn)分析過程中對象引用關系還在變化的情況，該點不滿足的話分析結果準確性就無法得到保證。這點導致GC進行時必須停頓所有的Java執(zhí)行線程（Sun將這件事稱為“Stop The World”）的其中一個重要原因，即使在號稱（幾乎）不會發(fā)生停頓的GMS收集器中，枚舉根節(jié)點時也是必須要停頓的。

由于目前主流的Java虛擬機使用的都是準確式GC，所以在執(zhí)行系統(tǒng)停頓下來以后，并不需要一個不漏地檢查完所有執(zhí)行上下文和全局的引用變量，虛擬機應當是有辦法直接得知哪些地方存著對象引用。在HotSpot實現(xiàn)中，是使用一組稱為OopMap的數(shù)據(jù)結構來達到這個目的的，在類加載完成的時候，HotSpot就把對象內(nèi)什么偏移量上是什么類型的數(shù)據(jù)算出來，在JIT編譯過程中，也會在特定的位置記錄下棧和寄存器中哪些位置是引用。這樣,GC在掃描時就可以直接得知這些信息了。

3.4.2 安全點

在 OopMap的協(xié)助下，HotSpot可以快速且準確地完成GC Roots枚舉，但是一個很現(xiàn)實的問題隨之而來：可能導致引用關系變化，或者說OopMap內(nèi)容變化的指令非常多，如果為每一條指令都生成對應的OopMap，那將會需要大量的額外空間，這樣GC的空間成本將會變得很高。

實際上,HotSpot也的確沒有為每條指令都生成OopMap，前面已經(jīng)提到，只是在“特定的位置”記錄了這些信息，這些位置稱為安全點（Safepoint），即程序執(zhí)行時并非在所有地方都停頓下來開始GC，只有在到達安全點時才能暫停。Safepoint的選定既不能太少以至于讓GC等待時間太長，也不能過于頻繁以致于過分增加運行時的負荷。所以安全點的選定基本上是以程序“是否具有讓程序長時間執(zhí)行的特征”為標準進行選定的----因為每條指令執(zhí)行的時間都非常短暫，程序不太可能因為指令流長度太長這個原因而過長時間運行，“長時間執(zhí)行”的最明顯特征就是指令序列復用，例如方法調(diào)用，循環(huán)跳轉，異常跳轉等，所以具有這些功能的指令才會產(chǎn)生Safepoint。

對于Safepoint，另一種需要考慮到的問題是如何在GC發(fā)生時讓所有線程（這里不包括執(zhí)行JNI調(diào)用的線程）都“跑”到最近的安全點上再停頓下來。這里有兩種方案可供選擇：搶先式中斷（Preemptive Suspension）和主動式中斷（Voluntary SusPension），其中搶斷式中斷不需要線程的執(zhí)行代碼主動配合，在GC發(fā)生時，首先把所有線程全部中斷，如果發(fā)現(xiàn)有線程在中斷的地方不在安全點上，就恢復線程，讓它“跑”到安全點上，現(xiàn)在幾乎沒有虛擬機采用搶先式中斷來暫停線程從而響應GC事件。

而主動式中斷的思想是當GC需要中斷線程的時候，不直接對線程操作，僅僅簡單地設置一個標志，各個線程執(zhí)行時主動去輪詢這個標志，發(fā)現(xiàn)中斷標志為真時就自己中斷掛起。輪詢標志的地方和安全點事重合的，另外再加上創(chuàng)建對象需要分配內(nèi)存的地方。

3.4.3 安全區(qū)域

使用Safepoint似乎完美地解決了如何進入GC的問題，但實際情況卻并不一定。Safepoint機制保證了程序執(zhí)行時，在不太長的時間內(nèi)就會遇到可進入GC的Safepoint。但是程序“不執(zhí)行”的時候呢？所謂的程序不執(zhí)行就是沒有分配CPU時間，典型的例子就是線程處于Sleep狀態(tài)或者Blocked狀態(tài)，這時候線程無法響應JVM的中斷請求，“走”到安全的地方去中斷掛起，JVM也顯然不太可能等待線程重新被分配CPU時間。對于這種情況，就需要安全區(qū)域（Safe Region）來解決。

安全區(qū)域是指一段代碼片段之中，引用關系不會發(fā)生變化。在這個區(qū)域中的任意地方開始GC都是安全的。我們把Safe Region看做是被拓展的SafePoint。

在線程執(zhí)行到Safe Region中的代碼時，首先標識自己已經(jīng)進入了Safe Region，那樣，當在這段時間里JVM發(fā)起GC時，就不用管便是自己為Safe Region狀態(tài)的線程了。在線程將要離開Safe Region時，它要檢查系統(tǒng)是否已經(jīng)完成了根節(jié)點枚舉（或者整個GC過程），如果完成了，那線程就繼續(xù)執(zhí)行，否則就必須等待直到收到可以安全離開Safe Region的信號為止。