線上JVM是怎么優(yōu)化的

本篇內(nèi)容介紹了“線上JVM是怎么優(yōu)化的”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

JVM的內(nèi)存模型是什么樣子的？

JVM內(nèi)存模型可以大致可劃分為線程私有區(qū)域和共享區(qū)域，線程私有區(qū)域由虛擬機棧、本地方法棧、程序計數(shù)器組成，而共享區(qū)域由堆、元數(shù)據(jù)空間（方法區(qū)）組成。

再有人問你JVM的內(nèi)存模型就回想下上面的圖，但是知道JVM的內(nèi)存模型的樣子還是不行的，還要知道他們分別干什么的。

虛擬機棧/本地方法棧

當你碰到過StackOverflowException這個異常的時候，有沒有思考下為什么會出現(xiàn)這樣的異常呢？答案就在虛擬機棧中，JVM會為每個方法生成棧幀然后將棧幀壓入虛擬機棧中。

舉個粟子：假設JVM參數(shù)-Xss設置為1m，如果某個方法里面創(chuàng)建一個128kb的數(shù)組，那這個方法在同一個線程中只能遞歸4次，再遞歸第五次的時候就會報StackOverflowException異常，因為虛擬機棧的大小只有1m，每次遞歸都需要為方法在虛擬機棧中分配128kb的空間，很顯示到第五次的時候就空間不足了。

程序計數(shù)器

程序計數(shù)器是一個記錄著當前線程所執(zhí)行的字節(jié)碼的行號指示器。JVM的多線程是通過CPU時間片輪轉（即線程輪流切換并分配處理器執(zhí)行時間）算法來實現(xiàn)的。也就是說，某個線程在執(zhí)行過程中可能會因為時間片耗盡而被掛起，而另一個線程獲取到時間片開始執(zhí)行。

簡單的說程序計數(shù)器的主要功能就是記錄著當前線程所執(zhí)行的字節(jié)碼的行號指示器。

方法區(qū)（元數(shù)據(jù)區(qū)）

方法區(qū)存儲了類的元數(shù)據(jù)信息、靜態(tài)變量、常量等數(shù)據(jù)。

堆（heap)

平常大家使用new關鍵字創(chuàng)建的對象都會進入堆中，堆也是GC重點照顧的區(qū)域，堆會被劃分為：新生代、老年代，而新生代還會被進一步劃分為Eden區(qū)和Survivor區(qū)：

新生代中的Eden區(qū)和Survivor區(qū)，是根據(jù)JVM回收算法來的，只是現(xiàn)在大部分都是使用的分代回收算法，所以在介紹堆的時候會直接將新生代歸納為Eden區(qū)和Survivor區(qū)。

小結

JVM內(nèi)存模型小結：

• JVM內(nèi)存模型劃分為線程私有區(qū)域和共享區(qū)域

• 虛擬機棧/本地方法棧負責存放線程執(zhí)行方法棧幀

• 程序計數(shù)器用于記錄線程執(zhí)行指令的位置

• 方法區(qū)（元數(shù)據(jù)區(qū)）存儲類的元數(shù)據(jù)信息、靜態(tài)變量、常量等數(shù)據(jù)

• 堆（heap)使用new關鍵字創(chuàng)建的對象都會進入堆中，堆被劃分為新生代和老年代

什么時候對象可以被收回？

JVM判斷對象回收有兩種方式：引用記數(shù)、GC Roots，引用記數(shù)比較簡單，JVM為每個對象維護一個引用計數(shù)，假設A對象引用計數(shù)為零說明沒有任務對象引用A對象，那A對象就可以被回收了，但是引用計數(shù)有個缺點就是無法解決循環(huán)引用的問題。

GC Roots通過一系列的名為GC Roots的對象作為起始點，從這些節(jié)點開始向下搜索，搜索過的路徑稱為引用鏈，當一個對象到GC Roots沒有任何引用鏈相連時，則證明對象是不可用的。

