摘要：程序計(jì)數(shù)器程序計(jì)數(shù)器是一塊較小的內(nèi)存空間，它的作用可以看做是當(dāng)前線(xiàn)程所執(zhí)行的字節(jié)碼的行號(hào)指示器。它的主要缺點(diǎn)有兩個(gè)一個(gè)是效率問(wèn)題，標(biāo)記和清除過(guò)程的效率都不

本段參考 http://www.importnew.com/2374...

類(lèi)加載指的是將類(lèi)的.class文件中的二進(jìn)制數(shù)據(jù)讀入到內(nèi)存中，將其放在運(yùn)行時(shí)數(shù)據(jù)區(qū)的方法區(qū)內(nèi)，然后在堆區(qū)創(chuàng)建一個(gè)java.lang.Class對(duì)象，用來(lái)封裝類(lèi)在方法區(qū)內(nèi)的數(shù)據(jù)結(jié)構(gòu)。類(lèi)的加載的最終產(chǎn)品是位于堆區(qū)中的Class對(duì)象，Class對(duì)象封裝了類(lèi)在方法區(qū)內(nèi)的數(shù)據(jù)結(jié)構(gòu)，并且向Java程序員提供了訪(fǎng)問(wèn)方法區(qū)內(nèi)的數(shù)據(jù)結(jié)構(gòu)的接口。

加載.class文件的方式

從本地系統(tǒng)中直接加載

通過(guò)網(wǎng)絡(luò)下載.class文件

從zip，jar等歸檔文件中加載.class文件

從專(zhuān)有數(shù)據(jù)庫(kù)中提取.class文件

將Java源文件動(dòng)態(tài)編譯為.class文件

(略)

其中，

父類(lèi)加載器并不是通過(guò)繼承關(guān)系來(lái)實(shí)現(xiàn)的，而是采用組合實(shí)現(xiàn)的；

bootstrap ClassLoader是用C++實(shí)現(xiàn)的;

對(duì)JVM來(lái)說(shuō)，類(lèi)加載器分為啟動(dòng)類(lèi)加載器bootstrap ClassLoader和其他加載器

對(duì)開(kāi)發(fā)者來(lái)說(shuō)，分為啟動(dòng)類(lèi)加載器、擴(kuò)展類(lèi)加載器、應(yīng)用程序類(lèi)加載器、自定義類(lèi)加載器

啟動(dòng)類(lèi)加載器：Bootstrap ClassLoader，負(fù)責(zé)加載存放在JDKjrelib(JDK代表JDK的安裝目錄，下同)下，或被-Xbootclasspath參數(shù)指定的路徑中的，并且能被虛擬機(jī)識(shí)別的類(lèi)庫(kù)（如rt.jar，所有的java.*開(kāi)頭的類(lèi)均被Bootstrap ClassLoader加載）。啟動(dòng)類(lèi)加載器是無(wú)法被Java程序直接引用的。

擴(kuò)展類(lèi)加載器：Extension ClassLoader，該加載器由sun.misc.Launcher$ExtClassLoader實(shí)現(xiàn)，它負(fù)責(zé)加載DKjrelibext目錄中，或者由java.ext.dirs系統(tǒng)變量指定的路徑中的所有類(lèi)庫(kù)（如javax.*開(kāi)頭的類(lèi)），開(kāi)發(fā)者可以直接使用擴(kuò)展類(lèi)加載器。

應(yīng)用程序類(lèi)加載器：Application ClassLoader，該類(lèi)加載器由sun.misc.Launcher$AppClassLoader來(lái)實(shí)現(xiàn)，它負(fù)責(zé)加載用戶(hù)類(lèi)路徑（ClassPath）所指定的類(lèi)，開(kāi)發(fā)者可以直接使用該類(lèi)加載器，如果應(yīng)用程序中沒(méi)有自定義過(guò)自己的類(lèi)加載器，一般情況下這個(gè)就是程序中默認(rèn)的類(lèi)加載器。

全盤(pán)負(fù)責(zé)，當(dāng)一個(gè)類(lèi)加載器負(fù)責(zé)加載某個(gè)Class時(shí)，該Class所依賴(lài)的和引用的其他Class也將由該類(lèi)加載器負(fù)責(zé)載入，除非顯示使用另外一個(gè)類(lèi)加載器來(lái)載入

父類(lèi)委托，先讓父類(lèi)加載器試圖加載該類(lèi)，只有在父類(lèi)加載器無(wú)法加載該類(lèi)時(shí)才嘗試從自己的類(lèi)路徑中加載該類(lèi)

