面試必問之JVM篇

前言

只有光頭才能變強

JVM在準備面試的時候就有看了，一直沒時間寫筆記。如今到了一家公司實習，閒的時候就寫寫，刷刷JVM博客，刷刷電子書。

學習JVM的目的也很簡單：

• 可以知道JVM是什麼，爲咱們幹了什麼，具體是怎麼幹的。可以理解到一些初學時不懂的東西
• 在面試的時候有談資
• 能裝逼

聲明：全文默認指的是HotSpot VM

1、簡單聊聊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源碼編譯器(上述所說的java.exe)來完成，流程圖以下所示：

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

• 分析和輸入到符號表
• 註解處理
• 語義分析和生成class文件

1.2.1編譯時期-語法糖

語法糖能夠看作是編譯器實現的一些「小把戲」，這些「小把戲」可能會使得效率「大提高」。

最值得說明的就是泛型了，這個語法糖能夠說咱們是常常會使用到的！

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

有了泛型這顆語法糖之後：

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

瞭解泛型更多的知識：

• http://www.javashuo.com/article/p-rwrpoigi-bv.html

1.3JVM實現跨平臺

至此，咱們經過java.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默認有三種類加載器：

各個加載器的工做責任：

• 1）Bootstrap ClassLoader：負責加載$JAVA_HOME中jre/lib/rt.jar裏全部的class，由C++實現，不是ClassLoader子類
• 2）Extension ClassLoader：負責加載java平臺中擴展功能的一些jar包，包括$JAVA_HOME中jre/lib/*.jar或-Djava.ext.dirs指定目錄下的jar包
• 3）App ClassLoader：負責記載classpath中指定的jar包及目錄中class

工做過程：

• 一、當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類的對象。
• 鏈接，鏈接又包含三塊內容：驗證、準備、初始化。

    - 1）驗證，文件格式、元數據、字節碼、符號引用驗證；     - 2）準備，爲類的靜態變量分配內存，並將其初始化爲默認值；     - 3）解析，把類中的符號引用轉換爲直接引用

• 初始化，爲類的靜態變量賦予正確的初始值。

1.4.3JIT即時編輯器

通常咱們可能會想：JVM在加載了這些class文件之後，針對這些字節碼，逐條取出，逐條執行-->解析器解析。

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

咱們的JVM是這樣實現的：

• 就是把這些Java字節碼從新編譯優化，生成機器碼，讓CPU直接執行。這樣編出來的代碼效率會更高。
• 編譯也是要花費時間的，咱們通常對熱點代碼作編譯，非熱點代碼直接解析就行了。

熱點代碼解釋：1、屢次調用的方法。2、屢次執行的循環體

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

• 採樣
• 計數器

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

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

1.4.4回到例子中

按咱們程序來走，咱們的Java3yTest.class文件會被AppClassLoader加載器(由於ExtClassLoader和BootStrap加載器都不會加載它[雙親委派模型])加載到JVM中。

隨後發現了要使用Java3y這個類，咱們的Java3y.class文件會被AppClassLoader加載器(由於ExtClassLoader和BootStrap加載器都不會加載它[雙親委派模型])加載到JVM中

詳情參考：

• https://www.mrsssswan.club/2018/06/30/jvm-start1/---淺解JVM加載class文件
• https://zhuanlan.zhihu.com/p/28476709---JVM雜談之JIT

擴展閱讀：

• https://www.ibm.com/developerworks/cn/java/j-lo-classloader/---深刻探討 Java 類加載器
• https://www.ibm.com/developerworks/cn/java/j-lo-just-in-time/---深刻淺出 JIT 編譯器
• https://www.zhihu.com/question/46719811---Java 類加載器（ClassLoader）的實際使用場景有哪些？

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

在類加載檢查經過後，接下來虛擬機將爲新生對象分配內存。

1.5.1JVM的內存模型

首先咱們來了解一下JVM的內存模型的怎麼樣的：

• 基於jdk1.8畫的JVM的內存模型--->我畫得比較細。

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

• 堆：存放對象實例，幾乎全部的對象實例都在這裏分配內存
• 虛擬機棧：虛擬機棧描述的是Java方法執行的內存模型：每一個方法被執行的時候都會同時建立一個棧幀（Stack Frame）用於存儲局部變量表、操做棧、動態連接、方法出口等信息
• 本地方法棧：本地方法棧則是爲虛擬機使用到的Native方法服務。
• 方法區：存儲已被虛擬機加載的類元數據信息(元空間)
• 程序計數器：當前線程所執行的字節碼的行號指示器

1.5.2例子中的流程

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

• 一、經過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對象持有的引用定位到方法區中Java3y類的類型信息的方法表，得到setName()函數的字節碼的地址
• 六、爲setName()函數建立棧幀，開始運行setName()函數

從微觀上其實還作了不少東西，正如上面所說的類加載過程（加載-->鏈接(驗證，準備，解析)-->初始化)，在類加載完以後jvm爲其分配內存(分配內存中也作了很是多的事)。因爲這些步驟並非一步一步往下走，會有不少的「混沌bootstrap」的過程，因此很難描述清楚。

• 擴展閱讀(先有Class對象仍是先有Object)：https://www.zhihu.com/question/30301819

參考資料：

• http://www.cnblogs.com/qiumingcheng/p/5398610.html---Java程序編譯和運行的過程
• https://zhuanlan.zhihu.com/p/25713880---Java JVM 運行機制及基本原理

1.6簡單聊聊各類常量池

在寫這篇文章的時候，本來覺得我對String s = "aaa";相似這些題目已是不成問題了，直到我遇到了String.intern()這樣的方法與諸如String s1 = new String("1") + new String("2"); 混合一塊兒用的時候

• 我發現，我仍是太年輕了。

首先我是先閱讀了美團技術團隊的這篇文章：https://tech.meituan.com/in_depth_understanding_string_intern.html---深刻解析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大以前寫過的文章：

• http://rednaxelafx.iteye.com/blog/774673#comments---請別再拿「String s = new String("xyz");建立了多少個String實例」來面試了吧

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

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

• https://www.zhihu.com/question/55994121---Java 中new String("字面量") 中 "字面量" 是什麼時候進入字符串常量池的?

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

1.6.1各個常量池的狀況

針對於jdk1.7以後：

• 常量池位於堆中
• 運行時常量池位於堆中
• 字符串常量池位於堆中

常量池存儲的是：

• 字面量(Literal)：文本字符串等---->用雙引號引發來的字符串字面量都會進這裏面
• 符號引用(Symbolic References)

    - 類和接口的全限定名(Full Qualified Name)     - 字段的名稱和描述符(Descriptor)     - 方法的名稱和描述符

常量池（Constant Pool Table），用於存放編譯期生成的各類字面量和符號引用，這部份內容將在類加載後進入方法區的運行時常量池中存放--->來源：深刻理解Java虛擬機 JVM高級特性與最佳實踐（第二版）

如今咱們的運行時常量池只是換了一個位置(本來來方法區，如今在堆中),但能夠明確的是：類加載後，常量池中的數據會在運行時常量池中存放！

HotSpot VM裏，記錄interned string的一個全局表叫作StringTable，它本質上就是個HashSet<String>。注意它只存儲對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) {

    //  1.1在堆中建立"1"字符串對象
    //  1.2字符串常量池引用"1"字符串對象
    //  1.3s引用指向堆中"1"字符串對象
    String s = new String("1");

    // 2. 發現字符串常量池中已經存在"1"字符串對象，直接返回字符串常量池中對堆的引用(但沒有接收)-->s引用仍是指向着堆中的對象
    s.intern();

    // 3. 發現字符串常量池已經保存了該對象的引用了，直接返回字符串常量池對堆中字符串的引用
    String s2 = "1";

    // 4. s指向的是堆中對象的引用，s2指向的是在字符串常量池對堆中對象的引用
    System.out.println(s == s2);// false
    System.out.println("-----------關注公衆號：Java3y-------------");
}

第一句：String s = new String("1");

第二句：s.intern();發現字符串常量池中已經存在"1"字符串對象，直接返回字符串常量池中對堆的引用(但沒有接收)-->此時s引用仍是指向着堆中的對象

第三句：String s2 = "1";發現字符串常量池已經保存了該對象的引用了，直接返回字符串常量池對堆中字符串的引用

很容易看到，兩條引用是不同的！因此返回false。

---

public static void main(String[] args) {

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

        // 1. 在堆中首先建立了兩個「1」對象
        // 1.1 +號運算符解析成stringBuilder，最後toString()，最終在堆中建立出"11"對象
        // 1.2 注意：此時"11"對象並無在字符串常量池中保存引用
        String s3 = new String("1") + new String("1");

        // 2. 發現"11"對象並無在字符串常量池中存在，因而將"11"對象在字符串常量池中保存當前字符串的引用，並返回當前字符串的引用
        s3.intern();

        // 3. 發現字符串常量池已經存在引用了，直接返回(拿到的也是與s3相同指向的引用)
        String s4 = "11";
        System.out.println(s3 == s4); // true
    }

第一句：String s3 = new String("1") + new String("1");在堆中首先建立了兩個「1」對象。 +號運算符解析成stringBuilder，最後toString()，最終在堆中建立出"11"對象。注意：此時"11"對象並無在字符串常量池中保存引用。

第二句：s3.intern();發現"11"對象並無在字符串常量池中，因而將"11"對象在字符串常量池中保存當前字符串的引用，並返回當前字符串的引用(但沒有接收)

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

根據上述所說的：最後會返回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使用的都是準確式GC。JVM是使用一組稱爲OopMap的數據結構，來存儲全部的對象引用(這樣就不用遍歷整個內存去查找了，時間換空間)。 而且不會將全部的指令都生成OopMap，只會在安全點上生成OopMap，在安全區域上開始GC。

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

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

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

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

1.8JVM參數與調優

不少作過JavaWeb項目(ssh/ssm)這樣的同窗可能都會遇到過OutOfMemory這樣的錯誤。通常解決起來也很方便，在啓動的時候加個參數就好了。

上面也說了不少關於JVM的東西--->JVM對內存的劃分啊，JVM各類的垃圾收集器啊。

內存的分配的大小啊，使用哪一個收集器啊，這些均可以由咱們根據需求，現實狀況來指定的，這裏就不詳細說了，等真正用到的時候纔回來填坑吧~~~~

參考資料：

• http://www.cnblogs.com/redcreen/archive/2011/05/04/2037057.html---JVM系列三:JVM參數設置、分析

2、JVM面試題

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

• 一、詳細jvm內存模型
• 二、講講什麼狀況下回出現內存溢出，內存泄漏？
• 三、說說Java線程棧
• 四、JVM 年輕代到年老代的晉升過程的判斷條件是什麼呢？
• 五、JVM 出現 fullGC 很頻繁，怎麼去線上排查問題？
• 六、類加載爲何要使用雙親委派模式，有沒有什麼場景是打破了這個模式？
• 七、類的實例化順序
• 八、JVM垃圾回收機制，什麼時候觸發MinorGC等操做
• 九、JVM 中一次完整的 GC 流程（從 ygc 到 fgc）是怎樣的
• 十、各類回收器，各自優缺點，重點CMS、G1
• 十一、各類回收算法
• 十二、OOM錯誤，stackoverflow錯誤，permgen space錯誤

題目來源：

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

2.1詳細jvm內存模型

根據 JVM 規範，JVM 內存共分爲虛擬機棧、堆、方法區、程序計數器、本地方法棧五個部分。

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

• 本來永久代存儲的數據：符號引用(Symbols)轉移到了native heap；字面量(interned strings)轉移到了java heap；類的靜態變量(class statics)轉移到了java heap
• Metaspace（元空間）存儲的是類的元數據信息（metadata）
• 元空間的本質和永久代相似，都是對JVM規範中方法區的實現。不過元空間與永久代之間最大的區別在於：元空間並不在虛擬機中，而是使用本地內存。
• 替換的好處：1、字符串存在永久代中，容易出現性能問題和內存溢出。2、永久代會爲 GC 帶來沒必要要的複雜度，而且回收效率偏低

圖片來源：http://www.javashuo.com/article/p-smjktxqf-nt.html

參考資料：

• http://www.javashuo.com/article/p-fdtgegxz-hk.html

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直接操做內存，內存過大致使溢出

解決：

• 查看程序是否存在內存泄漏的問題
• 設置參數加大空間
• 代碼中是否存在死循環或循環產生過多重複的對象實體、
• 查看是否使用了nio直接操做內存。

參考資料：

• http://www.javashuo.com/article/p-prnovryf-he.html
• http://www.importnew.com/14604.html

2.3說說線程棧

這裏的線程棧應該指的是虛擬機棧吧...

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

當方法調用的時候，會生成一個棧幀。棧幀是保存在虛擬機棧中的，棧幀存儲了方法的局部變量表、操做數棧、動態鏈接和方法返回地址等信息

線程運行過程當中，只有一個棧幀是處於活躍狀態，稱爲「當前活躍棧幀」，當前活動棧幀始終是虛擬機棧的棧頂元素。

經過jstack工具查看線程狀態

參考資料：

• http://wangwengcn.iteye.com/blog/1622195
• http://www.javashuo.com/article/p-cljjbmft-ha.html
• http://www.javashuo.com/article/p-vmnpujqh-b.html

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

1. 部分對象會在From和To區域中複製來複制去,如此交換15次(由JVM參數MaxTenuringThreshold決定,這個參數默認是15),最終若是仍是存活,就存入到老年代。
2. 若是對象的大小大於Eden的二分之一會直接分配在old，若是old也分配不下，會作一次majorGC，若是小於eden的一半可是沒有足夠的空間，就進行minorgc也就是新生代GC。
3. minor gc後，survivor仍然放不下，則放到老年代
4. 動態年齡判斷 ，大於等於某個年齡的對象超過了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幾個對象就大於老年代的剩餘空間了)

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

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

• 假設有一個開發者本身編寫了一個名爲java.lang.Object的類，想借此欺騙JVM。如今他要使用自定義ClassLoader來加載本身編寫的java.lang.Object類。
• 然而幸運的是，雙親委託模型不會讓他成功。由於JVM會優先在Bootstrap ClassLoader的路徑下找到java.lang.Object類，並載入它

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

• 在實際開發中，咱們能夠經過自定義ClassLoader，並重寫父類的loadClass方法，來打破這一機制。
• SPI就是打破了雙親委託機制的(SPI：服務提供發現)。SPI資料：

    - https://zhuanlan.zhihu.com/p/28909673     - http://www.javashuo.com/article/p-mbtipyvc-gx.html     - http://www.javashuo.com/article/p-mnszpkje-ct.html

參考資料：

• http://www.javashuo.com/article/p-bqsbztql-gc.html

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的呀~~

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高級特效與最佳實現》，圖中兩個收集器之間有連線，說明它們能夠配合使用.

• 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版本)：

• 大量加載class文件
• 常量池內存溢出

3、總結

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

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