面試官:說一下你們線上JVM是如何優化的?一不小心聊了2個小時!!

2020-09-23 16:00:49

面試官:說一下你們線上JVM是如何優化的?一不小心聊了2個小時!!

說一JVM的記憶體模型是什麼樣子的?什麼時候物件可以被收回?常見的垃圾回收器演演算法有哪些,各有什麼優劣?什麼時候物件會進入老年代?什麼是空間分配擔保策略?如何優化減少Full
GC?

面對這一大波JVM面試題,你真的Hold住嗎?

這裡把重要的知識點都寫出來了,不管是核心知識點也好還是面試題也好,讓大家對知識框架有個基本輪廓
同時也整理了283頁的PDF檔案,也是Java的核心知識點。
需要的朋友可以,點選這裡領取!!!,暗號是:CSDN

在這裡插入圖片描述

JVM的記憶體模型是什麼樣子的?

JVM記憶體模型可以大致可劃分為執行緒私有區域和共用區域,執行緒私有區域由虛擬機器器棧、本地方法棧、程式計數器組成,而共用區域由堆、後設資料空間(方法區)組成。在這裡插入圖片描述

再有人問你JVM的記憶體模型就回想下上面的圖,但是知道JVM的記憶體模型的樣子還是不行的,還要知道他們分別幹什麼的。

虛擬機器器棧/本地方法棧

當你碰到過StackOverflowException這個異常的時候,有沒有思考下為什麼會出現這樣的異常呢?答案就在虛擬機器器棧中,JVM會為每個方法生成棧幀然後將棧幀壓入虛擬機器器棧中。

舉個粟子:假設JVM引數-Xss設定為1m,如果某個方法裡面建立一個128kb的陣列,那這個方法在同一個執行緒中只能遞迴4次,再遞迴第五次的時候就會報StackOverflowException異常,因為虛擬機器器棧的大小隻有1m,每次遞迴都需要為方法在虛擬機器器棧中分配128kb的空間,很顯示到第五次的時候就空間不足了。
在這裡插入圖片描述

程式計數器

程式計數器是一個記錄著當前執行緒所執行的位元組碼的行號指示器。JVM的多執行緒是通過CPU時間片輪轉(即執行緒輪流切換並分配處理器執行時間)演演算法來實現的。也就是說,某個執行緒在執行過程中可能會因為時間片耗盡而被掛起,而另一個執行緒獲取到時間片開始執行。

簡單的說程式計數器的主要功能就是記錄著當前執行緒所執行的位元組碼的行號指示器。

方法區(後設資料區)

方法區儲存了類的後設資料資訊、靜態變數、常數等資料。
在這裡插入圖片描述

堆(heap)

平常大家使用new關鍵字建立的物件都會進入堆中,堆也是GC重點照顧的區域,堆會被劃分為:新生代、老年代,而新生代還會被進一步劃分為Eden區和Survivor區:
在這裡插入圖片描述

新生代中的Eden區和Survivor區,是根據JVM回收演演算法來的,只是現在大部分都是使用的分代回收演演算法,所以在介紹堆的時候會直接將新生代歸納為Eden區和Survivor區。

小結

JVM記憶體模型小結:

JVM記憶體模型劃分為執行緒私有區域和共用區域虛擬機器器棧/本地方法棧負責存放執行緒執行方法棧幀程式計數器用於記錄執行緒執行指令的位置方法區(後設資料區)儲存類的後設資料資訊、靜態變數、常數等資料堆(heap)使用new關鍵字建立的物件都會進入堆中,堆被劃分為新生代和老年代

什麼時候物件可以被收回?

JVM判斷物件回收有兩種方式:參照記數、GC Roots,參照記數比較簡單,JVM為每個物件維護一個參照計數,假設A物件參照計數為零說明沒有任務物件參照A物件,那A物件就可以被回收了,但是參照計數有個缺點就是無法解決迴圈參照的問題。

GC Roots通過一系列的名為GC Roots的物件作為起始點,從這些節點開始向下搜尋,搜尋過的路徑稱為參照鏈,當一個物件到GC Roots沒有任何參照鏈相連時,則證明物件是不可用的。

在Java中,可以作為GC Roots的物件包括下面幾種:

虛擬機器器棧中參照的物件;方法區中類靜態屬性參照的物件;方法區中的常數參照的物件;本地方法棧中JNI(即一般說的Native方法)的參照的物件;

小結

總的來說就是當一個物件通過GC Roots搜尋不到時,說明物件可以被回收了,但什麼時候回收還要看GC的心情!

常見的垃圾回收器演演算法有哪些,各有什麼優劣?

標記清除

這種演演算法分兩分:標記、清除兩個階段,
標記階段是從根集合(GC Root)開始掃描,每到達一個物件就會標記該物件為存活狀態,清除階段在掃描完成之後將沒有標記的物件給清除掉。

用一張圖說明:
在這裡插入圖片描述
這個演演算法有個缺陷就是會產生記憶體碎片,如上圖B被清除掉後會留下一塊記憶體區域,如果後面需要分配大的物件就會導致沒有連續的記憶體可供使用。

標記整理

標記整理就沒有記憶體碎片的問題了,也是從根集合(GC Root)開始掃描進行標記然後清除無用的物件,清除完成後它會整理記憶體。
在這裡插入圖片描述
這樣記憶體就是連續的了,但是產生的另外一個問題是:每次都得移動物件,因此成本很高。

複製演演算法

複製演演算法會將JVM推分成二等分,如果堆設定的是1g,那使用複製演演算法的時候堆就會有被劃分為兩塊區域各512m。給物件分配記憶體的時候總是使用其中的一塊來分配,分配滿了以後,GC就會進行標記,然後將存活的物件移動到另外一塊空白的區域,然後清除掉所有沒有存活的物件,這樣重複的處理,始終就會有一塊空白的區域沒有被合理的利用到。
在這裡插入圖片描述
兩塊區域交替使用,最大問題就是會導致空間的浪費,現在堆記憶體的使用率只有50%。