緩存機(jī)制，緩存機(jī)制將會(huì)保證所有加載過(guò)的Class都會(huì)被緩存，當(dāng)程序中需要使用某個(gè)Class時(shí)，類(lèi)加載器先從緩存區(qū)尋找該Class，只有緩存區(qū)不存在，系統(tǒng)才會(huì)讀取該類(lèi)對(duì)應(yīng)的二進(jìn)制數(shù)據(jù)，并將其轉(zhuǎn)換成Class對(duì)象，存入緩存區(qū)。這就是為什么修改了Class后，必須重啟JVM，程序的修改才會(huì)生效。

類(lèi)加載有三種方式

命令行啟動(dòng)應(yīng)用時(shí)候由JVM初始化加載

通過(guò)Class.forName()方法動(dòng)態(tài)加載

通過(guò)ClassLoader.loadClass()方法動(dòng)態(tài)加載

雙親委派模型的工作流程是：如果一個(gè)類(lèi)加載器收到了類(lèi)加載的請(qǐng)求，它首先不會(huì)自己去嘗試加載這個(gè)類(lèi)，而是把請(qǐng)求委托給父加載器去完成，依次向上，因此，所有的類(lèi)加載請(qǐng)求最終都應(yīng)該被傳遞到頂層的啟動(dòng)類(lèi)加載器中，只有當(dāng)父加載器在它的搜索范圍中沒(méi)有找到所需的類(lèi)時(shí)，即無(wú)法完成該加載，子加載器才會(huì)嘗試自己去加載該類(lèi)。

工作流程：

當(dāng)AppClassLoader加載一個(gè)class時(shí)，它首先不會(huì)自己去嘗試加載這個(gè)類(lèi)，而是把類(lèi)加載請(qǐng)求委派給父類(lèi)加載器ExtClassLoader去完成。

當(dāng)ExtClassLoader加載一個(gè)class時(shí)，它首先也不會(huì)自己去嘗試加載這個(gè)類(lèi)，而是把類(lèi)加載請(qǐng)求委派給BootStrapClassLoader去完成。

如果BootStrapClassLoader加載失?。ɡ缭?JAVA_HOME/jre/lib里未查找到該class），會(huì)使用ExtClassLoader來(lái)嘗試加載；

若ExtClassLoader也加載失敗，則會(huì)使用AppClassLoader來(lái)加載，如果AppClassLoader也加載失敗，則會(huì)報(bào)出異常ClassNotFoundException。

本節(jié)參考 http://www.importnew.com/2374...

http://ifeve.com/under-the-ho...

JVM內(nèi)存結(jié)構(gòu)主要有三大塊：堆內(nèi)存、方法區(qū)和棧。堆內(nèi)存存放對(duì)象以及數(shù)組的數(shù)據(jù)，堆內(nèi)存是JVM中最大的一塊由年輕代和老年代組成，而年輕代內(nèi)存又被分成三部分，Eden空間、From Survivor空間、To Survivor空間,默認(rèn)情況下年輕代按照8:1:1的比例來(lái)分配。
方法區(qū)存儲(chǔ)類(lèi)信息、常量、靜態(tài)變量等數(shù)據(jù)，是線(xiàn)程共享的區(qū)域，為與Java堆區(qū)分，方法區(qū)還有一個(gè)別名Non-Heap(非堆)，方法區(qū)存放類(lèi)的信息(包括類(lèi)名、方法、字段)、靜態(tài)變量、編譯器編譯后的代碼。
棧又分為java虛擬機(jī)棧和本地方法棧主要用于方法的執(zhí)行。

對(duì)于大多數(shù)應(yīng)用來(lái)說(shuō)，Java堆（Java Heap）是Java虛擬機(jī)所管理的內(nèi)存中最大的一塊。Java堆是被所有線(xiàn)程共享的一塊內(nèi)存區(qū)域，在虛擬機(jī)啟動(dòng)時(shí)創(chuàng)建。此內(nèi)存區(qū)域的唯一目的就是存放對(duì)象實(shí)例，幾乎所有的對(duì)象實(shí)例都在這里分配內(nèi)存。
如果在堆中沒(méi)有內(nèi)存完成實(shí)例分配，并且堆也無(wú)法再擴(kuò)展時(shí)，將會(huì)拋出OutOfMemoryError異常。

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

