這是面試專題系列第五篇JVM篇。這一篇可能稍微比較長，沒有耐心的同學建議直接拖到最后。

說說JVM的內存布局？

Java虛擬機主要包含幾個區(qū)域：

堆：堆Java虛擬機中最大的一塊內存，是線程共享的內存區(qū)域，基本上所有的對象實例數組都是在堆上分配空間。堆區(qū)細分為Yound區(qū)年輕代和Old區(qū)老年代，其中年輕代又分為Eden、S0、S1 3個部分，他們默認的比例是8:1:1的大小。

棧：棧是線程私有的內存區(qū)域，每個方法執(zhí)行的時候都會在棧創(chuàng)建一個棧幀，方法的調用過程就對應著棧的入棧和出棧的過程。每個棧幀的結構又包含局部變量表、操作數棧、動態(tài)連接、方法返回地址。

局部變量表用于存儲方法參數和局部變量。當第一個方法被調用的時候，他的參數會被傳遞至從0開始的連續(xù)的局部變量表中。

操作數棧用于一些字節(jié)碼指令從局部變量表中傳遞至操作數棧，也用來準備方法調用的參數以及接收方法返回結果。

動態(tài)連接用于將符號引用表示的方法轉換為實際方法的直接引用。

元數據：在Java1.7之前，包含方法區(qū)的概念，常量池就存在于方法區(qū)（永久代）中，而方法區(qū)本身是一個邏輯上的概念，在1.7之后則是把常量池移到了堆內，1.8之后移出了永久代的概念(方法區(qū)的概念仍然保留)，實現(xiàn)方式則是現(xiàn)在的元數據。它包含類的元信息和運行時常量池。

Class文件就是類和接口的定義信息。

運行時常量池就是類和接口的常量池運行時的表現(xiàn)形式。

本地方法棧：主要用于執(zhí)行本地native方法的區(qū)域

程序計數器：也是線程私有的區(qū)域，用于記錄當前線程下虛擬機正在執(zhí)行的字節(jié)碼的指令地址

知道new一個對象的過程嗎？

當虛擬機遇見new關鍵字時候，實現(xiàn)判斷當前類是否已經加載，如果類沒有加載，首先執(zhí)行類的加載機制，加載完成后再為對象分配空間、初始化等。

1. 首先校驗當前類是否被加載，如果沒有加載，執(zhí)行類加載機制
2. 加載：就是從字節(jié)碼加載成二進制流的過程
3. 驗證：當然加載完成之后，當然需要校驗Class文件是否符合虛擬機規(guī)范，跟我們接口請求一樣，第一件事情當然是先做個參數校驗了
4. 準備：為靜態(tài)變量、常量賦默認值
5. 解析：把常量池中符號引用(以符號描述引用的目標)替換為直接引用(指向目標的指針或者句柄等)的過程
6. 初始化：執(zhí)行static代碼塊(cinit)進行初始化，如果存在父類，先對父類進行初始化

Ps：靜態(tài)代碼塊是絕對線程安全的，只能隱式被java虛擬機在類加載過程中初始化調用！(此處該有問題static代碼塊線程安全嗎？)

當類加載完成之后，緊接著就是對象分配內存空間和初始化的過程

1. 首先為對象分配合適大小的內存空間
2. 接著為實例變量賦默認值
3. 設置對象的頭信息，對象hash碼、GC分代年齡、元數據信息等
4. 執(zhí)行構造函數(init)初始化

知道雙親委派模型嗎？

類加載器自頂向下分為：

1. Bootstrap ClassLoader啟動類加載器：默認會去加載JAVA_HOME/lib目錄下的jar
2. Extention ClassLoader擴展類加載器：默認去加載JAVA_HOME/lib/ext目錄下的jar
3. Application ClassLoader應用程序類加載器：比如我們的web應用，會加載web程序中ClassPath下的類
4. User ClassLoader用戶自定義類加載器：由用戶自己定義

