學習JVM是如何從入門到放棄的？(修訂版)

  • 2019 年 10 月 6 日
  • 筆記

前言

只有光頭才能變強。 文本已收錄至我的GitHub倉庫，歡迎Star：https://github.com/ZhongFuCheng3y/3y

JVM在準備面試的時候就有看了，一直沒時間寫筆記。現在到了一家公司實習，閑的時候就寫寫，刷刷JVM部落格，刷刷電子書。

學習JVM的目的也很簡單：

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

(圖片來源：https://zhuanlan.zhihu.com/p/25511795,侵刪)

聲明：全文默認指的是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異常】
  • 可讀性和穩定性【在編寫集合的時候，就限定了類型】

了解泛型更多的知識：

  • https://segmentfault.com/a/1190000014120746

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默認有三種類載入器：

各個載入器的工作責任：

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

工作過程：

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

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

好處：

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

特別說明：

  • 類載入器在成功載入某個類之後，會把得到的 java.lang.Class類的實例快取起來。下次再請求載入該類的時候，類載入器會直接使用快取的類的實例，而不會嘗試再次載入。

1.4.2類載入詳細過程

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

  • 載入，查找並載入類的二進位數據，在Java堆中也創建一個java.lang.Class類的對象。
  • 連接，連接又包含三塊內容：驗證、準備、初始化。 - 1）驗證，文件格式、元數據、位元組碼、符號引用驗證； - 2）準備，為類的靜態變數分配記憶體，並將其初始化為默認值； - 3）解析，把類中的符號引用轉換為直接引用
  • 初始化，為類的靜態變數賦予正確的初始值。

1.4.3JIT即時編輯器

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

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

我們的JVM是這樣實現的：

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

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

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

  • 取樣
  • 計數器

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

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

1.4.4回到例子中

按我們程式來走，我們的 Java3yTest.class文件會被AppClassLoader載入器(因為ExtClassLoader和BootStrap載入器都不會載入它[雙親委派模型])載入到JVM中。

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

詳情參考：

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

擴展閱讀：

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

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

在類載入檢查通過後，接下來虛擬機將為新生對象分配記憶體。

1.5.1JVM的記憶體結構

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

  • 基於jdk1.8畫的JVM的記憶體結構--->我畫得比較細。

![圖片描述][1]

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

  • 堆：存放對象實例，幾乎所有的對象實例都在這裡分配記憶體
  • 虛擬機棧：虛擬機棧描述的是Java方法執行的記憶體結構：每個方法被執行的時候都會同時創建一個棧幀（Stack Frame）用於存儲局部變數表、操作棧、動態鏈接、方法出口等資訊
  • 本地方法棧：本地方法棧則是為虛擬機使用到的Native方法服務。
  • 方法區：存儲已被虛擬機載入的類元數據資訊(元空間)
  • 程式計數器：當前執行緒所執行的位元組碼的行號指示器

1.5.2例子中的流程

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

  • 1、通過 java.exe運行 Java3yTest.class，隨後被載入到JVM中，元空間存儲著類的資訊(包括類的名稱、方法資訊、欄位資訊..)。
  • 2、然後JVM找到Java3yTest的主函數入口(main)，為main函數創建棧幀，開始執行main函數
  • 3、main函數的第一條命令是 Java3yjava3y=newJava3y();就是讓JVM創建一個Java3y對象，但是這時候方法區中沒有Java3y類的資訊，所以JVM馬上載入Java3y類，把Java3y類的類型資訊放到方法區中(元空間)
  • 4、載入完Java3y類之後，Java虛擬機做的第一件事情就是在堆區中為一個新的Java3y實例分配記憶體, 然後調用構造函數初始化Java3y實例，這個Java3y實例持有著指向方法區的Java3y類的類型資訊（其中包含有方法表，java動態綁定的底層實現）的引用
  • 5、當使用 java3y.setName("Java3y");的時候，JVM根據java3y引用找到Java3y對象，然後根據Java3y對象持有的引用定位到方法區中Java3y類的類型資訊的方法表，獲得 setName()函數的位元組碼的地址
  • 6、為 setName()函數創建棧幀，開始運行 setName()函數

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

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

參考資料：

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

1.6簡單聊聊各種常量池

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

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

首先我是先閱讀了美團技術團隊的這篇文章：

  • 深入解析String#intern
    • https://tech.meituan.com/indepthunderstandingstringintern.html

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

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實例」來面試了吧
    • http://rednaxelafx.iteye.com/blog/774673#comments

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

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

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

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

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-------------");  }

第一句： Strings=newString("1");

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

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

很容易看到，兩條引用是不一樣的！所以返回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      }

第一句： Strings3=newString("1")+newString("1");注意：此時"11"對象並沒有在字元串常量池中保存引用。

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

第三句： Strings4="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各種的垃圾收集器啊。

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

參考資料：

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

二、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 記憶體共分為虛擬機棧、堆、方法區、程式計數器、本地方法棧五個部分。

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

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

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

參考資料：

  • https://www.cnblogs.com/paddix/p/5309550.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直接操作記憶體。

參考資料：

  • 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 年輕代到年老代的晉陞過程的判斷條件是什麼呢？

  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會優先在 BootstrapClassLoader的路徑下找到 java.lang.Object類，並載入它

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

  • 在實際開發中，我們可以通過自定義ClassLoader，並重寫父類的loadClass方法，來打破這一機制。
  • SPI就是打破了雙親委託機制的(SPI：服務提供發現)。SPI資料：
    • https://zhuanlan.zhihu.com/p/28909673 -https://www.cnblogs.com/huzi007/p/6679215.html - https://blog.csdn.net/sigangjun/article/details/79071850

參考資料：

  • 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）是怎樣的

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文件
  • 常量池記憶體溢出

三、總結

總的來說，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

Tags:

VirMach 便宜 VPS