在Java中，可以作為GC Roots的對象包括下面幾種：

• 虛擬機棧中引用的對象；

• 方法區(qū)中類靜態(tài)屬性引用的對象；

• 方法區(qū)中的常量引用的對象；

• 本地方法棧中JNI（即一般說的Native方法）的引用的對象；

小結

總的來說就是當一個對象通過GC Roots搜索不到時，說明對象可以被回收了，但什么時候回收還要看GC的心情！

常見的垃圾回收器算法有哪些，各有什么優(yōu)劣？

標記清除

這種算法分兩分：標記、清除兩個階段，
標記階段是從根集合（GC Root)開始掃描，每到達一個對象就會標記該對象為存活狀態(tài)，清除階段在掃描完成之后將沒有標記的對象給清除掉。

這個算法有個缺陷就是會產(chǎn)生內(nèi)存碎片，如上圖B被清除掉后會留下一塊內(nèi)存區(qū)域，如果后面需要分配大的對象就會導致沒有連續(xù)的內(nèi)存可供使用。

標記整理

標記整理就沒有內(nèi)存碎片的問題了，也是從根集合（GC Root)開始掃描進行標記然后清除無用的對象，清除完成后它會整理內(nèi)存。

這樣內(nèi)存就是連續(xù)的了，但是產(chǎn)生的另外一個問題是：每次都得移動對象，因此成本很高。

復制算法

復制算法會將JVM推分成二等分，如果堆設置的是1g，那使用復制算法的時候堆就會有被劃分為兩塊區(qū)域各512m。給對象分配內(nèi)存的時候總是使用其中的一塊來分配，分配滿了以后，GC就會進行標記，然后將存活的對象移動到另外一塊空白的區(qū)域，然后清除掉所有沒有存活的對象，這樣重復的處理，始終就會有一塊空白的區(qū)域沒有被合理的利用到。

兩塊區(qū)域交替使用，最大問題就是會導致空間的浪費，現(xiàn)在堆內(nèi)存的使用率只有50%。

小結

JVM回收算法小結：

• 標記清除速度快，但是會產(chǎn)生內(nèi)存碎片；

• 標記整理解決了標記清除內(nèi)存碎片的問題，但是每次都得移動對象，因此成本很高；

• 復制算法沒有內(nèi)存碎片也不需要移動對象，但是導致空間的浪費；

什么時候對象會進入老年代？

新創(chuàng)建出來的對象一開始都會停留在新生代中，但隨著JVM的運行，有些存活的長的對象會慢慢的移動到老年代中。

根據(jù)對象年齡

JVM會給對象增加一個年齡（age）的計數(shù)器，對象每“熬過”一次GC，年齡就要+1，待對象到達設置的閾值（默認為15歲）就會被移移動到老年代，可通過-XX:MaxTenuringThreshold調整這個閾值。

一次Minor GC后，對象年齡就會+1，達到閾值的對象就移動到老年代，其他存活下來的對象會繼續(xù)保留在新生代中。

動態(tài)年齡判斷

根據(jù)對象年齡有另外一個策略也會讓對象進入老年代，不用等待15次GC之后進入老年代，他的大致規(guī)則就是，假如當前放對象的Survivor，一批對象的總大小大于這塊Survivor內(nèi)存的50%，那么大于這批對象年齡的對象，就可以直接進入老年代了。

假如Survivor 2是100m，如果A + B + D的內(nèi)存大小超過50m，現(xiàn)在D的年齡是10，那E都會被移動到老年代。實際上這個計算邏輯是這樣的：年齡1 + 年齡2 + 年齡n的多個對象總和超過Survivor區(qū)的50%，那就會把年齡n以上的對象都放入老年代。

大對象直接進入老年代