當我們在加載類的時候，首先都會向上詢問自己的父加載器是否已經加載，如果沒有則依次向上詢問，如果沒有加載，則從上到下依次嘗試是否能加載當前類，直到加載成功。

說說有哪些垃圾回收算法？

標記-清除

統(tǒng)一標記出需要回收的對象，標記完成之后統(tǒng)一回收所有被標記的對象，而由于標記的過程需要遍歷所有的GC ROOT，清除的過程也要遍歷堆中所有的對象，所以標記-清除算法的效率低下，同時也帶來了內存碎片的問題。

復制算法

為了解決性能的問題，復制算法應運而生，它將內存分為大小相等的兩塊區(qū)域，每次使用其中的一塊，當一塊內存使用完之后，將還存活的對象拷貝到另外一塊內存區(qū)域中，然后把當前內存清空，這樣性能和內存碎片的問題得以解決。但是同時帶來了另外一個問題，可使用的內存空間縮小了一半！

因此，誕生了我們現(xiàn)在的常見的年輕代+老年代的內存結構：Eden+S0+S1組成，因為根據IBM的研究顯示，98%的對象都是朝生夕死，所以實際上存活的對象并不是很多，完全不需要用到一半內存浪費，所以默認的比例是8:1:1。

這樣，在使用的時候只使用Eden區(qū)和S0S1中的一個，每次都把存活的對象拷貝另外一個未使用的Survivor區(qū)，同時清空Eden和使用的Survivor，這樣下來內存的浪費就只有10%了。

如果最后未使用的Survivor放不下存活的對象，這些對象就進入Old老年代了。

PS：所以有一些初級點的問題會問你為什么要分為Eden區(qū)和2個Survior區(qū)？有什么作用？就是為了節(jié)省內存和解決內存碎片的問題，這些算法都是為了解決問題而產生的，如果理解原因你就不需要死記硬背了

標記-整理

針對老年代再用復制算法顯然不合適，因為進入老年代的對象都存活率比較高了，這時候再頻繁的復制對性能影響就比較大，而且也不會再有另外的空間進行兜底。所以針對老年代的特點，通過標記-整理算法，標記出所有的存活對象，讓所有存活的對象都向一端移動，然后清理掉邊界以外的內存空間。

那么什么是GC ROOT？有哪些GC ROOT？

上面提到的標記的算法，怎么標記一個對象是否存活？簡單的通過引用計數法，給對象設置一個引用計數器，每當有一個地方引用他，就給計數器+1，反之則計數器-1，但是這個簡單的算法無法解決循環(huán)引用的問題。

Java通過可達性分析算法來達到標記存活對象的目的，定義一系列的GC ROOT為起點，從起點開始向下開始搜索，搜索走過的路徑稱為引用鏈，當一個對象到GC ROOT沒有任何引用鏈相連的話，則對象可以判定是可以被回收的。

而可以作為GC ROOT的對象包括：

1. 棧中引用的對象

2. 靜態(tài)變量、常量引用的對象

3. 本地方法棧native方法引用的對象

垃圾回收器了解嗎？年輕代和老年代都有哪些垃圾回收器？

年輕代的垃圾收集器包含有Serial、ParNew、Parallell，老年代則包括Serial Old老年代版本、CMS、Parallel Old老年代版本和JDK11中的船新的G1收集器。

Serial：單線程版本收集器，進行垃圾回收的時候會STW（Stop The World），也就是進行垃圾回收的時候其他的工作線程都必須暫停

ParNew：Serial的多線程版本，用于和CMS配合使用

Parallel Scavenge：可以并行收集的多線程垃圾收集器

Serial Old：Serial的老年代版本，也是單線程

Parallel Old：Parallel Scavenge的老年代版本

