1.介紹下Java內存區(qū)域（運行時數(shù)據(jù)區(qū)）。

Java虛擬機在執(zhí)行Java程序的過程中會把它所管理的內存劃分為以下6個運行時數(shù)據(jù)區(qū)域。

程序計數(shù)器（Program Counter Register）

一塊較小的內存空間，可以看作當前線程所執(zhí)行的字節(jié)碼的行號指示器。如果線程正在執(zhí)行的是一個Java方法，這個計數(shù)器記錄的是正在執(zhí)行的虛擬機字節(jié)碼指令的地址；如果正在執(zhí)行的是Native方法，這個計數(shù)器值則為空。

Java虛擬機棧（Java Virtual Machine Stacks）

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

本地方法棧（Native Method Stack）

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

Java堆（Java Heap）

對大多數(shù)應用來說，Java堆是Java虛擬機所管理的內存中最大的一塊。Java堆是被所有線程共享的一塊內存區(qū)域，在虛擬機啟動時創(chuàng)建。此內存區(qū)域的唯一目的就是存放對象實例，幾乎所有的對象實例都在這里分配內存。

方法區(qū)（Method Area）

與Java堆一樣，是各個線程共享的內存區(qū)域，它用于存儲已被虛擬機加載的類信息、常量、靜態(tài)變量、即時編譯器編譯后的代碼等數(shù)據(jù)。方法區(qū)是JVM規(guī)范中定義的一個概念，具體放在哪里，不同的實現(xiàn)可以放在不同的地方。

運行時常量池（Runtime Constant Pool）

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

2.怎么判定對象已經“死去”？

常見的判定方法有兩種：引用計數(shù)法和可達性分析算法，HotSpot中采用的是可達性分析算法。

引用計數(shù)法

給對象中添加一個引用計數(shù)器，每當有一個地方引用它時，計數(shù)器值就加1；當引用失效時，計數(shù)器值就減1；任何時刻計數(shù)器為0的對象就是不可能再被使用的。

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

可達性分析算法

這個算法的基本思路就是通過一系列的稱為“GC Roots”的對象作為起始點，從這些節(jié)點開始向下搜索，搜索所走過的路徑稱為引用鏈，當一個對象到GC Roots沒有任何引用鏈相連（用圖論的話來說，就是從GC Roots到這個對象不可達）時，則證明此對象是不可用的。如下圖所示，對象object 5、object 6、object 7雖然互相有關聯(lián)，但是它們到GC Roots是不可達的，所以它們將會被判定為是可回收的對象。

3.介紹下四種引用（強引用、軟引用、弱引用、虛引用）？

強引用：在程序代碼之中普遍存在的，類似“Object obj=new Object()”這類的引用，只要強引用還存在，垃圾收集器永遠不會回收掉被引用的對象。

軟引用：用來描述一些還有用但并非必需的對象，使用SoftReference類來實現(xiàn)軟引用，在系統(tǒng)將要發(fā)生內存溢出異常之前，將會把這些對象列進回收范圍之中進行第二次回收。

弱引用：用來描述非必需對象的，使用WeakReference類來實現(xiàn)弱引用，被弱引用關聯(lián)的對象只能生存到下一次垃圾收集發(fā)生之前。

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

4.垃圾收集有哪些算法，各自的特點？ 標記 - 清除算法

首先標記出所有需要回收的對象，在標記完成后統(tǒng)一回收所有被標記的對象。它的主要不足有兩個：一個是效率問題，標記和清除兩個過程的效率都不高；另一個是空間問題，標記清除之后會產生大量不連續(xù)的內存碎片，空間碎片太多可能會導致以后在程序運行過程中需要分配較大對象時，無法找到足夠的連續(xù)內存而不得不提前觸發(fā)另一次垃圾收集動作。

復制算法

