3. Native Method Stack(本地方法棧)

與Java Stack作用類(lèi)似, 區(qū)別是Java Stack為執(zhí)行Java方法服務(wù), 而本地方法棧則為Native方法服務(wù), 如果一個(gè)VM實(shí)現(xiàn)使用C-linkage模型來(lái)支持Native調(diào)用, 那么該棧將會(huì)是一個(gè)#(詳見(jiàn): JVM學(xué)習(xí)筆記-本地方法棧(Native Method Stacks)), 但HotSpot VM直接就把本地方法棧和虛擬機(jī)棧合二為一.

二. 線程共享區(qū)域

隨虛擬機(jī)的啟動(dòng)/關(guān)閉而創(chuàng)建/銷(xiāo)毀.

1. Heap(Java堆)

幾乎所有對(duì)象實(shí)例和數(shù)組都要在堆上分配(棧上分配、標(biāo)量替換除外), 因此是VM管理的最大一塊內(nèi)存, 也是垃圾收集器的主要活動(dòng)區(qū)域. 由于現(xiàn)代VM采用分代收集算法, 因此Java堆從GC的角度還可以細(xì)分為: 新生代(Eden區(qū)、From Survivor區(qū)和To Survivor區(qū))和老年代; 而從內(nèi)存分配的角度來(lái)看, 線程共享的Java堆還還可以劃分出多個(gè)線程私有的分配緩沖區(qū)(TLAB). 而進(jìn)一步劃分的目的是為了更好地回收內(nèi)存和更快地分配內(nèi)存.

2. Method Area(方法區(qū))

即我們常說(shuō)的永久代(Permanent Generation), 用于存儲(chǔ)被JVM加載的類(lèi)信息、常量、靜態(tài)變量、即時(shí)編譯器編譯后的代碼等數(shù)據(jù). HotSpot VM把GC分代收集擴(kuò)展至方法區(qū), 即使用Java堆的永久代來(lái)實(shí)現(xiàn)方法區(qū), 這樣HotSpot的垃圾收集器就可以像管理Java堆一樣管理這部分內(nèi)存, 而不必為方法區(qū)開(kāi)發(fā)專(zhuān)門(mén)的內(nèi)存管理器(永久帶的內(nèi)存回收的主要目標(biāo)是針對(duì)常量池的回收和類(lèi)型的卸載, 因此收益一般很小)
運(yùn)行時(shí)常量池
方法區(qū)的一部分. Class文件中除了有類(lèi)的版本、字段、方法、接口等描述信息外,還有一項(xiàng)常量池(Constant Pool Table)用于存放編譯期生成的各種字面量和符號(hào)引用, 這部分內(nèi)容會(huì)存放到方法區(qū)的運(yùn)行時(shí)常量池中(如前面從test方法中讀到的signature信息). 但Java語(yǔ)言并不要求常量一定只能在編譯期產(chǎn)生, 即并非預(yù)置入Class文件中常量池的內(nèi)容才能進(jìn)入方法區(qū)運(yùn)行時(shí)常量池, 運(yùn)行期間也可能將新的常量放入池中, 如String的intern()方法.

三. 直接內(nèi)存

直接內(nèi)存并不是JVM運(yùn)行時(shí)數(shù)據(jù)區(qū)的一部分, 但也會(huì)被頻繁的使用: 在JDK 1.4引入的NIO提供了基于Channel與Buffer的IO方式, 它可以使用Native函數(shù)庫(kù)直接分配堆外內(nèi)存, 然后使用DirectByteBuffer對(duì)象作為這塊內(nèi)存的引用進(jìn)行操作(詳見(jiàn): Java I/O 擴(kuò)展), 這樣就避免了在Java堆和Native堆中來(lái)回復(fù)制數(shù)據(jù), 因此在一些場(chǎng)景中可以顯著提高性能.
顯然, 本機(jī)直接內(nèi)存的分配不會(huì)受到Java堆大小的限制(即不會(huì)遵守-Xms、-Xmx等設(shè)置), 但既然是內(nèi)存, 則肯定還是會(huì)受到本機(jī)總內(nèi)存大小及處理器尋址空間的限制, 因此動(dòng)態(tài)擴(kuò)展時(shí)也會(huì)出現(xiàn)OutOfMemoryError異常.