CMS（Concurrent Mark Sweep）：CMS收集器是以獲取最短停頓時間為目標的收集器，相對于其他的收集器STW的時間更短暫，可以并行收集是他的特點，同時他基于標記-清除算法，整個GC的過程分為4步。

1. 初始標記：標記GC ROOT能關聯(lián)到的對象，需要STW
2. 并發(fā)標記：從GCRoots的直接關聯(lián)對象開始遍歷整個對象圖的過程，不需要STW
3. 重新標記：為了修正并發(fā)標記期間，因用戶程序繼續(xù)運作而導致標記產生改變的標記，需要STW
4. 并發(fā)清除：清理刪除掉標記階段判斷的已經死亡的對象，不需要STW

從整個過程來看，并發(fā)標記和并發(fā)清除的耗時最長，但是不需要停止用戶線程，而初始標記和重新標記的耗時較短，但是需要停止用戶線程，總體而言，整個過程造成的停頓時間較短，大部分時候是可以和用戶線程一起工作的。

G1（Garbage First）：G1收集器是JDK9的默認垃圾收集器，而且不再區(qū)分年輕代和老年代進行回收。

G1的原理了解嗎？

G1作為JDK9之后的服務端默認收集器，且不再區(qū)分年輕代和老年代進行垃圾回收，他把內存劃分為多個Region，每個Region的大小可以通過-XX：G1HeapRegionSize設置，大小為1~32M，對于大對象的存儲則衍生出Humongous的概念，超過Region大小一半的對象會被認為是大對象，而超過整個Region大小的對象被認為是超級大對象，將會被存儲在連續(xù)的N個Humongous Region中，G1在進行回收的時候會在后臺維護一個優(yōu)先級列表，每次根據用戶設定允許的收集停頓時間優(yōu)先回收收益最大的Region。

G1的回收過程分為以下四個步驟：

1. 初始標記：標記GC ROOT能關聯(lián)到的對象，需要STW
2. 并發(fā)標記：從GCRoots的直接關聯(lián)對象開始遍歷整個對象圖的過程，掃描完成后還會重新處理并發(fā)標記過程中產生變動的對象
3. 最終標記：短暫暫停用戶線程，再處理一次，需要STW
4. 篩選回收：更新Region的統(tǒng)計數據，對每個Region的回收價值和成本排序，根據用戶設置的停頓時間制定回收計劃。再把需要回收的Region中存活對象復制到空的Region，同時清理舊的Region。需要STW

總的來說除了并發(fā)標記之外，其他幾個過程也還是需要短暫的STW，G1的目標是在停頓和延遲可控的情況下盡可能提高吞吐量。

什么時候會觸發(fā)YGC和FGC？對象什么時候會進入老年代？

當一個新的對象來申請內存空間的時候，如果Eden區(qū)無法滿足內存分配需求，則觸發(fā)YGC，使用中的Survivor區(qū)和Eden區(qū)存活對象送到未使用的Survivor區(qū)，如果YGC之后還是沒有足夠空間，則直接進入老年代分配，如果老年代也無法分配空間，觸發(fā)FGC，F(xiàn)GC之后還是放不下則報出OOM異常。

YGC之后，存活的對象將會被復制到未使用的Survivor區(qū)，如果S區(qū)放不下，則直接晉升至老年代。而對于那些一直在Survivor區(qū)來回復制的對象，通過-XX：MaxTenuringThreshold配置交換閾值，默認15次，如果超過次數同樣進入老年代。

此外，還有一種動態(tài)年齡的判斷機制，不需要等到MaxTenuringThreshold就能晉升老年代。如果在Survivor空間中相同年齡所有對象大小的總和大于Survivor空間的一半，年齡大于或等于該年齡的對象就可以直接進入老年代。

頻繁FullGC怎么排查？

這種問題最好的辦法就是結合有具體的例子舉例分析，如果沒有就說一般的分析步驟。發(fā)生FGC有可能是內存分配不合理，比如Eden區(qū)太小，導致對象頻繁進入老年代，這時候通過啟動參數配置就能看出來，另外有可能就是存在內存泄露，可以通過以下的步驟進行排查：

