1、詳細jvm記憶體模型
2、講講什麼情況下回出現記憶體溢出，記憶體洩漏？
3、說說Java線程棧
4、JVM 年輕代到年老代的晉升過程的判斷條件是什麼呢？
5、JVM 出現 fullGC 很頻繁，怎麼去線上排查問題？
6、類加載為什麼要使用雙親委派模式，有沒有什麼場景是打破了這個模式？
7、類的執行個體化順序
8、JVM垃圾回收機制，何時觸發MinorGC等操作
9、JVM 中一次完整的 GC 流程（從 ygc 到 fgc）是怎樣的
10、各種回收器，各自優缺點，重點CMS、G1
11、各種回收算法
12、OOM錯誤，stackoverflow錯誤，permgen space錯誤

面試必問之JVM篇！！一、簡單聊聊JVM二、JVM面試題

聲明：全文預設指的是HotSpot VM

一、簡單聊聊JVM

1.1先來看看簡單的Java程式

現在我有一個JavaBean：

public class Java3y {

    // 姓名
    private String name;

    // 年齡
    private int age;

       //.....各種get/set方法/toString
}

一個測試類：

public class Java3yTest {

    public static void main(String[] args) {
        
        Java3y java3y = new Java3y();
        java3y.setName("Java3y");
        System.out.println(java3y);

    }
}

我們在初學的時候肯定用過

javac

來編譯.java檔案代碼，用過

java

指令來執行編譯後生成的.class檔案。

Java源檔案：

在使用IDE點選運作的時候其實就是将這兩個指令結合起來了(編譯并運作)，友善我們開發。

生成class檔案

解析class檔案得到結果

1.2編譯過程

.java檔案是由Java源碼編譯器(上述所說的javac.exe)來完成，流程圖如下所示：

Java源碼編譯由以下三個過程組成：

分析和輸入到符号表
注解處理
語義分析和生成class檔案

1.2.1編譯時期-文法糖

文法糖可以看做是編譯器實作的一些“小把戲”，這些“小把戲”可能會使得效率“大提升”。

最值得說明的就是泛型了，這個文法糖可以說我們是經常會使用到的！

泛型隻會在Java源碼中存在，編譯過後會被替換為原來的原生類型（Raw Type，也稱為裸類型）了。這個過程也被稱為：泛型擦除。

有了泛型這顆文法糖以後：

代碼更加簡潔【不用強制轉換】
程式更加健壯【隻要編譯時期沒有警告，那麼運作時期就不會出現ClassCastException異常】
可讀性和穩定性【在編寫集合的時候，就限定了類型】

了解泛型更多的知識：

1.3JVM實作跨平台

至此，我們通過javac.exe編譯器編譯我們的.java源代碼檔案生成出.class檔案了！

這些.class檔案很明顯是不能直接運作的，它不像C語言(編譯cpp後生成exe檔案直接運作)

這些.class檔案是交由JVM來解析運作！

JVM是運作在作業系統之上的，每個作業系統的指令是不同的，而JDK是區分作業系統的，隻要你的本地系統裝了JDK，這個JDK就是能夠和目前系統相容的。
而class位元組碼運作在JVM之上，是以不用關心class位元組碼是在哪個作業系統編譯的，隻要符合JVM規範，那麼，這個位元組碼檔案就是可運作的。
是以Java就做到了跨平台—>一次編譯，到處運作！

1.4class檔案和JVM的恩怨情仇

1.4.1類的加載時機

現在我們例子中生成的兩個.class檔案都會直接被加載到JVM中嗎？？

虛拟機規範則是嚴格規定了有且隻有5種情況必須立即對類進行“初始化”(class檔案加載到JVM中)：

建立類的執行個體(new 的方式)。通路某個類或接口的靜态變量，或者對該靜态變量指派，調用類的靜态方法
反射的方式
初始化某個類的子類，則其父類也會被初始化
Java虛拟機啟動時被标明為啟動類的類，直接使用java.exe指令來運作某個主類（包含main方法的那個類）
當使用JDK1.7的動态語言支援時(…)

是以說：

Java類的加載是動态的，它并不會一次性将所有類全部加載後再運作，而是保證程式運作的基礎類(像是基類)完全加載到jvm中，至于其他類，則在需要的時候才加載。這當然就是為了節省記憶體開銷。

1.4.2如何将類加載到jvm

class檔案是通過類的加載器裝載到jvm中的！