程序計(jì)數(shù)器是一塊較小的內(nèi)存空間，它的作用可以看做是當(dāng)前線(xiàn)程所執(zhí)行的字節(jié)碼的行號(hào)指示器。在虛擬機(jī)的概念模型里（僅是概念模型，各種虛擬機(jī)可能會(huì)通過(guò)一些更高效的方式去實(shí)現(xiàn)），字節(jié)碼解釋器工作時(shí)就是通過(guò)改變這個(gè)計(jì)數(shù)器的值來(lái)選取下一條需要執(zhí)行的字節(jié)碼指令，分支、循環(huán)、跳轉(zhuǎn)、異常處理、線(xiàn)程恢復(fù)等基礎(chǔ)功能都需要依賴(lài)這個(gè)計(jì)數(shù)器來(lái)完成。
由于Java虛擬機(jī)的多線(xiàn)程是通過(guò)線(xiàn)程輪流切換并分配處理器執(zhí)行時(shí)間的方式來(lái)實(shí)現(xiàn)的，在任何一個(gè)確定的時(shí)刻，一個(gè)處理器（對(duì)于多核處理器來(lái)說(shuō)是一個(gè)內(nèi)核）只會(huì)執(zhí)行一條線(xiàn)程中的指令。因此，為了線(xiàn)程切換后能恢復(fù)到正確的執(zhí)行位置，每條線(xiàn)程都需要有一個(gè)獨(dú)立的程序計(jì)數(shù)器，各條線(xiàn)程之間的計(jì)數(shù)器互不影響，獨(dú)立存儲(chǔ)，我們稱(chēng)這類(lèi)內(nèi)存區(qū)域?yàn)椤熬€(xiàn)程私有”的內(nèi)存。
如果線(xiàn)程正在執(zhí)行的是一個(gè)Java方法，這個(gè)計(jì)數(shù)器記錄的是正在執(zhí)行的虛擬機(jī)字節(jié)碼指令的地址；如果正在執(zhí)行的是Natvie方法，這個(gè)計(jì)數(shù)器值則為空（Undefined）。
此內(nèi)存區(qū)域是唯一一個(gè)在Java虛擬機(jī)規(guī)范中沒(méi)有規(guī)定任何OutOfMemoryError情況的區(qū)域。

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

局部變量表存放了編譯期可知的各種基本數(shù)據(jù)類(lèi)型（boolean、byte、char、short、int、float、long、double）、對(duì)象引用（reference類(lèi)型，它不等同于對(duì)象本身，根據(jù)不同的虛擬機(jī)實(shí)現(xiàn)，它可能是一個(gè)指向?qū)ο笃鹗嫉刂返囊弥羔?，也可能指向一個(gè)代表對(duì)象的句柄或者其他與此對(duì)象相關(guān)的位置）和returnAddress類(lèi)型（指向了一條字節(jié)碼指令的地址）。

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

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

本地方法棧（Native Method Stacks）與虛擬機(jī)棧所發(fā)揮的作用是非常相似的，其區(qū)別不過(guò)是虛擬機(jī)棧為虛擬機(jī)執(zhí)行Java方法（也就是字節(jié)碼）服務(wù)，而本地方法棧則是為虛擬機(jī)使用到的Native方法服務(wù)。虛擬機(jī)規(guī)范中對(duì)本地方法棧中的方法使用的語(yǔ)言、使用方式與數(shù)據(jù)結(jié)構(gòu)并沒(méi)有強(qiáng)制規(guī)定，因此具體的虛擬機(jī)可以自由實(shí)現(xiàn)它。甚至有的虛擬機(jī)（譬如Sun HotSpot虛擬機(jī)）直接就把本地方法棧和虛擬機(jī)棧合二為一。與虛擬機(jī)棧一樣，本地方法棧區(qū)域也會(huì)拋出StackOverflowError和OutOfMemoryError異常。

本節(jié)參考 https://my.oschina.net/hosee/...

判斷對(duì)象是否存活一般有兩種方式：

引用計(jì)數(shù)：每個(gè)對(duì)象有一個(gè)引用計(jì)數(shù)屬性，新增一個(gè)引用時(shí)計(jì)數(shù)加1，引用釋放時(shí)計(jì)數(shù)減1，計(jì)數(shù)為0時(shí)可以回收。此方法簡(jiǎn)單，無(wú)法解決對(duì)象相互循環(huán)引用的問(wèn)題。