GC算法種類(lèi)

1、引用計(jì)數(shù)算法：給對(duì)象中添加一個(gè)引用計(jì)數(shù)器，每當(dāng)有一個(gè)地方引用他時(shí)，計(jì)數(shù)器值就加1；當(dāng)引用失效時(shí)，計(jì)數(shù)器值就減1；任何時(shí)刻計(jì)數(shù)器為0的對(duì)象就是不可能再被使用的。
缺點(diǎn)：引用和去引用伴隨著加法和減法，影響性能，而且難以處理循環(huán)引用，java中沒(méi)有使用。
2、可達(dá)性分析算法：通過(guò)一系列名為"GC Roots"的對(duì)象作為起始點(diǎn)，從這些節(jié)點(diǎn)開(kāi)始向下搜索，搜索所走過(guò)的路徑稱(chēng)為引用鏈(Reference Chain)，當(dāng)一個(gè)對(duì)象到GC Roots沒(méi)有任何引用鏈相連時(shí)，則證明此對(duì)象是不可用的。

收集算法

1、標(biāo)記-清除算法
對(duì)待回收的對(duì)象進(jìn)行標(biāo)記。
算法缺點(diǎn)：效率問(wèn)題，標(biāo)記和清除過(guò)程效率都很低；空間問(wèn)題，收集之后會(huì)產(chǎn)生大量的內(nèi)存碎片，不利于大對(duì)象的分配。
2、復(fù)制算法
復(fù)制算法將可用內(nèi)存劃分成大小相等的兩塊A和B，每次只使用其中一塊，當(dāng)A的內(nèi)存用完了，就把存活的對(duì)象復(fù)制到B，并清空A的內(nèi)存，不僅提高了標(biāo)記的效率，因?yàn)橹恍枰獦?biāo)記存活的對(duì)象，同時(shí)也避免了內(nèi)存碎片的問(wèn)題，代價(jià)是可用內(nèi)存縮小為原來(lái)的一半。
3、標(biāo)記-整理算法
在老年代中，對(duì)象存活率較高，復(fù)制算法的效率很低。在標(biāo)記-整理算法中，標(biāo)記出所有存活的對(duì)象，并移動(dòng)到一端，然后直接清理邊界以外的內(nèi)存。

垃圾收集器

