JVM(Java虛擬機)簡單來講就是運行Java代碼的解釋器,做爲螺絲釘程序員JVM其實瞭解下就差很少啦,不懂JVM內部細節照樣能寫出優質的代碼!可是一到造火箭、飛機的場景(面試)不懂JVM的你,會被面試官虐的體無完膚,本期內容列舉常見的JVM面試題:程序員
面對這一大波JVM面試題,你真的Hold住嗎?面試
JVM內存結構能夠大體可劃分爲線程私有區域和共享區域,線程私有區域由虛擬機棧、本地方法棧、程序計數器組成,而共享區域由堆、元數據空間(方法區)組成。算法
再有人問你JVM的內存結構就回想下上面的圖,可是知道JVM的內存模型的樣子仍是不行的,還要知道他們分別幹什麼的。數組
當你碰到過StackOverflowException
這個異常的時候,有沒有思考下爲何會出現這樣的異常呢?答案就在虛擬機棧中,JVM會爲每一個方法生成棧幀而後將棧幀壓入虛擬機棧中。安全
舉個粟子:假設JVM參數-Xss
設置爲1m
,若是某個方法裏面建立一個128kb的數組,那這個方法在同一個線程中只能遞歸4次,再遞歸第五次的時候就會報StackOverflowException
異常,由於虛擬機棧的大小隻有1m,每次遞歸都須要爲方法在虛擬機棧中分配128kb的空間,很顯示到第五次的時候就空間不足了。多線程
程序計數器是一個記錄着當前線程所執行的字節碼的行號指示器。JVM的多線程是經過CPU時間片輪轉(即線程輪流切換並分配處理器執行時間)算法來實現的。也就是說,某個線程在執行過程當中可能會由於時間片耗盡而被掛起,而另外一個線程獲取到時間片開始執行。架構
簡單的說程序計數器的主要功能就是記錄着當前線程所執行的字節碼的行號指示器。機器學習
方法區存儲了類的元數據信息、靜態變量、常量等數據。學習
日常你們使用new
關鍵字建立的對象都會進入堆中,堆也是GC重點照顧的區域,堆會被劃分爲:新生代、老年代,而新生代還會被進一步劃分爲Eden區和Survivor區:大數據
新生代中的Eden區和Survivor區,是根據JVM回收算法來的,只是如今大部分都是使用的分代回收算法,因此在介紹堆的時候會直接將新生代概括爲Eden區和Survivor區。
JVM內存模型小結:
new
關鍵字建立的對象都會進入堆中,堆被劃分爲新生代和老年代JVM判斷對象回收有兩種方式:引用記數、GC Roots,引用記數比較簡單,JVM爲每一個對象維護一個引用計數,假設A對象引用計數爲零說明沒有任務對象引用A對象,那A對象就能夠被回收了,可是引用計數有個缺點就是沒法解決循環引用的問題。
GC Roots經過一系列的名爲GC Roots的對象做爲起始點,從這些節點開始向下搜索,搜索過的路徑稱爲引用鏈,當一個對象到GC Roots沒有任何引用鏈相連時,則證實對象是不可用的。
在Java中,能夠做爲GC Roots的對象包括下面幾種:
總的來講就是當一個對象經過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。
將前面的一些問題總結下來,而後應用到線上,那JVM應該如何優化減小Full GC呢?以標準的4核8G機器爲例說明,首先系統預留4G,其餘4G按以下規則分配 :
設置參數以下:
-Xms3072m -Xmx3072m -Xmn1536m -Xss=1m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:HandlePromotionFailure -XX:SurvivorRatio=8
在優化JVM以前,要先估算要系統每秒佔用的內存數量,若有個日活百萬的商場系統,每日下單量在20w左右,按照一天8個小時算,那訂單服務的每秒大概會有500個請求,而後粗略的估算下每一個請求佔用多少內存,計算出每秒要花費多少內存。
假設是每秒500個請求,每一個請求須要分配100k的空間,那1秒須要分配大約50m的內存。
按照以前的估算1秒須要分配大約50m的內存的話,Eden區的空間是1228m那平均每25秒就要執行一次Minor GC。
按照上面的模型,每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 ...
《架構文摘》天天一篇架構領域重磅好文,涉及一線互聯網公司應用架構(高可用、高性 能、高穩定)、大數據、機器學習等各個熱門領域。