面了BAT,我總結(jié)了他們會問的JVM基礎(chǔ)知識
掃描二維碼
隨時隨地手機看文章
面試開始
一個一看就是一周沒洗頭,穿著格子襯衣的中年男子,拿著背面滿是貼紙的 mac 走了進來??粗@地中海,心想他肯定是尼瑪高級架構(gòu)師吧! 但是看過程序員大帝的小伙伴,肯定都跟無忌一樣練就了吹的能力,肯定不帶虛的。
小伙子您好,看你簡歷上寫了你對 JVM 的原理和調(diào)優(yōu)都有所了解,先給我講講你對 JVM 的了解?
心里忍不住暗罵,這叫啥問題,太寬了吧,但是你不能說出來。這個問題和自我介紹一樣,就是拋磚引玉。
所以咱們還是要認真回答:Java 虛擬機是 Java 語言能夠得到廣泛傳播的基礎(chǔ),讓 Java 一處安裝,到處運行成為了可能。在不同平臺上運行時不需要重新編譯,通過 JVM 屏蔽了與具體平臺相關(guān)的信息,使咱們 Java 程序員只需要關(guān)注目標代碼的實現(xiàn)即可。
JVM 有哪幾部分呀?
堆 Heap、棧 Stack、程序計數(shù)器 Register、方法區(qū)/永久代 Permanent、本地方法棧 Native Method Stack。
這里我相信 99% 的讀者都能回答上來 JVM 的 5 個基本組成部分,如果回答不出來的小伙伴我們就要加油補課喲,大家知道這五個部分每個的作用更好。
但是,如果你還想進一步突出你和其他候選人的不同,還需要加上下面的一些知識點。
在 JDK8 之后,對 JVM 內(nèi)存空間開始了改造,主要的區(qū)別是將方法區(qū)進行了移除,并新增了元空間,元空間是放置在 JVM 內(nèi)存空間之外的直接內(nèi)存中,并且 JDK8 中對于方法區(qū)的參數(shù) PermSize 和 MaxPermSize 已經(jīng)失效。
不錯,那為什么需要這樣改造?元空間是什么結(jié)構(gòu)呢?
有的時候面試官其實也不知道怎么問,所以我們需要對面試官進行引導。比如通過上一個問題,我們就可以引出自己對元空間的理解,這個知識點其實是非常能體現(xiàn)能力的。
在 JDK8 之前,JVM 模型中存在著方法區(qū),它是一個非常重要的區(qū)域,與堆一樣可以被線程共享。
在方法區(qū)中,存儲了每個類的信息(包括類的名稱、方法信息、字段信息)、靜態(tài)變量、常量以及編譯器編譯后的代碼等。我們也習慣稱方法區(qū)它為“永久代”(Permanent Generation),但是絕大部分 Java 程序員應(yīng)該都見過“java.lang.OutOfMemoryError: PremGen space”異常,這里的“PermGen space”其實指的就是方法區(qū)。
通過 -XX:MaxPermSize 這個參數(shù)可以設(shè)定方法區(qū)的大小,但是為它到底分配多大的空間很難確定,因為PermSize的大小依賴于很多因素,比如JVM加載的class總數(shù),常量池的大小,方法的大小等。
隨著動態(tài)類加載的情況越來越多,這塊內(nèi)存越來越不太可控。如果設(shè)置小了,當JVM加載的類信息容量超過了這個值,系統(tǒng)運行過程中就容易出現(xiàn)內(nèi)存溢出OOM:PermGen 的錯誤,設(shè)置大了又浪費內(nèi)存。
而元空間的本質(zhì)和永久代類似,都是對JVM規(guī)范中方法區(qū)的實現(xiàn)。不過元空間與永久代之間的最大區(qū)別在于:元空間并不在虛擬機中,而是使用本地內(nèi)存。因此,默認情況下,元空間的大小僅受本地內(nèi)存限制。
注:本人在面試時非常喜歡問這個問題,真正能把這其中的原理說清楚的同學不多,但其實很好理解,看完這篇文章相信你就可以在面試官面前侃侃而談了。
剛剛你提到了內(nèi)存溢出,可不可以說幾種常見的 OOM?
有的同學看到這個問題,心想這不是給自己挖坑么,我知道 OOM 是 Out Of Memory 內(nèi)存溢出錯誤,哪里還知道其中的道道呢?
但大家遇到凡事不要慌,屢屢思路問題不大。
當JVM內(nèi)存嚴重不足時,就會拋出 java.lang.OutOfMemoryError 錯誤,根據(jù)實際生產(chǎn)經(jīng)驗,OOM是非常嚴重的問題,一般會對程序日志中的 OutOfMemoryError 配置關(guān)鍵字告警,一經(jīng)發(fā)現(xiàn),立即處理。
常見引起 OOM 的錯誤主要有以下幾種:
(1)Java Heap Space
當堆沒有足夠的內(nèi)存空間存放新創(chuàng)建的對象時,就會拋出 java.lang.OutOfMemoryError:Java heap space 錯誤。比如請求創(chuàng)建一個超大的大數(shù)組對象,或者發(fā)生了內(nèi)存泄露,該回收的對象沒有釋放,堆空間不足等等。
(2)GC overhead limit exceeded
當 Java 進程花費 98% 以上的時間執(zhí)行 GC,但只恢復了不到 2% 的內(nèi)存,且該動作連續(xù)重復了 5 次,就會拋出 java.lang.OutOfMemoryError:GC overhead limit exceeded 錯誤。
(3)Unable to create new native thread
Java 的線程是用戶級線程,它的創(chuàng)建和使用對應(yīng)著操作系統(tǒng)的內(nèi)核級線程,每個 Java 線程都需要占用一定的內(nèi)存空間。當 JVM 向底層操作系統(tǒng) OS 請求創(chuàng)建 native 線程,沒有足夠的資源分配就會報此類錯誤。
這時候估計面試官會露出一個(猥瑣)的笑容,心想今天面試的這個小伙子還不錯,掌握的很扎實。下面要問些有難度的問題了,看看他到底什么水平。
平時項目中有沒有 JVM 調(diào)優(yōu)的經(jīng)驗?zāi)兀?/span>
無形裝逼,最為致命。而這個問題,就是給你吹牛*的最好機會!
很多同學都會覺得 JVM 是底層知識,掌握起來非常困難,但這是成為一名優(yōu)秀 Java 程序員的必修課!
這時候即使你內(nèi)心洶涌澎拜,也要表面給予恰當其份的淡然,然后回答:嗯,做過一些,項目上線前的 JVM 優(yōu)化和線上問題排查都經(jīng)歷過。
對方包括我這時都會非常有興趣,心里開始默念:終于開始有點意思了。
畢竟前面的問題都是偏向于理論的知識,但是涉及到 JVM 調(diào)優(yōu)和問題排查就會考察具體的功底了,光靠背概念可沒用。
你是怎么了解 JVM 運行的狀況?
很多成熟的公司都已經(jīng)建立了可視化的監(jiān)控平臺,比如Zabbix、Ganglia、Open-Falcon、Prometheus 等等,但如果沒有這樣的條件,通過命令行我們也可以觀察 JVM 各個區(qū)域的內(nèi)存變化,GC 次數(shù)和 GC 耗時。
jstat 就是自帶的小而強大的工具,可以直觀的把每一個參數(shù)打印出來。具體的使用大家可以看之前的文章:
如果發(fā)現(xiàn)內(nèi)存溢出了,怎么處理?
發(fā)生了內(nèi)存溢出,我們需要先判斷具體是哪一種 OOM,然后再做相應(yīng)處理。比如堆內(nèi)存溢出,有可能是因為大對象導致的,這個時候我們可以通過 jmap 工具,dump 出內(nèi)存快照,然后再用 jhat 或者 Visual VM 之類的可視化工具來分析就可以了。
之前線上出過一個真實的重大Bug《重大事故!線上系統(tǒng)頻繁卡死,兇手竟然是 Full GC ?》,大家可以學習一下分析和排查思路。
面試的時候,完全可以把這個當成你自己的真實經(jīng)歷,和面試官侃侃而談。相信到這里面試官暗地里已經(jīng)對你豎起了大拇指。并且默默給了你A+。
面試結(jié)束
小伙子你可以的,什么時候有時間來上班啊,要不明天就來吧?
你強裝鎮(zhèn)定,這么急啊我還需要考慮考慮,要不下禮拜一吧。
好的,心想這小子這么龜毛是不是很多 Offer 在手上,不行我得叫 hr 小姐姐給他加錢還得微信溝通下。
能撐到最后,你自己都忍不住自己給自己點個贊了。其實在技術(shù)面試的時候,不管是 JVM 還是其他問題,如果你能舉出實際的例子,或者是自己開發(fā)過程的問題和收獲都會給面試官很好的印象,回答邏輯性也要強一點,不要東一點西一點。你想面試官可能剛剛還在修bug,把你自己和他都繞暈的。
還有就是回答問題的時候不要背概念,大家都這么回答,面試官肯定也想聽點不一樣的東西,比如你可以這樣回答:
大佬您好,首先我們的項目在上線之后遇到了性能瓶頸,特別是在有秒殺活動的時候。經(jīng)常由于數(shù)據(jù)量太大會報 JVM OOM 的錯誤,所以需要對它進行排查和調(diào)優(yōu),排查我是從觀察對象分布、垃圾回收耗時...入手,調(diào)優(yōu)我是從調(diào)整內(nèi)存大小、更改垃圾回收次數(shù)...進行,綜合這些然后再結(jié)合我們項目特點,最后我在線上做了...。
如果你這樣有條不紊,有理有據(jù)的回答了我的問題而且還說出很多問題外的知識點,我會覺得你不只是一個會寫代碼的人。你邏輯清晰,對知識有自己的理解和思考,說白了就是你的offer有戲了。
特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容,還沒關(guān)注的小伙伴,可以長按關(guān)注一下:
長按訂閱更多精彩▼
如有收獲,點個在看,誠摯感謝
免責聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!