為了解決效率問題，一種稱為“復制”（Copying）的收集算法出現(xiàn)了，它將可用內存按容量劃分為大小相等的兩塊，每次只使用其中的一塊。當這一塊的內存用完了，就將還存活著的對象復制到另外一塊上面，然后再把已使用過的內存空間一次清理掉。這樣使得每次都是對整個半區(qū)進行內存回收，內存分配時也就不用考慮內存碎片等復雜情況，只要移動堆頂指針，按順序分配內存即可，實現(xiàn)簡單，運行高效。只是這種算法的代價是將內存縮小為了原來的一半，未免太高了一點。

標記 - 整理算法

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

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

5.HotSpot為什么要分為新生代和老年代？

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

其中新生代又分為1個Eden區(qū)和2個Survivor區(qū)，通常稱為From Survivor和To Survivor區(qū)。

6.新生代中Eden區(qū)和Survivor區(qū)的默認比例？

在HotSpot虛擬機中，Eden區(qū)和Survivor區(qū)的默認比例為8:1:1，即-XX:SurvivorRatio=8，其中Survivor分為From Survivor和ToSurvivor，因此Eden此時占新生代空間的80%。

7.HotSpot GC的分類？

針對HotSpot VM的實現(xiàn)，它里面的GC其實準確分類只有兩大種：

1. Partial GC：并不收集整個GC堆的模式，具體如下：
   1. Young GC/Minor GC：只收集新生代的GC。
   2. Old GC：只收集老年代的GC。只有CMS的concurrent collection是這個模式。
   3. Mixed GC：收集整個新生代以及部分老年代的GC，只有G1有這個模式。
2. Full GC/Major GC：收集整個GC堆的模式，包括新生代、老年代、永久代（如果存在的話）等所有部分的模式。

8.HotSpot GC的觸發(fā)條件？

這里只說常見的Young GC和Full GC。

Young GC：當新生代中的Eden區(qū)沒有足夠空間進行分配時會觸發(fā)Young GC。

Full GC：

1. 當準備要觸發(fā)一次Young GC時，如果發(fā)現(xiàn)統(tǒng)計數(shù)據(jù)說之前Young GC的平均晉升大小比目前老年代剩余的空間大，則不會觸發(fā)Young GC而是轉為觸發(fā)Full GC。（通常情況）
2. 如果有永久代的話，在永久代需要分配空間但已經沒有足夠空間時，也要觸發(fā)一次Full GC。
3. System.gc()默認也是觸發(fā)Full GC。
4. heap dump帶GC默認也是觸發(fā)Full GC。
5. CMS GC時出現(xiàn)Concurrent Mode Failure會導致一次Full GC的產生。

9.Full GC后老年代的空間反而變??？

HotSpot的Full GC實現(xiàn)中，默認新生代里所有活的對象都要晉升到老年代，實在晉升不了才會留在新生代。假如做Full GC的時候，老年代里的對象幾乎沒有死掉的，而新生代又要晉升活對象上來，那么Full GC結束后老年代的使用量自然就上升了。

10.什么情況下新生代對象會晉升到老年代？

1. 如果新生代的垃圾收集器為Serial和ParNew，并且設置了-XX:PretenureSizeThreshold參數(shù)，當對象大于這個參數(shù)值時，會被認為是大對象，直接進入老年代。
2. Young GC后，如果對象太大無法進入Survivor區(qū)，則會通過分配擔保機制進入老年代。
3. 對象每在Survivor區(qū)中“熬過”一次Young GC，年齡就增加1歲，當它的年齡增加到一定程度（默認為15歲，可以通過-XX:MaxTenuringThreshold設置），就將會被晉升到老年代中。
4. 如果在Survivor區(qū)中相同年齡所有對象大小的總和大于Survivor空間的一半，年齡大于或等于該年齡的對象就可以直接進入老年代，無須等到MaxTenuringThreshold中要求的年齡。

11.介紹下垃圾收集機制（在什么時候，對什么，做了什么）？ 在什么時候？

