這篇文章真的是給大家分享一篇我自己血的教訓，本人是一個(gè)勤勤懇懇、任勞任怨的java程序猿一直都在自己的崗位上發(fā)光發(fā)熱，耐不住今年疫情小心思就發(fā)芽了，想要跳槽到大廠(chǎng)上班，在家里那簡(jiǎn)直就是頭懸梁錐刺股，因為身邊也沒(méi)有太多大廠(chǎng)上班經(jīng)驗的朋友，所以自己也算是無(wú)頭蒼蠅一樣頭懸梁錐刺股的看書(shū)、做題，但是確實(shí)自己看的題型還是不夠全面，面試官問(wèn)的問(wèn)題都是比較全面的，可想而知是掛了。
掛了之后其實(shí)還是比較沮喪的，但是又想想自己工作經(jīng)驗也有，又刷了這么多的題，也知道面試大概會(huì )遇到什么場(chǎng)景，相當于是半只腳已經(jīng)跨進(jìn)門(mén)了，怎么能輕易放棄呢？
不就是把所有的面試題全部都搞定嗎？我就不信我弄不清白，在朋友的介紹下，找到了一些大神分享的面試資料，并且大神的教了我一些技巧，經(jīng)過(guò)幾個(gè)月的時(shí)間，功夫不負有心人，我終于拿到offer了。
這確實(shí)是很艱難的過(guò)程，但是沒(méi)有什么熬不過(guò)去的，不就是重新找回高三的感覺(jué)，只要你資料夠多，技巧正確，心夠沉，一定可以進(jìn)入到自己理想的公司，我的資料也分享給大家。
接下來(lái)就主要是從一個(gè)面試的案例題來(lái)告訴大家，在面試的時(shí)候如何有技巧的回答面試官的問(wèn)題，也是一個(gè)常見(jiàn)的面試問(wèn)題“JVM類(lèi)加載機制”大家可以看看，說(shuō)不定你面試的時(shí)候剛好遇到了也說(shuō)不定。
接下來(lái)就來(lái)看看這個(gè)案例，面試者該如何應對……
在了解類(lèi)加載機制前，我們要先了解下類(lèi)加載的過(guò)程，然后再進(jìn)行逐步深入
類(lèi)加載運行全過(guò)程
當我們用java命令運行某個(gè)類(lèi)的main函數啟動(dòng)程序時(shí)，首先需要通過(guò)類(lèi)加載器把主類(lèi)加載到JVM。
其中loadClass的類(lèi)加載過(guò)程有如下幾步：
加載 >> 驗證 >> 準備 >> 解析 >> 初始化 >> 使用 >> 卸載
? 加載：在硬盤(pán)上查找并通過(guò)IO讀入字節碼文件，使用到類(lèi)時(shí)才會(huì )加載，例如調用類(lèi)的main()方法，new對象等等，在加載階段會(huì )在內存中生成一個(gè)代表這個(gè)類(lèi)的java.lang.Class對象，作為方法區這個(gè)類(lèi)的各種數據的訪(fǎng)問(wèn)入口
? 驗證：校驗字節碼文件的正確性
? 準備：給類(lèi)的靜態(tài)變量分配內存，并賦予默認值
? 解析：將符號引用替換為直接引用，該階段會(huì )把一些靜態(tài)方法(符號引用，比如main()方法)替換為指向數據所存內存的指針或句柄等(直接引用)，這是所謂的靜態(tài)鏈接過(guò)程(類(lèi)加載期間完成)，動(dòng)態(tài)鏈接是在程序運行期間完成的將符號引用替換為直接引用，下節課會(huì )講到動(dòng)態(tài)鏈接
? 初始化：對類(lèi)的靜態(tài)變量初始化為指定的值，執行靜態(tài)代碼塊
類(lèi)被加載到方法區中后主要包含 運行時(shí)常量池、類(lèi)型信息、字段信息、方法信息、類(lèi)加載器的引用、對應class實(shí)例的引用等信息。
類(lèi)加載器的引用：這個(gè)類(lèi)到類(lèi)加載器實(shí)例的引用
對應class實(shí)例的引用：類(lèi)加載器在加載類(lèi)信息放到方法區中后，會(huì )創(chuàng )建一個(gè)對應的Class 類(lèi)型的對象實(shí)例放到堆(Heap)中, 作為開(kāi)發(fā)人員訪(fǎng)問(wèn)方法區中類(lèi)定義的入口和切入點(diǎn)。
注意，主類(lèi)在運行過(guò)程中如果使用到其它類(lèi)，會(huì )逐步加載這些類(lèi)。jar包或war包里的類(lèi)不是一次性全部加載的，是使用到時(shí)才加載。
上面的類(lèi)加載過(guò)程主要是通過(guò)類(lèi)加載器來(lái)實(shí)現的，Java里有如下幾種類(lèi)加載器
? 引導類(lèi)加載器：負責加載支撐JVM運行的位于JRE的lib目錄下的核心類(lèi)庫，比如rt.jar、charsets.jar等
? 擴展類(lèi)加載器：負責加載支撐JVM運行的位于JRE的lib目錄下的ext擴展目錄中的JAR
類(lèi)包
? 應用程序類(lèi)加載器：負責加載ClassPath路徑下的類(lèi)包，主要就是加載你自己寫(xiě)的那
些類(lèi)
? 自定義加載器：負責加載用戶(hù)自定義路徑下的類(lèi)包
看一個(gè)類(lèi)加載器示例：
參見(jiàn)類(lèi)運行加載全過(guò)程圖可知其中會(huì )創(chuàng )建JVM啟動(dòng)器實(shí)例sun.misc.Launcher。sun.misc.Launcher初始化使用了單例模式設計，保證一個(gè)JVM虛擬機內只有一個(gè)sun.misc.Launcher實(shí)例。
在Launcher構造方法內部，其創(chuàng )建了兩個(gè)類(lèi)加載器，分別是sun.misc.Launcher.ExtClassLoader(擴展類(lèi)加載器)和sun.misc.Launcher.AppClassLoader(應用類(lèi)加載器)。
JVM默認使用Launcher的getClassLoader()方法返回的類(lèi)加載器AppClassLoader的實(shí)例加載我們的應用程序。
JVM類(lèi)加載器是有親子層級結構的，如下圖
這里類(lèi)加載其實(shí)就有一個(gè)雙親委派機制，加載某個(gè)類(lèi)時(shí)會(huì )先委托父加載器尋找目標類(lèi)，找不到再委托上層父加載器加載，如果所有父加載器在自己的加載類(lèi)路徑下都找不到目標類(lèi)，則在自己的類(lèi)加載路徑中查找并載入目標類(lèi)。
比如我們的Math類(lèi)，最先會(huì )找應用程序類(lèi)加載器加載，應用程序類(lèi)加載器會(huì )先委托擴展類(lèi)加載器加載，擴展類(lèi)加載器再委托引導類(lèi)加載器，頂層引導類(lèi)加載器在自己的類(lèi)加載路徑里找了半天沒(méi)找到Math類(lèi)，則向下退回加載Math類(lèi)的請求，擴展類(lèi)加載器收到回復就自己加載，在自己的類(lèi)加載路徑里找了半天也沒(méi)找到Math類(lèi)，又向下退回Math類(lèi)的加載請求給應用程序類(lèi)加載器， 應用程序類(lèi)加載器于是在自己的類(lèi)加載路徑里找Math類(lèi)，結果找到了就自己加載了。。
雙親委派機制說(shuō)簡(jiǎn)單點(diǎn)就是，先找父親加載，不行再由兒子自己加載
我們來(lái)看下應用程序類(lèi)加載器AppClassLoader加載類(lèi)的雙親委派機制源碼，AppClassLoader 的loadClass方法最終會(huì )調用其父類(lèi)ClassLoader的loadClass方法，該方法的大體邏輯如下：
首先，檢查一下指定名稱(chēng)的類(lèi)是否已經(jīng)加載過(guò)，如果加載過(guò)了，就不需要再加載，直接返回。
如果此類(lèi)沒(méi)有加載過(guò)，那么，再判斷一下是否有父加載器；如果有父加載器，則由父加載器加載（即調用parent.loadClass(name, false);）.或者是調用bootstrap類(lèi)加載器來(lái)加載。
如果父加載器及bootstrap類(lèi)加載器都沒(méi)有找到指定的類(lèi)，那么調用當前類(lèi)加載器的findClass方法來(lái)完成類(lèi)加載。
? 沙箱安全機制：自己寫(xiě)的java.lang.String.class類(lèi)不會(huì )被加載，這樣便可以防止核心API庫被隨意篡改
? 避免類(lèi)的重復加載：當父親已經(jīng)加載了該類(lèi)時(shí)，就沒(méi)有必要子ClassLoader再加載一次，保證被加載類(lèi)的唯一性
看一個(gè)類(lèi)加載示例：
“全盤(pán)負責”是指當一個(gè)ClassLoder裝載一個(gè)類(lèi)時(shí)，除非顯示的使用另外一個(gè)ClassLoder，該類(lèi) 所依賴(lài)及引用的類(lèi)也由這個(gè)ClassLoder載入。
自定義類(lèi)加載器只需要繼承 java.lang.ClassLoader 類(lèi)，該類(lèi)有兩個(gè)核心方法，一個(gè)是loadClass(String, boolean)，實(shí)現了雙親委派機制，還有一個(gè)方法是findClass，默認實(shí)現是空方法，所以我們自定義類(lèi)加載器主要是重寫(xiě)findClass方法。
再來(lái)一個(gè)沙箱安全機制示例，嘗試打破雙親委派機制，用自定義類(lèi)加載器加載我們自己實(shí)現的java.lang.String.class
以Tomcat類(lèi)加載為例，Tomcat 如果使用默認的雙親委派類(lèi)加載機制行不行？ 我們思考一下：Tomcat是個(gè)web容器， 那么它要解決什么問(wèn)題：
一個(gè)web容器可能需要部署兩個(gè)應用程序，不同的應用程序可能會(huì )依賴(lài)同一個(gè)第三方類(lèi)庫的不同版本，不能要求同一個(gè)類(lèi)庫在同一個(gè)服務(wù)器只有一份，因此要保證每個(gè)應用程序的類(lèi)庫都是獨立的，保證相互隔離。
部署在同一個(gè)web容器中相同的類(lèi)庫相同的版本可以共享。否則，如果服務(wù)器有10個(gè)應用程序，那么要有10份相同的類(lèi)庫加載進(jìn)虛擬機。
web容器也有自己依賴(lài)的類(lèi)庫，不能與應用程序的類(lèi)庫混淆?；诎踩紤]，應該讓容器的類(lèi)庫和程序的類(lèi)庫隔離開(kāi)來(lái)。
web容器要支持jsp的修改，我們知道，jsp 文件最終也是要編譯成class文件才能在虛擬機中運行，但程序運行后修改jsp已經(jīng)是司空見(jiàn)慣的事情， web容器需要支持 jsp 修改后不用重啟。
再看看我們的問(wèn)題：Tomcat 如果使用默認的雙親委派類(lèi)加載機制行不行？ 答案是不行的。為什么？
第一個(gè)問(wèn)題，如果使用默認的類(lèi)加載器機制，那么是無(wú)法加載兩個(gè)相同類(lèi)庫的不同版本的，默認的類(lèi)加器是不管你是什么版本的，只在乎你的全限定類(lèi)名，并且只有一份。
第二個(gè)問(wèn)題，默認的類(lèi)加載器是能夠實(shí)現的，因為他的職責就是保證唯一性。第三個(gè)問(wèn)題和第一個(gè)問(wèn)題一樣。
我們再看第四個(gè)問(wèn)題，我們想我們要怎么實(shí)現jsp文件的熱加載，jsp 文件其實(shí)也就是class文件，那么如果修改了，但類(lèi)名還是一樣，類(lèi)加載器會(huì )直接取方法區中已經(jīng)存在的，修改后的jsp 是不會(huì )重新加載的。那么怎么辦呢？我們可以直接卸載掉這jsp文件的類(lèi)加載器，所以你應該想
到了，每個(gè)jsp文件對應一個(gè)唯一的類(lèi)加載器，當一個(gè)jsp文件修改了，就直接卸載這個(gè)jsp類(lèi)加載器。重新創(chuàng )建類(lèi)加載器，重新加載jsp文件。
tomcat的幾個(gè)主要類(lèi)加載器：
? commonLoader：Tomcat最基本的類(lèi)加載器，加載路徑中的class可以被Tomcat容器本身以及各個(gè)Webapp訪(fǎng)問(wèn)；
? catalinaLoader：Tomcat容器私有的類(lèi)加載器，加載路徑中的class對于Webapp不可見(jiàn)；
? sharedLoader：各個(gè)Webapp共享的類(lèi)加載器，加載路徑中的class對于所有Webapp可見(jiàn)，但是對于Tomcat容器不可見(jiàn)；
? WebappClassLoader：各個(gè)Webapp私有的類(lèi)加載器，加載路徑中的class只對當前Webapp可見(jiàn)，比如加載war包里相關(guān)的類(lèi)，每個(gè)war包應用都有自己的WebappClassLoader，實(shí)現相互隔離，比如不同war包應用引入了不同的spring版本， 這樣實(shí)現就能加載各自的spring版本；
從圖中的委派關(guān)系中可以看出：
CommonClassLoader能加載的類(lèi)都可以被CatalinaClassLoader和SharedClassLoader使用， 從而實(shí)現了公有類(lèi)庫的共用，而CatalinaClassLoader和SharedClassLoader自己能加載的類(lèi)則與對方相互隔離。
WebAppClassLoader可以使用SharedClassLoader加載到的類(lèi)，但各個(gè)WebAppClassLoader 實(shí)例之間相互隔離。
而JasperLoader的加載范圍僅僅是這個(gè)JSP文件所編譯出來(lái)的那一個(gè).Class文件，它出現的目的就是為了被丟棄：當Web容器檢測到JSP文件被修改時(shí)，會(huì )替換掉目前的JasperLoader的實(shí)例， 并通過(guò)再建立一個(gè)新的Jsp類(lèi)加載器來(lái)實(shí)現JSP文件的熱加載功能。
tomcat 這種類(lèi)加載機制違背了java 推薦的雙親委派模型了嗎？答案是：違背了。
很顯然，tomcat 不是這樣實(shí)現，tomcat 為了實(shí)現隔離性，沒(méi)有遵守這個(gè)約定，每個(gè)webappClassLoader加載自己的目錄下的class文件，不會(huì )傳遞給父類(lèi)加載器，打破了雙親委派機制。
注意：同一個(gè)JVM內，兩個(gè)相同包名和類(lèi)名的類(lèi)對象可以共存，因為他們的類(lèi)加載器可以不一
樣，所以看兩個(gè)類(lèi)對象是否是同一個(gè)，除了看類(lèi)的包名和類(lèi)名是否都相同之外，還需要他們的類(lèi)加載器也是同一個(gè)才能認為他們是同一個(gè)。
附下User類(lèi)的代碼：
雖然只用一個(gè)常用問(wèn)題進(jìn)行剖析，其中的目的就是為了告訴和我一樣有java工作經(jīng)驗的工作者，想要進(jìn)入更好的工作崗位，必須全面了解各個(gè)題型，并且有技巧、有條理的回答出來(lái)，面試官不會(huì )刻意的為難大家，只要你掌握好每個(gè)知識點(diǎn)，再加上自己的經(jīng)驗融會(huì )貫通，是沒(méi)有問(wèn)題的。我也將更多的面試資料和經(jīng)驗總結分享給大家。
你要知道很多Java面試官的問(wèn)題都萬(wàn)變不離其宗，只是看你當場(chǎng)的回答效果，作為有經(jīng)驗的工作者，不是難事，只要你做好的充足的準備。有很多人走彎路，只了解一個(gè)方面，比如只準備了算法題，這方面回答得很好，其他的就一無(wú)所知。要知道，面試官不可能只問(wèn)算法問(wèn)題，切記，面試前一定要準備，如果你拿到面試資料，想盡辦法都要琢磨透，搞定這些面試資料，拿到理想的offer不是問(wèn)題。
聯(lián)系客服