小結

JVM回收演演算法小結:

標記清除速度快,但是會產生記憶體碎片;標記整理解決了標記清除記憶體碎片的問題,但是每次都得移動物件,因此成本很高;複製演演算法沒有記憶體碎片也不需要移動物件,但是導致空間的浪費;

什麼時候物件會進入老年代?

新建立出來的物件一開始都會停留在新生代中,但隨著JVM的執行,有些存活的長的物件會慢慢的移動到老年代中。

根據物件年齡

JVM會給物件增加一個年齡(age)的計數器,物件每「熬過」一次GC,年齡就要+1,待物件到達設定的閾值(預設為15歲)就會被移移動到老年代,可通過-XX:MaxTenuringThreshold調整這個閾值。
在這裡插入圖片描述
一次Minor GC後,物件年齡就會+1,達到閾值的物件就移動到老年代,其他存活下來的物件會繼續保留在新生代中。

動態年齡判斷

根據物件年齡有另外一個策略也會讓物件進入老年代,不用等待15次GC之後進入老年代,他的大致規則就是,假如當前放物件的Survivor,一批物件的總大小大於這塊Survivor記憶體的50%,那麼大於這批物件年齡的物件,就可以直接進入老年代了。

在這裡插入圖片描述
如圖上的A、B、D、E這四個物件,假如Survivor 2是100m,如果A + B + D的記憶體大小超過50m,現在D的年齡是10,那E都會被移動到老年代。實際上這個計算邏輯是這樣的:年齡1 + 年齡2 + 年齡n的多個物件總和超過Survivor區的50%,那就會把年齡n以上的物件都放入老年代。

大物件直接進入老年代

如果設定了-XX:PretenureSizeThreshold這個引數,那麼如果你要建立的物件大於這個引數的值,比如分配一個超大的位元組陣列,此時就直接把這個大物件放入到老年代,不會經過新生代。

這麼做就可以避免大物件在新生代,屢次躲過GC,還得把他們來複制來複制去的,最後才進入老年代,這麼大的物件來回複製,是很耗費時間的。

什麼是空間分配擔保策略?

JVM在發生Minor GC之前,虛擬機器器會檢查老年代最大可用的連續空間是否大於新生代所有物件的總空間,如果大於,則此次Minor GC是安全的如果小於,則虛擬機器器會檢視HandlePromotionFailure設定項的值是否允許擔保失敗。如果HandlePromotionFailure=true,那麼會繼續檢查老年代最大可用連續空間是否大於歷次晉升到老年代的物件的平均大小,如果大於則嘗試進行一次Minor GC,但這次Minor GC依然是有風險的;如果小於或者HandlePromotionFailure=false,則改為進行一次Full GC。

在這裡插入圖片描述

如何優化減少Full GC?

將前面的一些問題總結下來,然後應用到線上,那JVM應該如何優化減少Full GC呢?以標準的4核8G機器為例說明,首先系統預留4G,其他4G按如下規則分配 :
•堆記憶體:3g新生代:1.5g
•新生代Eden區:1228m
•新生代Survivor區:153m
•方法區:256m
•虛擬機器器棧:1m/thread

設定引數如下:

 
-Xms3072m
-Xmx3072m
-Xmn1536m
-Xss=1m
-XX:PermSize=256m
-XX:MaxPermSize=256m
-XX:HandlePromotionFailure
-XX:SurvivorRatio=8
 

在這裡插入圖片描述
估算系統每秒佔用記憶體數量

在優化JVM之前,要先估算要系統每秒佔用的記憶體數量,如有個日活百萬的商場系統,每日下單量在20w左右,按照一天8個小時算,那訂單服務的每秒大概會有500個請求,然後粗略的估算下每個請求佔用多少記憶體,計算出每秒要花費多少記憶體。

假設是每秒500個請求,每個請求需要分配100k的空間,那1秒需要分配大約50m的記憶體。

計算下多長時間觸發一次Minor GC

按照之前的估算1秒需要分配大約50m的記憶體的話,Eden區的空間是1228m那平均每25秒就要執行一次Minor GC。

檢查下Survivor區是否足夠

按照上面的模型,每25秒就要執行一次Minor GC,GC執行期間並不能回收掉所有的新生代中的物件,那每秒50m那每次GC執行期間還會剩下大約100m無法回收的物件會進入Survivor區,但是別忘記JVM有動態年齡判斷機制,這樣設定下來Survivor的空間明顯小了一點,所以將新生代設定2048m,才能避免觸發動態年齡判斷:

-Xms3072m
-Xmx3072m
-Xmn2048m
...

大物件直接進入老年代

大物件一般是長期存活和使用的物件,一般來說設定1M的物件直接進入老年代,這樣避免大物件一直處於新生代中來回複製,所以加上PretenureSizeThreshold=1m引數。

 
...
-XX:PretenureSizeThreshold=1m
...

合理設定物件年齡閾值

Minor GC後預設躲過15次垃圾回收後自動升入老年代,按照我們的評估25秒觸發一次Minor GC,如果按照MaxTenuringThreshold引數的預設值,躲過15次GC後,應該是6分鐘之後的事了,結合當前業務場景這裡可以降低一點,讓那些本應該進入老年代的物件,儘快的進入老年代,避免複製成本和浪費新生代空間,從而導致新生代Survivor空間不足,引發Full GC。

...
-XX:MaxTenuringThreshold=6
...
 

總結

以上所述是給大家介紹的大廠面試經:說一下你們線上JVM是如何優化的,希望對大家有所幫助