在觸發(fā)GC的時候，具體如下，這里只說常見的Young GC和Full GC。

觸發(fā)Young GC：當新生代中的Eden區(qū)沒有足夠空間進行分配時會觸發(fā)Young GC。

觸發(fā)Full GC：

1. 當準備要觸發(fā)一次Young GC時，如果發(fā)現(xiàn)統(tǒng)計數(shù)據(jù)說之前Young GC的平均晉升大小比目前老年代剩余的空間大，則不會觸發(fā)Young GC而是轉為觸發(fā)Full GC。（通常情況）
2. 如果有永久代的話，在永久代需要分配空間但已經沒有足夠空間時，也要觸發(fā)一次Full GC。
3. System.gc()默認也是觸發(fā)Full GC。
4. heap dump帶GC默認也是觸發(fā)Full GC。
5. CMS GC時出現(xiàn)Concurrent Mode Failure會導致一次Full GC的產生。

對什么？

對那些JVM認為已經“死掉”的對象。即從GC Root開始搜索，搜索不到的，并且經過一次篩選標記沒有復活的對象。

做了什么？

對這些JVM認為已經“死掉”的對象進行垃圾收集，新生代使用復制算法，老年代使用標記-清除和標記-整理算法。

12.GC Root有哪些?

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

• 虛擬機棧（棧幀中的本地變量表）中引用的對象。
• 方法區(qū)中類靜態(tài)屬性引用的對象。
• 方法區(qū)中常量引用的對象。
• 本地方法棧中JNI（即一般說的Native方法）引用的對象。

13.發(fā)生Young GC的時候需要掃描老年代的對象嗎？

在分代收集中，新生代的規(guī)模一般都比老年代要小許多，新生代的收集也比老年代要頻繁許多，如果回收新生代時也不得不同時掃描老年代的話，那么Young GC的效率可能下降不少。顯然是不可能區(qū)掃描老年代的，那么是通過什么辦法來解決這個問題了？

在大多垃圾收集器中（G1有不同的地方），通過CardTable來維護老年代對年輕代的引用，CardTable可以說是Remembered Set（RS）的一種特殊實現(xiàn)，是Card的集合。Card是一塊2的冪字節(jié)大小的內存區(qū)域，例如HotSpot用512字節(jié)，里面可能包含多個對象。CardTable要記錄的是從它覆蓋的范圍出發(fā)指向別的范圍的指針。以分代式GC的CardTable為例，要記錄老年代指向年輕代的跨代指針，被標記的Card是老年代范圍內的。當進行年輕代的垃圾收集時，只需要掃描年輕代和老年代的CardTable即可保證不對全堆掃描也不會有遺漏。CardTable通常為字節(jié)數(shù)組，由Card的索引（即數(shù)組下標）來標識每個分區(qū)的空間地址。

14.垃圾收集器有哪些？

目前HotSpot中有7種作用于不同分代的收集器，如下圖所示，如果兩個收集器之間存在連線，就說明它們可以搭配使用。

15.介紹CMS垃圾收集器的特點？

CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時間為目標的收集器。目前很大一部分的Java應用集中在互聯(lián)網站或者B/S系統(tǒng)的服務端上，這類應用尤其重視服務的響應速度，希望系統(tǒng)停頓時間最短，以給用戶帶來較好的體驗。CMS收集器就非常符合這類應用的需求。

從名字(包含“Mark Sweep”)上就可以看出，CMS收集器是基于“標記—清除”算法實現(xiàn)的，它的運作過程可以分為6個步驟，包括：初始標記、并發(fā)標記、預處理、重新標記、并發(fā)清除、重置。

CMS是一款優(yōu)秀的收集器，它的主要優(yōu)點在名字上已經體現(xiàn)出來了：并發(fā)收集、低停頓，但是CMS還遠達不到完美的程度，它有以下3個明顯的缺點：

