Java知識歸納之JVM詳解
- WBOY轉載
- 2022-07-12 17:20:031755瀏覽
本篇文章為大家帶來了關於java的相關知識，其中主要整理了JVM的相關問題，包括了JVM記憶體區域劃分、JVM類別載入機制、VM的垃圾回收等等內容，下面一起來看一下，希望對大家有幫助。
推薦學習：《java影片教學》
一.JVM記憶體區域分割
JVM為什麼要劃分出這些區域呢?JVM內存是從操作系統裡面申請過來的,而JVM就根據功能需求將這些劃分成了一些小的模組,這樣一塊大的場地就可以劃分成一些小的模組,然後每個模組就負責自己的功能就可以了,那接下來看看這些區域的功能到底是什麼呢!
# 1.程式計數器
程式計數器是記憶體中最小的區域,這裡面主要保存了下一條要執行的指令的地址在哪裡(指令就是字節碼,一般程式要運行,JVM就需要把字節碼加載出來放到內存中,然後程式再把一條一條的指令從記憶體中取出來放到CPU上去執行,所以必須要記住當前執行到哪一條指令,以及下一條在哪裡,因為CPU不是只給一個進程提供服務的,是給所有的進程都提供服務,是並發式的執行程序的,又因為操作系統是以線程為單位進行調度執行的,所以每個線程都要有自己的執行位置,也就是每一個線程都需要有一個程序計數器來記錄位置!)
2.棧
棧裡面存放的主要是局部變數和方法呼叫資訊,只要涉及到新方法的呼叫,就會有"入棧"的操作,每執行完成一個方法,就會有"出棧"的操作,而且棧也是每個線程都有一份的
因此對於遞歸來說,一定要控制好遞歸條件,否則很有可能會出現棧溢出(StackOverflowException)異常的!
#3.堆
堆是記憶體中空間最大的區域,而且堆是每個進程只有一份的,進程中的多個執行緒公用一個堆,裡面主要存放著new出來的物件以及物件的成員變數,例如String s = new String()如果在方法裡面這裡的s就是局部變數是在堆疊上的,如果這個s是成員變數,就是在堆上的,而後面new String()是物件的本體,物件是在堆上的,這是容易混淆的地方,另外堆還有一個重要的點就是關於垃圾回收問題,這個後面再詳細介紹!
4.方法區
#方法區中存放的是"類別物件",平常寫的.java程式碼經過編譯器翻譯過後就會變成.class(二進位字節碼),然後.class就會被載入到記憶體中,也就被JVM構造成了類別物件(載入的過程就是稱為"類別載入"),而這些類別物件就會存放到方法區中,這裡面就具體描述了類別長啥樣(類別的名字,類別的成員及其成員名稱成員類型,類別的方法及其方法名稱方法類型,以及一些指令…另外類別物件裡面還存放了一個很重要的東西,就是靜態成員,一般被static修飾的成員就成為了類別屬性,而普通的方法被稱為實例屬性,這是有很大差異的)!
上面所介紹的是JVM中比較常見的區域,而一些JVM的記憶體區域劃分不一定是符合實際情況的,JVM在實現的過程中區域的劃分是不盡相同的,不同的廠商不同版本的JVM都是有可能存在差異的,不過對於我們普通的程式設計師而講,只要不是去實現JVM,那麼就不需要了解那麼深刻,講上面的幾個常見的區域加以了解就可以了!
二.JVM類別載入機制
類別載入其實是設計一個運行時環境的一個重要的功核心功能,這是非常重量級的,因此我這裡也就簡單介紹一下!
上述就是類別加載的具體過程,最後面的Using和Unloading就是使用的過程就不介紹了,就介紹一下前面的三個大的步驟:
1.Loading(載入)
在loading階段就會先找到對應的.class檔案,然後開啟並讀取(根據位元組流).class檔案,同時初步產生一個類別物件,這個和完成的類別載入(class Loading)是不相同的,不要搞混淆了!
class檔案的具體格式(如果要實作一個Java編譯器就得按照這樣的格式來構造,實作JVM就得按照這個格式來進行載入!):
觀察這個格式就可以看到.class檔案就把.java檔案中的核心資訊都表述進去了,只不過組織格式上發生了轉變,所以loading環節就會把讀取到的信息,初步填寫到類別物件中
2.Linking(連結)
連結一般就是建立好多個實體之間的聯繫
2.1.Verification(驗證)
Verification就是一個校驗的過程,主要是驗證讀到的內容是不是和規範中規定的格式完全匹配,如果發現讀到的資料格式不符合規範,就會類別載入失敗,並且拋出異常!
2.2.Preparation(準備)
Preparation階段是正式為定義的變數(靜態變數,就是static修飾的變數)分配記憶體並設定類別變數初始值的階段,就會給每個靜態變數分配記憶體,並且設定為0值!
# 2.3.Resolution(解析)
Resolution階段是Java虛擬機器將常數池內的符號引用替換為直接引用的過程,也就是初始化常數的過程,.class檔案中常數是集中放置的,每個常數會有一個編號,而在.class檔案中的結構體裡初始情況就只是記錄的編號,然後就可以根據這個編號找到對應的內容,再填充到類別物件中!
3.Initialization(初始化)
Initialization階段就是真正的對類別物件進行初始化(根據寫的程式碼),尤其是針對靜態成員
# 4.典型的面試題
class A {
public A(){
System.out.println("A的构造方法");
}
{
System.out.println("A的构造代码块");
}
static {
System.out.println("A的静态代码块");
}}class B extends A{
public B(){
System.out.println("B的构造方法");
}
{
System.out.println("B的构造代码块");
}
static {
System.out.println("B的静态代码块");
}}public class Test extends B{
public static void main(String[] args) {
new Test();
new Test();
}}可以自己先嘗試寫一下輸出的結果
做這樣的題就需要把握幾個大的原則:
類別載入階段就會進行靜態程式碼區塊的執行,要想建立實例,勢必要先進行類別載入
#靜態程式碼區塊只是類別載入階段執行一次,其他階段都不會再執行
建構方法和建構程式碼區塊每次實例化都會執行,而且建構程式碼區塊會在建構方法前面執行~~
#父類別執行在前,子類別執行在後!
程式是從main開始執行的,main的Test的方法,因此要執行main就需要先載入Test類別
只有涉及到這個類別了,類別裡面的東西才會被載入
输出结果: A的静态代码块 B的静态代码块 A的构造代码块 A的构造方法 B的构造代码块 B的构造方法 A的构造代码块 A的构造方法 B的构造代码块 B的构造方法
5.雙親委派模型
這個東西是類別載入中的一個環節,處於Loading階段(比較靠前的部分),雙親委派模型描述的就是JVM中的類別載入器,如何根據類別的全限定名(java.lang.String)找到.class檔案的過程。這裡的類別載入器是JVM專門提供的物件,主要負責進行類別載入,所以找檔案的過程也是由類別載入器來負責的,.class檔案可能放置的位置有很多,有的要放到JDK目錄裡面,有的放到專案目錄裡面,還有的在其他特定的位置裡面,因此JVM提供了多個類別載入器,每個類別載入器負責一個片區,而預設的類別載入器主要有3個:
BootStrapClassLoader:負責載入標準函式庫中的類別(String,ArrayList,Random,Scanner…)
ExtensionClassLoader:負責載入JDK擴充的類(現在很少用到)
ApplicationClassLoader:負責載入目前專案目錄中的類別
另外程式設計師還可以自訂類別載入器,來載入其他目錄中的類別,Tomcat就自訂了類別載入器,用來專門載入webapps裡面的.class
雙親委派模型就描述了這個找目錄的過程,也就是上述類別載入器是如何配合的
考慮找java.lang.String:
程式啟動,就會先進入ApplicationClassLoader類別載入器
ApplicationClassLoader類別載入器就會檢查下,它的父載入器是否已經載入過了,如果沒有,就呼叫父類別載入器ExtensionClassLoader
#ExtensionClassLoader類別載入器就會檢查下,它的父載入器是否已經載入過了,如果沒有,就呼叫父類別載入器BootStrapClassLoader
BootStrapClassLoader類別載入器也會檢查下,它的父載入器是否已經載入過了,然後發現沒有父親,於是就掃描自己負責的目錄
然後java.lang.String這個類別就在標準庫中能找到,然後後續就由BootStrapClassLoader載入器負責後續的載入過程,查找環節就結束了!
#可以考慮找自己寫的Test類別:
#程式啟動,就會先進入ApplicationClassLoader類別載入器
ApplicationClassLoader類別載入器就會檢查下方,它的父載入器是否已經載入過了,如果沒有,就呼叫父類別載入器ExtensionClassLoader
ExtensionClassLoader類載入器就會檢查下,它的父載入器是否已經載入過了,如果沒有,就呼叫父類別載入器BootStrapClassLoader
BootStrapClassLoader類別載入器也會檢查下,它的父載入器是否已經載入過了,然後發現沒有父親,於是就掃描自己負責的目錄,沒掃描到,就會回到子載入器中繼續掃描
ExtensionClassLoader掃描自己負責的目錄,也沒有掃描到,再回到子載入器中繼續掃描
ApplicationClassLoader也掃描自己負責的目錄,自己寫的類別就在自己的專案目錄下,因此就能找到,然後後續的類別載入就由ApplicationClassLoad完成,此時查找目錄的環節就結束了~~(另外如果ApplicationClassLoader也沒有找到們就會拋出ClassNotFoundException異常)
這套查找規則就稱為雙親委派模型,那為啥JVM要這樣設計呢,理由就是一旦程式設計師自己寫的類別和全限定類別名稱重複了,也能夠成功載入標準庫中的類別,而不是自己寫的類別!!!
另外如果是自訂的類別載入器,要不要遵守這個雙親委派模型呢?
答案是可以遵守也可以不遵守,主要看需求,例如Tomcat載入webapp中的類別,就沒有遵守,因為遵守了上面的類別載入器也是不可能找到的!
三.JVM的垃圾回收
JVM中的垃圾回收機制(GC),一般在寫程式碼的時候,常常就會涉及到申請記憶體,例如建立一個變數,new一個物件,呼叫一個方法,載入類別…而申請記憶體的時機一般是明確的(需要保存某個或某些資料就需要申請記憶體),但是釋放記憶體的時機,卻是不那麼清楚的,釋放的早了也不行(如果還是要使用的,結果已經被釋放了這就讓其無內存可用了,就讓這些數據"無處可去"),釋放的晚了也不行(釋放晚了,大量的囤積很有可能讓可用內存逐漸變少,很有可能會出現記憶體洩漏問題,就是無記憶體可以使用),因此記憶體的釋放要恰到好處才好!
而垃圾回收的本職是靠運行時環境額外做了很多的工作來完成釋放記憶體操作的,這讓程式設計師的心智負擔大大降低了,但是垃圾回收也是有劣勢的:①消耗額外的開銷(消耗資源耕更多了);②可能會影響程式的流暢運作(垃圾回收會經常引入STW問題(Stop The World))
垃圾回收的記憶體有哪些呢,是全部都要回收嘛?
當然不是了,就用上面的四個區域來說一下:
- 程式計數器:這個記憶體是固定大小的,不涉及到釋放,也就不需要GC了;
- #堆疊:當函數調用完畢,對應的棧幀也就自動釋放了,也是不需要GC的;
- 堆:這是最需要GC的內存,一般代碼中的大量的內存都在堆上;
而這三個區域到底哪些是需要釋放的,對於這種一部分在使用,一部分不再使用的物件,整體來說就是不釋放的,只有等到這個物件完全不再使用,才真正的進行釋放,因此在GC中就不會出現半個物件的情況,因此垃圾回收的基本單位就是物件,而不是位元組!- 方法區:類別物件,類別載入的,而只有進行到類別卸載的時候才需要進行釋放記憶體,而卸載操作是非常低頻的,因此幾乎就不涉及到GC!
下面就具體來看一下是怎麼回收的:
1.找垃圾/判定垃圾
而當下有兩個主流的方案:
1.1.基於引用計數
這不是Java中採取的方案,這是Python及其他語言的方案,因此這裡就簡單介紹一下,就不過多介紹了~
而引用計數的具體思路就是針對每個物件,都會額外引入一小塊記憶體,來保存這個物件有多少個引用指向它
而這樣的引用計數存在兩個缺陷:
- 空間利用率比較低!!!,每個new的物件都需要搭配一個計數器,假設一個計數器4個位元組,如果物件本身比較大(幾百個字節),那麼這個計數器就無所謂,而一旦這個物件本身就比較小(4個位元組),那麼再多出來4個位元組,就相當於空間利用率就浪費了一倍,因此空間利用率會比較低~
- 有循環引用的問題
因此使用引用計數也是會有大量的問題出現的,而想Python,PHP之類的語言也不是只使用引用計數器就完成GC的,也是配合了一些其他的機制來完成的!
1.2.基於可達性分析
可達性分析是Java所採取的方案,可達性分析是透過一些額外的線程,定期針對整個記憶體空間的物件進行掃描,有一些起始位置(GCRoots),然後就類似於深度優先遍歷一樣(可以想像成是一棵樹),把可以訪問到的對像都標記一邊(帶有標記的對象就是可達的對象),而沒有被標記的對象,就是不可達的對象,也就是垃圾,應該被釋放掉!
這裡的GCRoots(從這些位置開始遍歷):
- #堆疊上的局部變數;
- 常數池中的引用指向的物件;
- 方法區中的靜態成員指向的物件;
因此可達性分析的優點就是解決了引用計數的缺點:空間利用率低,循環引用;而可達性分析的缺點也很明顯:系統開銷大,遍歷一次可能比較慢~
因此找垃圾也是很簡單的,核心就是確認這個物件未來是否還會使用,看還有沒有引用指向它,應不應該釋放掉!
2.釋放垃圾
#既然已經明確了什麼是垃圾,接下來就要回收垃圾了,而回收垃圾有三種基本策略,下面來看一下!
2.1.標記-請除
這裡的標記就是可達性分析的過程,而清除就是釋放記憶體,假設上面是一塊記憶體,而打鉤的區域代表是垃圾,此時如果直接釋放掉,雖然記憶體是還給系統了,但是釋放掉的記憶體是離散的,不是連續的,而這樣帶來的問題就是"內存碎片",空閒的內存可能會有很多,假設加起來一共是1G,而此時想要申請500MB的空間,按理是可以申請到的,但這裡是有可能申請失敗的(因為要申請的500MB是連續的內存,每次申請的內存都是連續的內存空間,而這裡的1G可能是多個碎片加起來的),因此這樣的問題其實是非常影響程式運行的
2.2.複製演算法
由於上面的標記-清除策略可能會帶來記憶體碎片的問題,因此引入了複製演算法來解決這一問題
上面是一塊記憶體,複製演算法的策略就是記憶體使用一半,丟一半,不全部使用,在使用的一般裡面把不是垃圾的拷貝到另一半(這個拷貝是JVM內部處理好的,不用糾結),然後把前面使用的全部記憶體都釋放掉,這樣記憶體碎片的問題就迎刃而解了!
所以複製演算法就有兩個很大的問題:
- 記憶體空間利用率低(只使用了一般的記憶體);
- 如果要保留的物件多,要釋放的物件少,那麼複製的開銷就很大;
2.3.標記-整理
這又是針對複製演算法,再進一步做出改進!
標記整理的策略就是將不是垃圾的記憶體整理到一起,然後釋放掉後面的全部記憶體,就類似於順序表刪除中間元素的操作一樣,有一個搬運的過程!
這個方案空間利用率是高了,但是仍然沒有辦法解決複製/搬運元素開銷大的問題!
上述的三種方案,雖然能夠解決問題,但是都有各自的缺陷,因此實際上JVM中的實現,會把多種方案結合起來使用,也就是"分代回收"!!!
2.4分代回收
這裡的分代就是針對對象來進行分類(根據對象的"年齡"進行分類,而這裡的年齡表示一個對象熬過一輪GC的掃描,就稱"長了一歲"),而針對不同年齡的對象,就採取不同的方案!!!
# 這就是整個分代回收的過程!
3.垃圾回收器
上面的找垃圾和釋放垃圾都只是演算法的思想,並不是真正的落地實現的過程,而真正實現上述演算法模組的是"垃圾回收器",以下來介紹一些特定的垃圾回收器:
3.1.Serial收集器和Serial Old收集器
Serial收集器是提供給新生代的垃圾回收器,Serial Old收集器是給老年代提供的垃圾回收器,這兩個收集器是串行收集的,而且在進行垃圾的掃描和釋放的時候,業務線程要停止工作,所以這樣的方式掃描的滿,釋放的也慢,而且也能產生嚴重的STW!
3.2.ParNew收集器,Parallel Scavenge收集器和Parallel Old收集器
ParNew收集器,Parallel Scavenge收集器都是提供給新生代的,Parallel Scavenge收集器比起ParNew收集器加了一些參數,可以控制STW的時間,就是多了一些更強的功能,Parallel Old收集器是提供給老年代的,這三個收集器都是並行收集的,就是引入了多線程的方式來解決掃描垃圾和釋放垃圾的功能!
上面的這幾個回收器都是歷史遺留下來的,也就是比較老的垃圾回收方式,另外再介紹兩個更新的垃圾回收器!
3.3.CMS收集器
CMS收集器設計的比較巧妙,其設計的初衷是盡可能讓STW時間短,Java8使用的正是CMS收集器,下面簡單介紹一下CMS收集器的過程:
- 初始標記:速度很快,會引起短暫的STW(只是找到GCRoots);
- 並發標記:速度很快,但是可以和業務線程並發執行,不會產生STW;
- 重新標記:在2業務代碼可能會影響並發標記的結果(業務線程在執行,就有可能產生新的垃圾),因此這一步就是針對2的結果進行微調,雖然會引起STW,但只是微調,速度很快;
上面三步都是基於可達性分析! - 回收記憶體:也是和業務執行緒並發執行,不會產生STW,這是基於標記整理;
#3.4.G1收集器
G1收集器是唯一一款全區域的垃圾回收器,從Java11開始使用的就是G1收集器,這個收集器是把整個內存,分成了很多小的區域Region,給這些Region進行了不同的標記,有的Region放新生代對象,有的Region放老年代對象,然後掃描的時候,就一次掃描若干個Region(不追求一輪GC就掃描完,需要分多次掃描),這樣對於業務代碼的影響也是最小的,
這兩個新的收集器的核心思想就是化整為零,G1當下可以優化到讓STW停頓時間小於1ms,這是完全可以接收的!上面就是關於JVM的一些學習了,這裡的收集器主要還是了解為主,主要還是上面的垃圾回收思想很重要!!!
#推薦學習：《java視頻教程》
以上是Java知識歸納之JVM詳解的詳細內容。更多資訊請關注PHP中文網其他相關文章！