上圖展示了7種不同分代的收集器，如果兩兩之間存在連線，說(shuō)明可以組合使用。
1、Serial收集器（串行GC）
Serial 是一個(gè)采用單個(gè)線程并基于復(fù)制算法工作在新生代的收集器，進(jìn)行垃圾收集時(shí)，必須暫停其他所有的工作線程。對(duì)于單CPU環(huán)境來(lái)說(shuō)，Serial由于沒(méi)有線程交互的開(kāi)銷(xiāo)，可以很高效的進(jìn)行垃圾收集動(dòng)作，是Client模式下新生代默認(rèn)的收集器。
2、ParNew收集器（并行GC）
ParNew其實(shí)是serial的多線程版本，除了使用多條線程進(jìn)行垃圾收集之外，其余行為與Serial一樣。
3、Parallel Scavenge收集器（并行回收GC）
Parallel Scavenge是一個(gè)采用多線程基于復(fù)制算法并工作在新生代的收集器，其關(guān)注點(diǎn)在于達(dá)到一個(gè)可控的吞吐量，經(jīng)常被稱(chēng)為“吞吐量?jī)?yōu)先”的收集器。
吞吐量 = 用戶代碼運(yùn)行時(shí)間 /（用戶代碼運(yùn)行時(shí)間 + 垃圾收集時(shí)間）
Parallel Scavenge提供了兩個(gè)參數(shù)用于精確控制吞吐量：
1、-XX：MaxGCPauseMillis 設(shè)置垃圾收集的最大停頓時(shí)間
2、-XX：GCTimeRatio 設(shè)置吞吐量大小
4、Serial Old收集器（串行GC）
Serial Old 是一個(gè)采用單線程基于標(biāo)記-整理算法并工作在老年代的收集器，是Client模式下老年代默認(rèn)的收集器。
5、Parallel Old收集器（并行GC）
Parallel Old是一個(gè)采用多線程基于標(biāo)記-整理算法并工作在老年代的收集器。在注重吞吐量以及CPU資源敏感的場(chǎng)合，可以優(yōu)先考慮Parallel Scavenge和Parallel Old的收集器組合。
6、CMS收集器（并發(fā)GC）
CMS(Concurrent Mark Sweep)是一種以獲取最短回收停頓時(shí)間為目標(biāo)的收集器，工作在老年代，基于“標(biāo)記-清除”算法實(shí)現(xiàn)，整個(gè)過(guò)程分為以下4步：
1、初始標(biāo)記：這個(gè)過(guò)程只是標(biāo)記以下GC Roots能夠直接關(guān)聯(lián)的對(duì)象，但是仍然會(huì)Stop The World；
2、并發(fā)標(biāo)記：進(jìn)行GC Roots Tracing的過(guò)程，可以和用戶線程一起工作。
3、重新標(biāo)記：用于修正并發(fā)標(biāo)記期間由于用戶程序繼續(xù)運(yùn)行而導(dǎo)致標(biāo)記產(chǎn)生變動(dòng)的那部分記錄，這個(gè)過(guò)程會(huì)暫停所有線程，但其停頓時(shí)間遠(yuǎn)比并發(fā)標(biāo)記的時(shí)間短；
4、并發(fā)清理：可以和用戶線程一起工作。
CMS收集器的缺點(diǎn)：
1、對(duì)CPU資源比較敏感，在并發(fā)階段，雖然不會(huì)導(dǎo)致用戶線程停頓，但是會(huì)占用一部分線程資源，降低系統(tǒng)的總吞吐量。
2、無(wú)法處理浮動(dòng)垃圾，在并發(fā)清理階段，用戶線程的運(yùn)行依然會(huì)產(chǎn)生新的垃圾對(duì)象，這部分垃圾只能在下一次GC時(shí)收集。
3、CMS是基于標(biāo)記-清除算法實(shí)現(xiàn)的，意味著收集結(jié)束后會(huì)造成大量的內(nèi)存碎片，可能導(dǎo)致出現(xiàn)老年代剩余空間很大，卻無(wú)法找到足夠大的連續(xù)空間分配當(dāng)前對(duì)象，不得不提前觸發(fā)一次Full GC。
JDK1.5實(shí)現(xiàn)中，當(dāng)老年代空間使用率達(dá)到68%時(shí)，就會(huì)觸發(fā)CMS收集器，如果應(yīng)用中老年代增長(zhǎng)不是太快，可以通過(guò)-XX:CMSInitiatingOccupancyFraction參數(shù)提高觸發(fā)百分比，從而降低內(nèi)存回收次數(shù)提高系統(tǒng)性能。
JDK1.6實(shí)現(xiàn)中，觸發(fā)CMS收集器的閾值已經(jīng)提升到92%，要是CMS運(yùn)行期間預(yù)留的內(nèi)存無(wú)法滿足用戶線程需要，會(huì)出現(xiàn)一次"Concurrent Mode Failure"失敗，這是虛擬機(jī)會(huì)啟動(dòng)Serial Old收集器對(duì)老年代進(jìn)行垃圾收集，當(dāng)然，這樣應(yīng)用的停頓時(shí)間就更長(zhǎng)了，所以這個(gè)閾值也不能設(shè)置的太高，如果導(dǎo)致了"Concurrent Mode Failure"失敗，反而會(huì)降低性能，至于如何設(shè)置這個(gè)閾值，還得長(zhǎng)時(shí)間的對(duì)老年代空間的使用情況進(jìn)行監(jiān)控。
7、G1收集器
G1（Garbage First）是JDK1.7提供的一個(gè)工作在新生代和老年代的收集器，基于“標(biāo)記-整理”算法實(shí)現(xiàn)，在收集結(jié)束后可以避免內(nèi)存碎片問(wèn)題。
G1優(yōu)點(diǎn)：
1、并行與并發(fā)：充分利用多CPU來(lái)縮短Stop The World的停頓時(shí)間；
2、分代收集：不需要其他收集配合就可以管理整個(gè)Java堆，采用不同的方式處理新建的對(duì)象、已經(jīng)存活一段時(shí)間和經(jīng)歷過(guò)多次GC的對(duì)象獲取更好的收集效果;
3、空間整合：與CMS的"標(biāo)記-清除"算法不同，G1在運(yùn)行期間不會(huì)產(chǎn)生內(nèi)存空間碎片，有利于應(yīng)用的長(zhǎng)時(shí)間運(yùn)行，且分配大對(duì)象時(shí)，不會(huì)導(dǎo)致由于無(wú)法申請(qǐng)到足夠大的連續(xù)內(nèi)存而提前觸發(fā)一次Full GC;
4、停頓預(yù)測(cè)：G1中可以建立可預(yù)測(cè)的停頓時(shí)間模型，能讓使用者明確指定在M毫秒的時(shí)間片段內(nèi)，消耗在垃圾收集上的時(shí)間不得超過(guò)N毫秒。
使用G1收集器時(shí)，Java堆的內(nèi)存布局與其他收集器有很大區(qū)別，整個(gè)Java堆會(huì)被劃分為多個(gè)大小相等的獨(dú)立區(qū)域Region，新生代和老年代不再是物理隔離了，都是一部分Region（不需要連續(xù)）的集合。G1會(huì)跟蹤各個(gè)Region的垃圾收集情況（回收空間大小和回收消耗的時(shí)間），維護(hù)一個(gè)優(yōu)先列表，根據(jù)允許的收集時(shí)間，優(yōu)先回收價(jià)值最大的Region，避免在整個(gè)Java堆上進(jìn)行全區(qū)域的垃圾回收，確保了G1收集器可以在有限的時(shí)間內(nèi)盡可能收集更多的垃圾。
不過(guò)問(wèn)題來(lái)了：使用G1收集器，一個(gè)對(duì)象分配在某個(gè)Region中，可以和Java堆上任意的對(duì)象有引用關(guān)系，那么如何判定一個(gè)對(duì)象是否存活，是否需要掃描整個(gè)Java堆？其實(shí)這個(gè)問(wèn)題在之前收集器中也存在，如果回收新生代的對(duì)象時(shí)，不得不同時(shí)掃描老年代的話，會(huì)大大降低Minor GC的效率。
針對(duì)這種情況，虛擬機(jī)提供了一個(gè)解決方案：G1收集器中Region之間的對(duì)象引用關(guān)系和其他收集器中新生代與老年代之間的對(duì)象引用關(guān)系被保存在Remenbered Set數(shù)據(jù)結(jié)構(gòu)中，用來(lái)避免全堆掃描。G1中每個(gè)Region都有一個(gè)對(duì)應(yīng)的Remenbered Set，當(dāng)虛擬機(jī)發(fā)現(xiàn)程序?qū)eference類(lèi)型的數(shù)據(jù)進(jìn)行寫(xiě)操作時(shí)，會(huì)產(chǎn)生一個(gè)Write Barrier暫時(shí)中斷寫(xiě)操作，檢查Reference引用的對(duì)象是否處于相同的Region中，如果不是，則通過(guò)CardTable把相關(guān)引用信息記錄到被引用對(duì)象所屬Region的Remenbered Set中。

JVM參數(shù)

JVM參數(shù)設(shè)置

參考：Java GC的那些事（2）