1. jstat -gcutil或者查看gc.log日志，查看內存回收情況

S0 S1 分別代表兩個Survivor區(qū)占比

E代表Eden區(qū)占比，圖中可以看到使用78%

O代表老年代，M代表元空間，YGC發(fā)生54次，YGCT代表YGC累計耗時，GCT代表GC累計耗時。

[GC [FGC 開頭代表垃圾回收的類型

PSYoungGen: 6130K->6130K(9216K)] 12274K->14330K(19456K), 0.0034895 secs代表YGC前后內存使用情況

Times: user=0.02 sys=0.00, real=0.00 secs，user表示用戶態(tài)消耗的CPU時間，sys表示內核態(tài)消耗的CPU時間，real表示各種墻時鐘的等待時間

這兩張圖只是舉例并沒有關聯(lián)關系，比如你從圖里面看能到是否進行FGC，F(xiàn)GC的時間花費多長，GC后老年代，年輕代內存是否有減少，得到一些初步的情況來做出判斷。

2. dump出內存文件在具體分析，比如通過jmap命令jmap -dump:format=b,file=dumpfile pid，導出之后再通過 Eclipse Memory Analyzer等工具進行分析，定位到代碼，修復

這里還會可能存在一個提問的點，比如CPU飆高，同時FGC怎么辦？辦法比較類似

1. 找到當前進程的pid，top -p pid -H 查看資源占用，找到線程
2. printf “%x\n” pid，把線程pid轉為16進制，比如0x32d
3. jstack pid|grep -A 10 0x32d查看線程的堆棧日志，還找不到問題繼續(xù)
4. dump出內存文件用MAT等工具進行分析，定位到代碼，修復

JVM調優(yōu)有什么經驗嗎？

要明白一點，所有的調優(yōu)的目的都是為了用更小的硬件成本達到更高的吞吐，JVM的調優(yōu)也是一樣，通過對垃圾收集器和內存分配的調優(yōu)達到性能的最佳。

簡單的參數含義

首先，需要知道幾個主要的參數含義。

1. -Xms設置初始堆的大小，-Xmx設置最大堆的大小
2. -XX:NewSize年輕代大小，-XX:MaxNewSize年輕代最大值，-Xmn則是相當于同時配置-XX:NewSize和-XX:MaxNewSize為一樣的值
3. -XX:NewRatio設置年輕代和年老代的比值，如果為3，表示年輕代與老年代比值為1:3，默認值為2
4. -XX:SurvivorRatio年輕代和兩個Survivor的比值，默認8，代表比值為8:1:1
5. -XX:PretenureSizeThreshold 當創(chuàng)建的對象超過指定大小時，直接把對象分配在老年代。
6. -XX:MaxTenuringThreshold設定對象在Survivor復制的最大年齡閾值，超過閾值轉移到老年代
7. -XX:MaxDirectMemorySize當Direct ByteBuffer分配的堆外內存到達指定大小后，即觸發(fā)Full GC

調優(yōu)

1. 為了打印日志方便排查問題最好開啟GC日志，開啟GC日志對性能影響微乎其微，但是能幫助我們快速排查定位問題。-XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:gc.log
2. 一般設置-Xms=-Xmx，這樣可以獲得固定大小的堆內存，減少GC的次數和耗時，可以使得堆相對穩(wěn)定
3. -XX:+HeapDumpOnOutOfMemoryError讓JVM在發(fā)生內存溢出的時候自動生成內存快照，方便排查問題
4. -Xmn設置新生代的大小，太小會增加YGC，太大會減小老年代大小，一般設置為整個堆的1/4到1/3
5. 設置-XX:+DisableExplicitGC禁止系統(tǒng)System.gc()，防止手動誤觸發(fā)FGC造成問題