學習JVM是如何從入門到放棄的?
前言
只有光頭才能變強
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源碼編譯器(上述所說的java.exe)來完成,流程圖如下所示:
Java源碼編譯由以下三個過程組成:
- 分析和輸入到符號表
- 註解處理
- 語義分析和生成class文件
1.2.1編譯時期-語法糖
語法糖可以看做是編譯器實現的一些“小把戲”,這些“小把戲”可能會使得效率“大提升”。
最值得說明的就是泛型了,這個語法糖可以說我們是經常會使用到的!
- 泛型只會在Java源碼中存在,編譯過後會被替換為原來的原生類型(Raw Type,也稱為裸類型)了。這個過程也被稱為:泛型擦除
有了泛型這顆語法糖以後:
- 代碼更加簡潔【不用強制轉換】
- 程序更加健壯【只要編譯時期沒有警告,那麽運行時期就不會出現ClassCastException異常】
- 可讀性和穩定性【在編寫集合的時候,就限定了類型】
了解泛型更多的知識:
- https://segmentfault.com/a/1190000014120746
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
工作過程:
- 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中
詳情參考:
- 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例子中的流程
我來宏觀簡述一下我們的例子中的工作流程:
- 1、通過
java.exe
運行Java3yTest.class
,隨後被加載到JVM中,元空間存儲著類的信息(包括類的名稱、方法信息、字段信息..)。 - 2、然後JVM找到Java3yTest的主函數入口(main),為main函數創建棧幀,開始執行main函數
- 3、main函數的第一條命令是
Java3y java3y = new Java3y();
就是讓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
參考資料:
- 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
字符串常量池只存儲引用,不存儲內容!
再來看一下我們的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參數設置、分析
二、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 年輕代到年老代的晉升過程的判斷條件是什麽呢?
- 部分對象會在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幾個對象就大於老年代的剩余空間了)
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
- 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)是怎樣的
這題不是很明白意思(水平有限...如果知道這題的意思可在評論區留言呀~~)
- 因為按我的理解:執行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文件
- 常量池內存溢出
三、總結
總的來說,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
如果文章有錯的地方歡迎指正,大家互相交流。習慣在微信看技術文章,想要獲取更多的Java資源的同學,可以關註微信公眾號:Java3y。為了大家方便,剛新建了一下qq群:742919422,大家也可以去交流交流。謝謝支持了!希望能多介紹給其他有需要的朋友
文章的目錄導航:
- https://zhongfucheng.bitcron.com/post/shou-ji/wen-zhang-dao-hang
學習JVM是如何從入門到放棄的?