1. CMS收集器對CPU資源非常敏感。
2. CMS收集器無法處理浮動垃圾(Floating Garbage)，可能出現(xiàn)“Concurrent Mode Failure”失敗而導致另一次Full GC的產生。
3. CMS是一款基于“標記—清除”算法實現(xiàn)的收集器，這意味著收集結束時會有大量空間碎片產生。

16.介紹下G1垃圾收集器的特點？（較復雜，可以考慮跳過）

G1(Garbage-First)收集器是當今收集器技術發(fā)展的最前沿成果之一。G1是一款面向服務端應用的垃圾收集器。與其他GC收集器相比，G1具備如下特點：并行與并發(fā)、分代收集、空間整合、可預測的停頓。

在G1之前的其他收集器進行收集的范圍都是整個新生代或者老年代，而G1不再是這樣。使用G1收集器時，Java堆的內存布局就與其他收集器有很大差別，它將整個Java堆劃分為多個大小相等的獨立區(qū)域，雖然還保留有新生代和老年代的概念，但新生代和老年代不再是物理隔離的了，它們都是一部分Region（不需要連續(xù)）的集合。

G1收集器之所以能建立可預測的停頓時間模型，是因為它可以有計劃地避免在整個Java堆中進行全區(qū)域的垃圾收集。G1跟蹤各個Region里面的垃圾堆積的價值大?。ɑ厥账@得的空間大小以及回收所需時間的經驗值），在后臺維護一個優(yōu)先列表，每次根據(jù)允許的收集時間，優(yōu)先回收價值最大的Region（這也就是Garbage-First名稱的來由）。這種使用Region劃分內存空間以及有優(yōu)先級的區(qū)域回收方式，保證了G1收集器在有限的時間內可以獲取盡可能高的收集效率。

Mixed GC是G1垃圾收集器特有的收集方式，Mixed GC大致可劃分為全局并發(fā)標記（global concurrent marking）和拷貝存活對象（evacuation）兩個大部分：

global concurrent marking是基于SATB形式的并發(fā)標記，包括以下4個階段：初始標記（Initial Marking）、并發(fā)標記（Concurrent Marking）、最終標記（Final Marking）、清理（Clean Up）。Evacuation階段是全暫停的。它負責把一部分region里的活對象拷貝到空region里去，然后回收原本的region的空間。

17.類加載的過程。

類從被加載到虛擬機內存中開始，到卸載出內存為止，它的整個生命周期包括：加載、驗證、準備、解析、初始化、使用和卸載7個階段。其中驗證、準備、解析3個部分統(tǒng)稱為連接。

加載：

“類加載”過程的一個階段，在加載階段，虛擬機需要完成以下3件事情：

通過一個類的全限定名來獲取定義此類的二進制字節(jié)流。將這個字節(jié)流所代表的靜態(tài)存儲結構轉化為方法區(qū)的運行時數(shù)據(jù)結構。在內存中生成一個代表這個類的java.lang.Class對象，作為方法區(qū)這個類的各種數(shù)據(jù)的訪問入口。

驗證：

連接階段的第一步，這一階段的目的是為了確保Class文件的字節(jié)流中包含的信息符合當前虛擬機的要求，并且不會危害虛擬機自身的安全。從整體上看，驗證階段大致上會完成下面4個階段的檢驗動作：文件格式驗證、元數(shù)據(jù)驗證、字節(jié)碼驗證、符號引用驗證。

準備：

該階段是正式為類變量（static修飾的變量）分配內存并設置類變量初始值的階段，這些變量所使用的內存都將在方法區(qū)中進行分配。這里所說的初始值“通常情況”下是數(shù)據(jù)類型的零值，下表列出了Java中所有基本數(shù)據(jù)類型的零值。

解析：

該階段是虛擬機將常量池內的符號引用替換為直接引用的過程。

初始化：