Java預設有三種類加載器：

面試必問之JVM篇！！一、簡單聊聊JVM二、JVM面試題

各個加載器的工作責任：

Bootstrap ClassLoader：負責加載$JAVA_HOME中jre/lib/rt.jar裡所有的class，由C++實作，不是ClassLoader子類
Extension ClassLoader：負責加載java平台中擴充功能的一些jar包，包括$JAVA_HOME中jre/lib/*.jar或-Djava.ext.dirs指定目錄下的jar包

工作過程：

當AppClassLoader加載一個class時，它首先不會自己去嘗試加載這個類，而是把類加載請求委派給父類加載器ExtClassLoader去完成。
當ExtClassLoader加載一個class時，它首先也不會自己去嘗試加載這個類，而是把類加載請求委派給BootStrapClassLoader去完成。
如果BootStrapClassLoader加載失敗（例如在$JAVA_HOME/jre/lib裡未查找到該class），會使用ExtClassLoader來嘗試加載；
若ExtClassLoader也加載失敗，則會使用AppClassLoader來加載
如果AppClassLoader也加載失敗，則會報出異常ClassNotFoundException

其實這就是所謂的雙親委派模型。簡單來說：如果一個類加載器收到了類加載的請求，它首先不會自己去嘗試加載這個類，而是把請求委托給父加載器去完成，依次向上。

好處：

防止記憶體中出現多份同樣的位元組碼(安全性角度)

特别說明：

類加載器在成功加載某個類之後，會把得到的 java.lang.Class類的執行個體緩存起來。下次再請求加載該類的時候，類加載器會直接使用緩存的類的執行個體，而不會嘗試再次加載。

1.4.2類加載詳細過程

加載器加載到jvm中，接下來其實又分了好幾個步驟：

加載，查找并加載類的二進制資料，在Java堆中也建立一個java.lang.Class類的對象。
連接配接，連接配接又包含三塊内容：驗證、準備、初始化。
- 驗證，檔案格式、中繼資料、位元組碼、符号引用驗證；
- 準備，為類的靜态變量配置設定記憶體，并将其初始化為預設值
- 解析，把類中的符号引用轉換為直接引用
初始化，為類的靜态變量賦予正确的初始值。

面試必問之JVM篇！！一、簡單聊聊JVM二、JVM面試題

1.4.3JIT即時編輯器

一般我們可能會想：JVM在加載了這些class檔案以後，針對這些位元組碼，逐條取出，逐條執行–>解析器解析。

但如果是這樣的話，那就太慢了！

我們的JVM是這樣實作的：

就是把這些Java位元組碼重新編譯優化，生成機器碼，讓CPU直接執行。這樣編出來的代碼效率會更高。
編譯也是要花費時間的，我們一般對熱點代碼做編譯，非熱點代碼直接解析就好了。

熱點代碼解釋：一、多次調用的方法。二、多次執行的循環體

使用熱點探測來檢測是否為熱點代碼，熱點探測有兩種方式：

采樣
計數器

目前HotSpot使用的是計數器的方式，它為每個方法準備了兩類計數器：

方法調用計數器（Invocation Counter）
回邊計數器（Back EdgeCounter）。
在确定虛拟機運作參數的前提下，這兩個計數器都有一個确定的門檻值，當計數器超過門檻值溢出了，就會觸發JIT編譯。

面試必問之JVM篇！！一、簡單聊聊JVM二、JVM面試題

1.4.4回到例子中

按我們程式來走，我們的Java3yTest.class檔案會被AppClassLoader加載器(因為ExtClassLoader和BootStrap加載器都不會加載它[雙親委派模型])加載到JVM中。随後發現了要使用Java3y這個類，我們的Java3y.class檔案會被AppClassLoader加載器(因為ExtClassLoader和BootStrap加載器都不會加載它[雙親委派模型])加載到JVM中。

面試必問之JVM篇！！一、簡單聊聊JVM二、JVM面試題

詳情參考：

淺解JVM加載class檔案

添加連結描述JVM雜談之JIT

擴充閱讀：

深入探讨 Java 類加載器

深入淺出 JIT 編譯器

Java 類加載器（ClassLoader）的實際使用場景有哪些？

1.5類加載完以後JVM幹了什麼？

在類加載檢查通過後，接下來虛拟機将為新生對象配置設定記憶體。

1.5.1JVM的記憶體模型

首先我們來了解一下JVM的記憶體模型的怎麼樣的：

基于jdk1.8畫的JVM的記憶體模型—>我畫得比較細。

面試必問之JVM篇！！一、簡單聊聊JVM二、JVM面試題

簡單看了一下記憶體模型，簡單看看每個區域究竟存儲的是什麼(幹的是什麼)：

堆：存放對象執行個體，幾乎所有的對象執行個體都在這裡配置設定記憶體
虛拟機棧：虛拟機棧描述的是Java方法執行的記憶體模型：每個方法被執行的時候都會同時建立一個棧幀（Stack Frame）用于存儲局部變量表、操作棧、動态連結、方法出口等資訊
本地方法棧：本地方法棧則是為虛拟機使用到的Native方法服務。
方法區：存儲已被虛拟機加載的類中繼資料資訊(元空間)
程式計數器：目前線程所執行的位元組碼的行号訓示器

1.5.2例子中的流程

面試必問之JVM篇！！一、簡單聊聊JVM二、JVM面試題

我來宏觀簡述一下我們的例子中的工作流程：

通過java.exe運作Java3yTest.class，随後被加載到JVM中，元空間存儲着類的資訊(包括類的名稱、方法資訊、字段資訊…)。
然後JVM找到Java3yTest的主函數入口(main)，為main函數建立棧幀，開始執行main函數
main函數的第一條指令是Java3y java3y = new Java3y();就是讓JVM建立一個Java3y對象，但是這時候方法區中沒有Java3y類的資訊，是以JVM馬上加載Java3y類，把Java3y類的類型資訊放到方法區中(元空間)
加載完Java3y類之後，Java虛拟機做的第一件事情就是在堆區中為一個新的Java3y執行個體配置設定記憶體, 然後調用構造函數初始化Java3y執行個體，這個Java3y執行個體持有着指向方法區的Java3y類的類型資訊（其中包含有方法表，java動态綁定的底層實作）的引用
當使用java3y.setName(“Java3y”);的時候，JVM根據java3y引用找到Java3y對象，然後根據Java3y對https://www.zhihu.com/question/30301819象持有的引用定位到方法區中Java3y類的類型資訊的方法表，獲得setName()函數的位元組碼的位址
為setName()函數建立棧幀，開始運作setName()函數

從微觀上其實還做了很多東西，正如上面所說的類加載過程（加載–>連接配接(驗證，準備，解析)–>初始化)，在類加載完之後jvm為其配置設定記憶體(配置設定記憶體中也做了非常多的事)。由于這些步驟并不是一步一步往下走，會有很多的“混沌bootstrap”的過程，是以很難描述清楚。

擴充閱讀：

先有Class對象還是先有Object

參考資料：

java程式編譯和運作的過程

java jvm運作機制及基本原理

1.6簡單聊聊各種常量池

在寫這篇文章的時候，原本以為我對String s = “aaa”;類似這些題目已經是不成問題了，直到我遇到了String.intern()這樣的方法與諸如String s1 = new String(“1”) + new String(“2”);混合一起用的時候

我發現，我還是太年輕了。

首先我是先閱讀了美團技術團隊的這篇文章：深入解析String#intern

嗯，然後就懵逼了。我摘抄一下他的例子：

public static void main(String[] args) {
    String s = new String("1");
    s.intern();
    String s2 = "1";
    System.out.println(s == s2);

    String s3 = new String("1") + new String("1");
    s3.intern();
    String s4 = "11";
    System.out.println(s3 == s4);
}

列印結果是

jdk7,8下false true

調換一下位置後：

public static void main(String[] args) {

    String s = new String("1");
    String s2 = "1";
    s.intern();
    System.out.println(s == s2);

    String s3 = new String("1") + new String("1");
    String s4 = "11";
    s3.intern();
    System.out.println(s3 == s4);
}

列印結果為：

jdk7,8下false false

文章中有很詳細的解析，但我簡單閱讀了幾次以後還是很懵逼。是以我知道了自己的知識點還存在漏洞，後面閱讀了一下R大之前寫過的文章：

請别再拿“String s = new String(“xyz”);建立了多少個String執行個體”來面試了吧

看完了之後，就更加懵逼了。

後來，在zhihu上看到了這個回答：

Java 中new String(“字面量”) 中 “字面量” 是何時進入字元串常量池的?

結合網上資料和自己的思考，下面整理一下對常量池的了解~~

1.6.1各個常量池的情況

針對于jdk1.7之後：

1.6.1各個常量池的情況
針對于jdk1.7之後：

常量池存儲的是：

字面量(Literal)：文本字元串等---->用雙引号引起來的字元串字面量都會進這裡面
符号引用(Symbolic References)
- 類和接口的全限定名(Full Qualified Name)
- 字段的名稱和描述符(Descriptor)
- 方法的名稱和描述符

常量池（Constant Pool Table），用于存放編譯期生成的各種字面量和符号引用，這部分内容将在類加載後進入方法區的運作時常量池中存放—>來源：深入了解Java虛拟機 JVM進階特性與最佳實踐（第二版）

現在我們的運作時常量池隻是換了一個位置(原本來方法區，現在在堆中),但可以明确的是：類加載後，常量池中的資料會在運作時常量池中存放！

别人總結的常量池：

它是Class檔案中的内容，還不是運作時的内容，不要了解它是個池子，其實就是Class檔案中的位元組碼指

HotSpot VM裡，記錄interned string的一個全局表叫做StringTable，它本質上就是個HashSet。注意它隻存儲對java.lang.String執行個體的引用，而不存儲String對象的内容

字元串常量池隻存儲引用，不存儲内容！

再來看一下我們的intern方法：

* When the intern method is invoked, if the pool already contains a
 * string equal to this {@code String} object as determined by
 * the {@link #equals(Object)} method, then the string from the pool is
 * returned. Otherwise, this {@code String} object is added to the
 * pool and a reference to this {@code String} object is returned.

如果常量池中存在目前字元串，那麼直接傳回常量池中它的引用。
如果常量池中沒有此字元串, 會将此字元串引用儲存到常量池中後, 再直接傳回該字元串的引用！

1.6.2解析題目

本來打算寫注釋的方式來解釋的，但好像挺難說清楚的。我還是畫圖吧…

public static void main(String[] args) {

 
    String s = new String("1");

    s.intern();


    String s2 = "1";

    System.out.println(s == s2);// false
    System.out.println("-----------關注公衆号：Java3y-------------");
}

第一句：

String s = new String("1");

面試必問之JVM篇！！一、簡單聊聊JVM二、JVM面試題

第二句：

s.intern()

;發現字元串常量池中已經存在"1"字元串對象，直接傳回字元串常量池中對堆的引用(但沒有接收)–>此時s引用還是指向着堆中的對象

面試必問之JVM篇！！一、簡單聊聊JVM二、JVM面試題

第三句：

String s2 = "1"

;發現字元串常量池已經儲存了該對象的引用了，直接傳回字元串常量池對堆中字元串的引用

面試必問之JVM篇！！一、簡單聊聊JVM二、JVM面試題

很容易看到，兩條引用是不一樣的！是以傳回false。

public static void main(String[] args) {

        System.out.println("-----------關注公衆号：Java3y-------------");

        String s3 = new String("1") + new String("1");


        s3.intern();


        String s4 = "11";
        System.out.println(s3 == s4); // true
    }

第一句：String s3 = new String(“1”) + new String(“1”);注意：此時"11"對象并沒有在字元串常量池中儲存引用。

面試必問之JVM篇！！一、簡單聊聊JVM二、JVM面試題

第二句：

s3.intern()

;發現"11"對象并沒有在字元串常量池中，于是将"11"對象在字元串常量池中儲存目前字元串的引用，并傳回目前字元串的引用(但沒有接收)

面試必問之JVM篇！！一、簡單聊聊JVM二、JVM面試題

第三句：String s4 = “11”;發現字元串常量池已經存在引用了，直接傳回(拿到的也是與s3相同指向的引用)

面試必問之JVM篇！！一、簡單聊聊JVM二、JVM面試題

根據上述所說的：最後會傳回true~~~

如果還是不太清楚的同學，可以試着接收一下intern()方法的傳回值，再看看上述的圖，應該就可以了解了

下面的就由各位來做做，看是不是掌握了：

public static void main(String[] args) {

        String s = new String("1");
        String s2 = "1";
        s.intern();
        System.out.println(s == s2);//false

        String s3 = new String("1") + new String("1");
        String s4 = "11";
        s3.intern();
        System.out.println(s3 == s4);//false
    }

還有

public static void main(String[] args) {
        String s1 = new String("he") + new String("llo");
        String s2 = new String("h") + new String("ello");
        String s3 = s1.intern();
        String s4 = s2.intern();
        System.out.println(s1 == s3);// true
        System.out.println(s1 == s4);// true
    }

1.7GC垃圾回收

可以說GC垃圾回收是JVM中一個非常重要的知識點，應該非常詳細去講解的。但在我學習的途中，我已經發現了有很好的文章去講解垃圾回收的了。

是以，這裡我隻簡單介紹一下垃圾回收的東西，詳細的可以到下面的面試題中查閱和最後給出相關的資料閱

讀吧~

1.7.1JVM垃圾回收簡單介紹

在C++中，我們知道建立出的對象是需要手動去delete掉的。我們Java程式運作在JVM中，JVM可以幫我們“自動”回收不需要的對象，對我們來說是十分友善的。

雖然說“自動”回收了我們不需要的對象，但如果我們想變強，就要變秃…不對，就要去了解一下它究竟是怎麼幹的，理論的知識有哪些。

首先，JVM回收的是垃圾，垃圾就是我們程式中已經是不需要的了。垃圾收集器在對堆進行回收前，第一件事情就是要确定這些對象之中哪些還“存活”着，哪些已經“死去”。判斷哪些對象“死去”常用有兩種方式：

引用計數法–>這種難以解決對象之間的循環引用的問題
可達性分析算法–>主流的JVM采用的是這種方式

面試必問之JVM篇！！一、簡單聊聊JVM二、JVM面試題

現在已經可以判斷哪些對象已經“死去”了，我們現在要對這些“死去”的對象進行回收，回收也有好幾種算法：

标記-清除算法
複制算法
标記-整理算法
分代收集算法

(這些算法詳情可看下面的面試題内容)~

無論是可達性分析算法，還是垃圾回收算法，JVM使用的都是準确式GC。JVM是使用一組稱為OopMap的資料結構，來存儲所有的對象引用(這樣就不用周遊整個記憶體去查找了，空間換時間)。

并且不會将所有的指令都生成OopMap，隻會在安全點上生成OopMap，在安全區域上開始GC。

在OopMap的協助下，HotSpot可以快速且準确地完成GC Roots枚舉（可達性分析）。

上面所講的垃圾收集算法隻能算是方法論，落地實作的是垃圾收集器：

Serial收集器
ParNew收集器
Parallel Scavenge收集器
Serial Old收集器
Parallel Old收集器
CMS收集器
G1收集器

上面這些收集器大部分是可以互相組合使用的

面試必問之JVM篇！！一、簡單聊聊JVM二、JVM面試題

1.8JVM參數與調優

很多做過JavaWeb項目(ssh/ssm)這樣的同學可能都會遇到過OutOfMemory這樣的錯誤。一般解決起來也很友善，在啟動的時候加個參數就行了。

上面也說了很多關于JVM的東西—>JVM對記憶體的劃分啊，JVM各種的垃圾收集器啊。

記憶體的配置設定的大小啊，使用哪個收集器啊，這些都可以由我們根據需求，現實情況來指定的，這裡就不詳細說了，等真正用到的時候才回來填坑吧~~~~

參考資料：

JVM系列三:JVM參數設定、分析

二、JVM面試題

拿些常見的JVM面試題來做做，加深一下了解和查缺補漏：

1、詳細jvm記憶體模型

2、講講什麼情況下回出現記憶體溢出，記憶體洩漏？

3、說說Java線程棧

4、JVM 年輕代到年老代的晉升過程的判斷條件是什麼呢？

5、JVM 出現 fullGC 很頻繁，怎麼去線上排查問題？

6、類加載為什麼要使用雙親委派模式，有沒有什麼場景是打破了這個模式？

7、類的執行個體化順序

8、JVM垃圾回收機制，何時觸發MinorGC等操作

9、JVM 中一次完整的 GC 流程（從 ygc 到 fgc）是怎樣的

10、各種回收器，各自優缺點，重點CMS、G1

11、各種回收算法

12、OOM錯誤，stackoverflow錯誤，permgen space錯誤

題目來源：

https://www.jianshu.com/p/a07d1d4004b0

2.1詳細jvm記憶體模型

根據 JVM 規範，JVM 記憶體共分為虛拟機棧、堆、方法區、程式計數器、本地方法棧五個部分。

面試必問之JVM篇！！一、簡單聊聊JVM二、JVM面試題

具體可能會聊聊jdk1.7以前的PermGen（永久代），替換成Metaspace（元空間）

原本永久代存儲的資料：符号引用(Symbols)轉移到了native heap；字面量(interned strings)轉移到了java heap；類的靜态變量(class statics)轉移到了java heap
Metaspace（元空間）存儲的是類的中繼資料資訊（metadata）

元空間的本質和永久代類似，都是對JVM規範中方法區的實作。不過元空間與永久代之間最大的差別在于：元空間并不在虛拟機中，而是使用本地記憶體。
替換的好處：一、字元串存在永久代中，容易出現性能問題和記憶體溢出。二、永久代會為 GC 帶來不必要的複雜度，并且回收效率偏低

面試必問之JVM篇！！一、簡單聊聊JVM二、JVM面試題

圖檔來源：https://blog.csdn.net/tophawk/article/details/78704074

參考資料：

https://www.cnblogs.com/paddix/p/5309550.html

https://www.jianshu.com/p/a07d1d4004b0

2.2講講什麼情況下回出現記憶體溢出，記憶體洩漏？

記憶體洩漏的原因很簡單：

對象是可達的(一直被引用)
但是對象不會被使用

常見的記憶體洩漏例子：

public static void main(String[] args) {

        Set set = new HashSet();

        for (int i = 0; i < 10; i++) {
            Object object = new Object();
            set.add(object);

            // 設定為空，這對象我不再用了
            object = null;
        }

        // 但是set集合中還維護這obj的引用，gc不會回收object對象
        System.out.println(set);
    }

解決這個記憶體洩漏問題也很簡單，将set設定為null，那就可以避免上訴記憶體洩漏問題了。其他記憶體洩漏得一步一步分析了。

記憶體洩漏參考資料：

https://www.ibm.com/developerworks/cn/java/l-JavaMemoryLeak/

記憶體溢出的原因：

記憶體洩露導緻堆棧記憶體不斷增大，進而引發記憶體溢出。
大量的jar，class檔案加載，裝載類的空間不夠，溢出
操作大量的對象導緻堆記憶體空間已經用滿了，溢出
nio直接操作記憶體，記憶體過大導緻溢出

參考資料：

https://www.cnblogs.com/bingosblog/p/6661527.html

http://www.importnew.com/14604.html

2.3說說線程棧

這裡的線程棧應該指的是虛拟機棧吧…

JVM規範讓每個Java線程擁有自己的獨立的JVM棧，也就是Java方法的調用棧。

當方法調用的時候，會生成一個棧幀。棧幀是儲存在虛拟機棧中的，棧幀存儲了方法的局部變量表、操作數棧、動态連接配接和方法傳回位址等資訊

線程運作過程中，隻有一個棧幀是處于活躍狀态，稱為“目前活躍棧幀”，目前活動棧幀始終是虛拟機棧的棧頂元素。

通過jstack工具檢視線程狀态

參考資料：

http://wangwengcn.iteye.com/blog/1622195

https://www.cnblogs.com/Codenewbie/p/6184898.html

https://blog.csdn.net/u011734144/article/details/60965155

2.4JVM 年輕代到年老代的晉升過程的判斷條件是什麼呢？

部分對象會在From和To區域中複制來複制去,如此交換15次(由JVM參數MaxTenuringThreshold決定,這個參數預設是15),最終如果還是存活,就存入到老年代。
如果對象的大小大于Eden的二分之一會直接配置設定在old，如果old也配置設定不下，會做一次majorGC，如果小于eden的一半但是沒有足夠的空間，就進行minorgc也就是新生代GC。
minor gc後，survivor仍然放不下，則放到老年代
動态年齡判斷，大于等于某個年齡的對象超過了survivor空間一半，大于等于某個年齡的對象直接進入老年代

2.5JVM 出現 fullGC 很頻繁，怎麼去線上排查問題

這題就依據full GC的觸發條件來做：

如果有perm gen的話(jdk1.8就沒了)，要給perm gen配置設定空間，但沒有足夠的空間時，會觸發full gc。
- 是以看看是不是perm gen區的值設定得太小了。
System.gc()方法的調用
- 這個一般沒人去調用吧~~~
當統計得到的Minor GC晉升到舊生代的平均大小大于老年代的剩餘空間，則會觸發full gc(這就可以從多個角度上看了)
- 是不是頻繁建立了大對象(也有可能eden區設定過小)(大對象直接配置設定在老年代中，導緻老年代空間不足—>進而頻繁gc)
- 是不是老年代的空間設定過小了(Minor GC幾個對象就大于老年代的剩餘空間了)
  
  面試必問之JVM篇！！一、簡單聊聊JVM二、JVM面試題

2.6類加載為什麼要使用雙親委派模式，有沒有什麼場景是打破了這個模式？

雙親委托模型的重要用途是為了解決類載入過程中的安全性問題。

假設有一個開發者自己編寫了一個名為java.lang.Object的類，想借此欺騙JVM。現在他要使用自定義ClassLoader來加載自己編寫的java.lang.Object類。
然而幸運的是，雙親委托模型不會讓他成功。因為JVM會優先在Bootstrap ClassLoader的路徑下找到java.lang.Object類，并載入它

Java的類加載是否一定遵循雙親委托模型？

在實際開發中，我們可以通過自定義ClassLoader，并重寫父類的loadClass方法，來打破這一機制。

參考資料：

https://blog.csdn.net/markzy/article/details/53192993

2.7類的執行個體化順序

1．父類靜态成員和靜态初始化塊，按在代碼中出現的順序依次執行

2．子類靜态成員和靜态初始化塊，按在代碼中出現的順序依次執行

3．父類執行個體成員和執行個體初始化塊，按在代碼中出現的順序依次執行

4．父類構造方法

5．子類執行個體成員和執行個體初始化塊，按在代碼中出現的順序依次執行

6．子類構造方法

檢驗一下是不是真懂了：

class Dervied extends Base {


    private String name = "Java3y";

    public Dervied() {
        tellName();
        printName();
    }

    public void tellName() {
        System.out.println("Dervied tell name: " + name);
    }

    public void printName() {
        System.out.println("Dervied print name: " + name);
    }

    public static void main(String[] args) {

        new Dervied();
    }
}

class Base {

    private String name = "公衆号";

    public Base() {
        tellName();
        printName();
    }

    public void tellName() {
        System.out.println("Base tell name: " + name);
    }

    public void printName() {
        System.out.println("Base print name: " + name);
    }
}

輸出資料：

Dervied tell name: null
Dervied print name: null
Dervied tell name: Java3y
Dervied print name: Java3y

第一次做錯的同學點個贊，加個關注不過分吧(hahaha

2.8JVM垃圾回收機制，何時觸發MinorGC等操作

當young gen中的eden區配置設定滿的時候觸發MinorGC(新生代的空間不夠放的時候).

2.9JVM 中一次完整的 GC 流程（從 ygc 到 fgc）是怎樣的

這題不是很明白意思(水準有限…如果知道這題的意思可在評論區留言呀~~)

因為按我的了解：執行fgc是不會執行ygc的呀~~

因為按我的了解：執行fgc是不會執行ygc的呀~~

YGC和FGC是什麼

YGC ：對新生代堆進行gc。頻率比較高，因為大部分對象的存活壽命較短，在新生代裡被回收。性能耗費較小。
FGC ：全堆範圍的gc。預設堆空間使用到達80%(可調整)的時候會觸發fgc。以我們生産環境為例，一般比較少會觸發fgc，有時10天或一周左右會有一次。

什麼時候執行YGC和FGC

a.eden空間不足,執行 young gc
b.old空間不足，perm空間不足，調用方法System.gc() ，ygc時的悲觀政策, dump live的記憶體資訊時(jmap –dump:live)，都會執行full gc

2.10各種回收算法

GC最基礎的算法有三種：

标記 -清除算法
複制算法
标記-壓縮算法
我們常用的垃圾回收器一般都采用分代收集算法(其實就是組合上面的算法，不同的區域使用不同的算法)。

具體：

标記-清除算法，“标記-清除”（Mark-Sweep）算法，如它的名字一樣，算法分為“标記”和“清除”兩個階段：首先标記出所有需要回收的對象，在标記完成後統一回收掉所有被标記的對象。
複制算法，“複制”（Copying）的收集算法，它将可用記憶體按容量劃分為大小相等的兩塊，每次隻使用其中的一塊。當這一塊的記憶體用完了，就将還存活着的對象複制到另外一塊上面，然後再把已使用過的記憶體空間一次清理掉。
标記-壓縮算法，标記過程仍然與“标記-清除”算法一樣，但後續步驟不是直接對可回收對象進行清理，而是讓所有存活的對象都向一端移動，然後直接清理掉端邊界以外的記憶體
分代收集算法，“分代收集”（Generational Collection）算法，把Java堆分為新生代和老年代，這樣就可以根據各個年代的特點采用最适當的收集算法。

2.11各種回收器，各自優缺點，重點CMS、G1

圖來源于《深入了解Java虛拟機：JVM進階特效與最佳實作》，圖中兩個收集器之間有連線，說明它們可以配合使用.

面試必問之JVM篇！！一、簡單聊聊JVM二、JVM面試題

Serial收集器，串行收集器是最古老，最穩定以及效率高的收集器，但可能會産生較長的停頓，隻使用一個線程去回收。
ParNew收集器，ParNew收集器其實就是Serial收集器的多線程版本。
Parallel收集器，Parallel Scavenge收集器類似ParNew收集器，Parallel收集器更關注系統的吞吐量。
Parallel Old收集器，Parallel Old是Parallel Scavenge收集器的老年代版本，使用多線程“标記－整理”算法
CMS收集器，CMS（Concurrent Mark Sweep）收集器是一種以擷取最短回收停頓時間為目标的收集器。它需要消耗額外的CPU和記憶體資源，在CPU和記憶體資源緊張，CPU較少時，會加重系統負擔。CMS無法處理浮動垃圾。CMS的“标記-清除”算法，會導緻大量空間碎片的産生。
G1收集器，G1 (Garbage-First)是一款面向伺服器的垃圾收集器,主要針對配備多顆處理器及大容量記憶體的機器. 以極高機率滿足GC停頓時間要求的同時,還具備高吞吐量性能特征。

2.12stackoverflow錯誤，permgen space錯誤

stackoverflow錯誤主要出現：

在虛拟機棧中(線程請求的棧深度大于虛拟機棧鎖允許的最大深度)

permgen space錯誤(針對jdk之前1.7版本)：
在虛拟機棧中(線程請求的棧深度大于虛拟機棧鎖允許的最大深度)
permgen space錯誤(針對jdk之前1.7版本)：

三、總結

總的來說，JVM在初級的層面上還是偏理論多，可能要做具體的東西才會有更深的體會。這篇主要是入個門吧~

這篇文章懶懶散散也算把JVM比較重要的知識點理了一遍了，後面打算學學，寫寫SpringCloud的東西。

參考資料：

《深入了解Java虛拟機 JVM進階特性與最佳實踐（第二版）》
純潔的微笑jvm專欄：https://zhuanlan.zhihu.com/p/25511795
SexyCode jvm專欄：https://blog.csdn.net/column/details/15618.html?&page=1
javaGC流程：https://blog.csdn.net/yangyang12345555/article/details/79257171

面試必問之JVM篇！！一、簡單聊聊JVM二、JVM面試題

一、簡單聊聊JVM

1.1先來看看簡單的Java程式

1.2編譯過程

1.2.1編譯時期-文法糖

1.3JVM實作跨平台

1.4class檔案和JVM的恩怨情仇

1.4.1類的加載時機

1.4.2如何将類加載到jvm

1.4.2類加載詳細過程

1.4.3JIT即時編輯器

1.4.4回到例子中

1.5類加載完以後JVM幹了什麼？

1.5.1JVM的記憶體模型

1.5.2例子中的流程

1.6簡單聊聊各種常量池

1.6.1各個常量池的情況

1.6.2解析題目

1.7GC垃圾回收

1.7.1JVM垃圾回收簡單介紹

1.8JVM參數與調優

二、JVM面試題

2.1詳細jvm記憶體模型

2.2講講什麼情況下回出現記憶體溢出，記憶體洩漏？

2.3說說線程棧

2.4JVM 年輕代到年老代的晉升過程的判斷條件是什麼呢？

2.5JVM 出現 fullGC 很頻繁，怎麼去線上排查問題

2.6類加載為什麼要使用雙親委派模式，有沒有什麼場景是打破了這個模式？

2.7類的執行個體化順序

2.8JVM垃圾回收機制，何時觸發MinorGC等操作

2.9JVM 中一次完整的 GC 流程（從 ygc 到 fgc）是怎樣的

2.10各種回收算法

2.11各種回收器，各自優缺點，重點CMS、G1

2.12stackoverflow錯誤，permgen space錯誤

三、總結

繼續閱讀