說一說JVM雙親委派機制與Tomcat
- 2019 年 11 月 12 日
- 筆記
講個故事：
以前，愛搗鼓的小明突然靈機一動，寫出了下面的程式碼
package java.lang; public class String { //...複製真正String的其他方法 public boolean equals(Object anObject) { sendEmail(xxx)； return equalsReal(anObject); } //... } 這樣，只要引用java.lang.String的人，小明能隨時收到他的系統的相關資訊，這簡直是個天才的注意。然而實施的時候卻發現，JVM並沒有載入這個類。
這是為什麼呢？
小明能想到的事情，JVM設計者也肯定能想到。
雙親委派模型
上述故事純屬瞎編，不過，這確實是以前JVM存在的一個問題，這幾天看Tomcat源程式碼的時候，發現頻繁出現ClassLoader為什麼要用這個東西呢？
想要解答這個問題，得先了解一個定義：雙親委派模型。
這個詞第一次看見是在《深入理解JVM》中，目的也是為了解決上面所提出來的問題。
在JVM中，存在三種類型的類載入器：
- 啟動類（Bootstrap）載入器： 用於載入本地（
Navicat）程式碼類的載入器，它負責裝入%JAVA_HOME%/lib下面的類。由於引導類載入器涉及到虛擬機本地實現細節，開發者無法直接獲取到啟動類載入器的引用，所以不允許直接通過引用進行操作。 - 標準擴展（Extension）類載入器： 由
ExtClassLoader實現，負責載入%JAVA_HOME/lib/ext%或者系統變數java.ext.dir（可使用System.out.println("java.ext.dir")查看)指定的類載入到記憶體中 - 系統（System）類載入器： 由
AppClassLoader實現，負責載入系統類（環境變數%CLASSPATH%）指定，默認為當前路徑的類載入到記憶體中。
除去以上三種外，還有一種比較特殊的執行緒上下文類載入器。存在於Thread類中，一般使用方式為new Thread().getContextClassLoader()
可以看出來，三種類型的載入器負責不同的模組的載入。那怎麼才能保證我所使用的String就是JDK裡面的String呢？這就是雙親委派模型的功能了：
上面三種類載入器中，他們之間的關係為：
也就是Bootstrap ClassLoader作為Extension ClassLoader的父類，而Extension ClassLoader作為Application ClassLoader的父類，Application ClassLoader是作為User ClassLoader的父類的。
而雙親委派機制規定：當某個特定的類載入在接收到類載入的請求的時候，首先需要將載入任務委託給父類載入器，依次遞歸到頂層後，如果最高層父類能夠找到需要載入的類，則成功返回，若父類無法找到相關的類，則依次傳遞給子類。
補充：
- 如果A類引用了B，則JVM將使用載入類A的載入器載入類B
- 類載入器存在快取，如果某個載入器以前成功載入過某個類後，再次接受到此類載入請求則直接返回，不再向上傳遞載入請求
- 可以通過
ClassLoader.loadClass()或Class.ForName(xxx,true,classLoader)指定某個載入器載入類 - 類類型由載入它的載入器和這個類本身共同決定，如果類載入器不同，類名相同，
instanceof依然會返回false - 父載入器無法載入子載入器能夠載入的類
可以看到，通過雙親委派機制，能夠保證使用的類的安全性，並且可以避免類重名的情況下JVM存在多個相同的類名相同，位元組碼不同的類。
回到剛開始講的故事，雖然小明自定義了
String,包名也叫java.lang，但是當用戶使用String的時候，會由普通的Application ClassLoader載入java.lang.String，此時通過雙親委派，類載入請求會上傳給Application ClassLoader的父類，直到傳遞給Bootstrap ClassLoader，而此時，Bootstrap ClassLoader將在%JAVA_HOME%/lib中尋找java.lang.String而此時正好能夠找到java.lang.String，載入成功，返回。因此小明自己寫的java.lang.String並沒有被載入。
可以看見，如果真的想要實現小明的計劃，只能將小明自己編寫的
java.lang.String這個class文件替換到%JAVA_HOME%/lib/rt.jar 中的String.class
自定義ClassLoader
到這裡，估計能明白為什麼需要雙親委派模型了，而某些時候，我們可以看見許多框架都自定義了ClassLoader，通過自定義ClassLoader，我們可以做很多好玩的事情，比如：設計一個從指定路徑動態載入類的類載入器：
public class DiskClassLoader extends ClassLoader { private String libPath; public DiskClassLoader(String path){ libPath=path; } @Override protected Class<?> findClass(String name) throws ClassNotFoundException { try(FileInputStream fileInputStream=new FileInputStream(new File(libPath,getFileName(name))); BufferedInputStream bufferedInputStream=new BufferedInputStream(fileInputStream); ByteArrayOutputStream byteArrayOutputStream=new ByteArrayOutputStream()){ for (int len=0;(len=bufferedInputStream.read())!=-1;){ byteArrayOutputStream.write(len); } byte[] data=byteArrayOutputStream.toByteArray(); return defineClass(name,data,0,data.length); }catch (IOException e){ e.printStackTrace(); } return super.findClass(name); } private String getFileName(String name) { int index = name.lastIndexOf('.'); if(index == -1){ return name+".class"; }else{ return name.substring(index+1)+".class"; } } }上面是一個簡單的例子，可以看見想要自定義ClassLoader,只需要繼承ClassLoader，然後覆蓋findClass()方法即可，其中findClass()是負責獲取指定類的位元組碼的，在獲取到位元組碼後，需要手動調用defineClass()載入類。
在ClassLoader類中，我們能找到loadClass的源程式碼：
protected Class<?> loadClass(String name, boolean resolve) { // First, check if the class has already been loaded Class<?> c = findLoadedClass(name); if (c == null) { if (parent != null) { c = parent.loadClass(name, false); } else { c = findBootstrapClassOrNull(name); } if (c == null) { c = findClass(name); } } if (resolve) { resolveClass(c); } return c; }在刪減掉一些模板程式碼後，我們可以看到loadClass()方法就是實現雙親委派的主要程式碼：首先查看類是否有快取，如果沒有，就調用父類的loadClass方法，讓父類去載入，如果父類載入失敗，則自己載入，如果自己載入失敗，那就返回null,注意：並沒有再找自己的子類去尋找類，也就是在哪裡發起的載入，就在哪裡結束。
這裡可以看到，
loadClass()方法並沒有被標記為final的，也就是我們依然可以重載它的loadClass()方法，破壞原本的委派雙親模型。
破壞雙親委派機制
有些時候，雙親委派機制也會遇到一些問題，在介紹雙親委派機制的時候，我列舉了一些補充。而在一些JDK中，存在一些基礎API他們的載入由比較上層的載入器負責,這些API只是一些簡單的介面，而具體的實現可能會由其他用戶自己實現，這個時候就存在一個問題，如果這些基礎的API需要調用/載入用戶的程式碼的時候，會發現由於父類無法找到子類所能載入的類的原因，調用失敗。
最典型的例子便是JNDI服務，JNDI服務是在JDK1.3的時候放入rt.jar中，而rt.jar有Bootstrap ClassLoader載入，JNDI的功能是對資源進行集中管理和查找，它需要調用獨立廠商實現部部署在應用程式的classpath下的JNDI介面提供者(SPI, Service Provider Interface)的程式碼，但啟動類載入器不可能「認識」之些程式碼，該怎麼辦？
這就需要用到最開始講的特殊的載入器：上下文類載入器
上下文類載入器的使用方式為：Thread.currentThread().getContextClassLoader()
上下文類載入器是什麼意思呢？可以看源碼，Thread初始化是通過本地方法currentThread();初始化的，而classLoader也正是通過currentThread初始化，currentThread指的是當前正在運行的執行緒。
而默認情況下，啟動Launcher後，Launcher會將當前執行緒的上下文載入器設置為Application ClassLoader
public Launcher() { //... try { this.loader = Launcher.AppClassLoader.getAppClassLoader(var1); } catch (IOException var9) { throw new InternalError("Could not create application class loader", var9); } Thread.currentThread().setContextClassLoader(this.loader); //... }因此，上下文類載入器默認就是系統載入器，通過上下文載入器，更高級別的載入器便可以調用系統載入器載入一個類。
Tomcat 與類載入器
Tomcat作為一個Web容器，會包含各種Web應用程式，而為了使各個應用程式不互相干擾，至少需要達到以下要求：
- 部署在同一個Web容器上的兩個Web應用程式所使用的Java類庫可以實現相互隔離
- 部署在同一個Web容器上的兩個Web應用程式所使用的Java類庫可以相互共享
- Web容器需要保證自身的安全不受Web應用程式所影響
- 只是JSP的容器，需要支援熱部署功能
因為這些需求，所以在Tomcat中，類的載入不能使用簡單的ClassLoader來載入，而是需要自定義分級的ClassLoader。
在Tomcat中，定義了3組目錄結構/common/*,/server/*和/shared/*可以存放Java類庫，另外還有Web應用程式自身的結構：/WEB-INF/*，而這幾級目錄結構分別對應了不同的載入器
- common： 類庫可以被Tomcat和所有Web應用程式共同使用
- server： 類庫可以被Tomcat使用，對其他Web程式不可見
- shared： 類庫可以被所有的Web應用程式共同使用，但對Tomcat不可見
- WEB-INF: 類庫僅僅能被自身Web應用程式使用
因此，需要支援以上結構，可以通過自定義遵循雙親委派模型的ClassLoader來完成。
參考鏈接：
如果覺得寫得不錯，歡迎關注微信公眾號：逸游Java ,每天不定時發布一些有關Java乾貨的文章，感謝關注