初始化階段是執(zhí)行類構造器<clinit>()方法的過程。<clinit>()方法是由編譯器自動收集類中的所有類變量（static修飾的變量）的賦值動作和靜態(tài)語句塊（static{}塊）中的語句合并產生的，編譯器收集的順序是由語句在源文件中出現(xiàn)的順序所決定的。如果該類存在父類，則虛擬機會保證在執(zhí)行子類的<clinit>()方法前，父類的<clinit>()方法已經執(zhí)行完畢。因此在虛擬機中第一個被執(zhí)行<clinit>()方法的類肯定是java.lang.Object。

18.Java虛擬機中有哪些類加載器？

從Java虛擬機的角度來講，只存在兩種不同的類加載器：一種是啟動類加載器（Bootstrap ClassLoader），這個類加載器使用C++語言實現(xiàn)，是虛擬機自身的一部分；另一種就是所有其他的類加載器，這些類加載器都由Java語言實現(xiàn)，獨立于虛擬機外部，并且全都繼承自抽象類java.lang.ClassLoader。

從Java開發(fā)人員的角度來看，絕大部分Java程序都會使用到以下3種系統(tǒng)提供的類加載器。

啟動類加載器（Bootstrap ClassLoader）：

這個類加載器負責將存放在<JAVA_HOME>\lib目錄中的，或者被-Xbootclasspath參數(shù)所指定的路徑中的，并且是虛擬機識別的（僅按照文件名識別，如rt.jar，名字不符合的類庫即使放在lib目錄中也不會被加載）類庫加載到虛擬機內存中。

擴展類加載器（Extension ClassLoader）：

這個加載器由sun.misc.Launcher$ExtClassLoader實現(xiàn)，它負責加載<JAVA_HOME>\lib\ext目錄中的，或者被java.ext.dirs系統(tǒng)變量所指定的路徑中的所有類庫，開發(fā)者可以直接使用擴展類加載器。

應用程序類加載器（Application ClassLoader）：

這個類加載器由sun.misc.Launcher$AppClassLoader實現(xiàn)。由于這個類加載器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也稱它為系統(tǒng)類加載器。它負責加載用戶類路徑（ClassPath）上所指定的類庫，開發(fā)者可以直接使用這個類加載器，如果應用程序中沒有自定義過自己的類加載器，一般情況下這個就是程序中默認的類加載器。

我們的應用程序都是由這3種類加載器互相配合進行加載的，如果有必要，還可以加入自己定義的類加載器。這些類加載器之間的關系一般如圖所示。

19.什么是雙親委派模型？

如果一個類加載器收到了類加載的請求，它首先不會自己去嘗試加載這個類，而是把這個請求委派給父類加載器去完成，每一個層次的類加載器都是如此，因此所有的加載請求最終都應該傳送到頂層的啟動類加載器中，只有當父加載器反饋自己無法完成這個加載請求（它的搜索范圍中沒有找到所需的類）時，子加載器才會嘗試自己去加載。

20.使用雙親委派模型的好處？

使用雙親委派模型來組織類加載器之間的關系，有一個顯而易見的好處就是Java類隨著它的類加載器一起具備了一種帶有優(yōu)先級的層次關系。例如類java.lang.Object，它存放在rt.jar之中，無論哪一個類加載器要加載這個類，最終都是委派給處于模型最頂端的啟動類加載器進行加載，因此Object類在程序的各種類加載器環(huán)境中都是同一個類。相反，如果沒有使用雙親委派模型，由各個類加載器自行去加載的話，如果用戶自己編寫了一個稱為java.lang.Object的類，并放在程序的ClassPath中，那系統(tǒng)中將會出現(xiàn)多個不同的Object類，Java 類型體系中最基礎的行為也就無法保證，應用程序也將會變得一片混亂。

總結

這篇JAVA虛擬機·面試題的總結就到這了，希望大家可以多多關注腳本之家的其他精彩文章!