面試官：說一下你們線上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是如何優化的，希望對大家有所幫助