如果設置了-XX:PretenureSizeThreshold這個參數(shù)，那么如果你要創(chuàng)建的對象大于這個參數(shù)的值，比如分配一個超大的字節(jié)數(shù)組，此時就直接把這個大對象放入到老年代，不會經(jīng)過新生代。

這么做就可以避免大對象在新生代，屢次躲過GC，還得把他們來復制來復制去的，最后才進入老年代，這么大的對象來回復制，是很耗費時間的。

什么是空間分配擔保策略？

JVM在發(fā)生Minor GC之前，虛擬機會檢查老年代最大可用的連續(xù)空間是否大于新生代所有對象的總空間，如果大于，則此次Minor GC是安全的如果小于，則虛擬機會查看HandlePromotionFailure設置項的值是否允許擔保失敗。如果HandlePromotionFailure=true，那么會繼續(xù)檢查老年代最大可用連續(xù)空間是否大于歷次晉升到老年代的對象的平均大小，如果大于則嘗試進行一次Minor GC，但這次Minor GC依然是有風險的；如果小于或者HandlePromotionFailure=false，則改為進行一次Full GC。

如何優(yōu)化減少Full GC？

將前面的一些問題總結下來，然后應用到線上，那JVM應該如何優(yōu)化減少Full GC呢？以標準的4核8G機器為例說明，首先系統(tǒng)預留4G，其他4G按如下規(guī)則分配 ：

• 堆內(nèi)存：3g

• 新生代：1.5g

• 新生代Eden區(qū)：1228m

• 新生代Survivor區(qū)：153m

• 方法區(qū)：256m

• 虛擬機棧：1m/thread

設置參數(shù)如下：

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

估算系統(tǒng)每秒占用內(nèi)存數(shù)量

在優(yōu)化JVM之前，要先估算要系統(tǒng)每秒占用的內(nèi)存數(shù)量，如有個日活百萬的商場系統(tǒng)，每日下單量在20w左右，按照一天8個小時算，那訂單服務的每秒大概會有500個請求，然后粗略的估算下每個請求占用多少內(nèi)存，計算出每秒要花費多少內(nèi)存。

假設是每秒500個請求，每個請求需要分配100k的空間，那1秒需要分配大約50m的內(nèi)存。

計算下多長時間觸發(fā)一次Minor GC

按照之前的估算1秒需要分配大約50m的內(nèi)存的話，Eden區(qū)的空間是1228m那平均每25秒就要執(zhí)行一次Minor GC。

檢查下Survivor區(qū)是否足夠

按照上面的模型，每25秒就要執(zhí)行一次Minor GC，GC執(zhí)行期間并不能回收掉所有的新生代中的對象，那每秒50m那每次GC執(zhí)行期間還會剩下大約100m無法回收的對象會進入Survivor區(qū)，但是別忘記JVM有動態(tài)年齡判斷機制，這樣設置下來Survivor的空間明顯小了一點，所以將新生代設置2048m，才能避免觸發(fā)動態(tài)年齡判斷：

-Xms3072m
-Xmx3072m
-Xmn2048m
...

大對象直接進入老年代

大對象一般是長期存活和使用的對象，一般來說設置1M的對象直接進入老年代，這樣避免大對象一直處于新生代中來回復制，所以加上PretenureSizeThreshold=1m參數(shù)。

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

合理設置對象年齡閾值

Minor GC后默認躲過15次垃圾回收后自動升入老年代，按照我們的評估25秒觸發(fā)一次Minor GC，如果按照MaxTenuringThreshold參數(shù)的默認值，躲過15次GC后，應該是6分鐘之后的事了，結合當前業(yè)務場景這里可以降低一點，讓那些本應該進入老年代的對象，盡快的進入老年代，避免復制成本和浪費新生代空間，從而導致新生代Survivor空間不足，引發(fā)Full GC。

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

“線上JVM是怎么優(yōu)化的”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注億速云網(wǎng)站，小編將為大家輸出更多高質量的實用文章！