可達(dá)性分析（Reachability Analysis）：從GC Roots開(kāi)始向下搜索，搜索所走過(guò)的路徑稱(chēng)為引用鏈。當(dāng)一個(gè)對(duì)象到GC Roots沒(méi)有任何引用鏈相連時(shí)，則證明此對(duì)象是不可用的。不可達(dá)對(duì)象。
其中，在Java語(yǔ)言中，GC Roots包括：

虛擬機(jī)棧中引用的對(duì)象。

方法區(qū)中類(lèi)靜態(tài)屬性實(shí)體引用的對(duì)象。

方法區(qū)中常量引用的對(duì)象。

本地方法棧中JNI引用的對(duì)象。

“標(biāo)記-清除”（Mark-Sweep）算法，如它的名字一樣，算法分為“標(biāo)記”和“清除”兩個(gè)階段：首先標(biāo)記出所有需要回收的對(duì)象，在標(biāo)記完成后統(tǒng)一回收掉所有被標(biāo)記的對(duì)象。之所以說(shuō)它是最基礎(chǔ)的收集算法，是因?yàn)楹罄m(xù)的收集算法都是基于這種思路并對(duì)其缺點(diǎn)進(jìn)行改進(jìn)而得到的。
它的主要缺點(diǎn)有兩個(gè)：一個(gè)是效率問(wèn)題，標(biāo)記和清除過(guò)程的效率都不高；另外一個(gè)是空間問(wèn)題，標(biāo)記清除之后會(huì)產(chǎn)生大量不連續(xù)的內(nèi)存碎片，空間碎片太多可能會(huì)導(dǎo)致，當(dāng)程序在以后的運(yùn)行過(guò)程中需要分配較大對(duì)象時(shí)無(wú)法找到足夠的連續(xù)內(nèi)存而不得不提前觸發(fā)另一次垃圾收集動(dòng)作。

“復(fù)制”（Copying）的收集算法，它將可用內(nèi)存按容量劃分為大小相等的兩塊，每次只使用其中的一塊。當(dāng)這一塊的內(nèi)存用完了，就將還存活著的對(duì)象復(fù)制到另外一塊上面，然后再把已使用過(guò)的內(nèi)存空間一次清理掉。
這樣使得每次都是對(duì)其中的一塊進(jìn)行內(nèi)存回收，內(nèi)存分配時(shí)也就不用考慮內(nèi)存碎片等復(fù)雜情況，只要移動(dòng)堆頂指針，按順序分配內(nèi)存即可，實(shí)現(xiàn)簡(jiǎn)單，運(yùn)行高效。只是這種算法的代價(jià)是將內(nèi)存縮小為原來(lái)的一半，持續(xù)復(fù)制長(zhǎng)生存期的對(duì)象則導(dǎo)致效率降低。

復(fù)制收集算法在對(duì)象存活率較高時(shí)就要執(zhí)行較多的復(fù)制操作，效率將會(huì)變低。更關(guān)鍵的是，如果不想浪費(fèi)50%的空間，就需要有額外的空間進(jìn)行分配擔(dān)保，以應(yīng)對(duì)被使用的內(nèi)存中所有對(duì)象都100%存活的極端情況，所以在老年代一般不能直接選用這種算法。
根據(jù)老年代的特點(diǎn)，有人提出了另外一種“標(biāo)記-整理”（Mark-Compact）算法，標(biāo)記過(guò)程仍然與“標(biāo)記-清除”算法一樣，但后續(xù)步驟不是直接對(duì)可回收對(duì)象進(jìn)行清理，而是讓所有存活的對(duì)象都向一端移動(dòng)，然后直接清理掉端邊界以外的內(nèi)存

GC分代的基本假設(shè)：絕大部分對(duì)象的生命周期都非常短暫，存活時(shí)間短。
“分代收集”（Generational Collection）算法，把Java堆分為新生代和老年代，這樣就可以根據(jù)各個(gè)年代的特點(diǎn)采用最適當(dāng)?shù)氖占惴?。在新生代中，每次垃圾收集時(shí)都發(fā)現(xiàn)有大批對(duì)象死去，只有少量存活，那就選用復(fù)制算法，只需要付出少量存活對(duì)象的復(fù)制成本就可以完成收集。而老年代中因?yàn)閷?duì)象存活率高、沒(méi)有額外空間對(duì)它進(jìn)行分配擔(dān)保，就必須使用“標(biāo)記-清理”或“標(biāo)記-整理”算法來(lái)進(jìn)行回收。

（略）