類加載機制，雙親委派模型（2）

接着昨天的記錄，今天繼續開始了。 在JDK9中，因爲Jigsaw項目引入了Java平臺模塊化系統（JPMS），Java SE的源代碼被劃分爲一系列模塊。 類加載器，類文件容器等都發生了很是大的變化，API已經被劃分到具體的模塊中，因此上文中，利用「——Xbootclasspath/p」 替換某個Java核心類型代碼，實際上變成了對對應的模塊進行的修補，能夠採用下面的解決方案： 首先，確認要修改的類文件已經編譯好，並按照對應模塊結構存放，而後，給模塊打補丁：

java --patch-module java.base=your_pathch yourApp

• 拓展類加載器將被重命名爲平臺類加載器（Platform Class-Loader)，並且extension機制規則被移除。也就意味着，若是咱們指定Java.ext.dirs環境變量，或者lib/ext目錄存在，JVM將直接返回錯誤！建議解決方法就是將其放入classpath裏。
• 部分不須要AllPermission的Java基礎模塊，被降級到平臺類加載器中，相應的權限粒度也被更精細粒度地限制起來。
• rt.jar和tools.jar一樣是被移除了！JDK的核心類庫以及相關資源，被存儲在jimage文件中，並經過新的JRT文件系統訪問，二不是原有的JAR文件系統。雖然看起來很驚人，但幸虧對於大部分軟件的兼容性影響，實際上是有限的，更直接的影響的是IDE等軟件，一般只要升級到最新版本就能夠了。
• 增長了Layer的抽象，JVM啓動默認建立BootLayer，開發者也能夠本身去定義和實例化Layer，能夠更加方便的實現相似容器通常的邏輯抽象。結合了Layer，目前的JVM內部結構就變成了下面的層次，內建類加載器都在BootLayer中，其餘Layer內部有自定義的類加載器，不一樣版本模塊能夠同時工做在不一樣的Layer。 談到類加載器，繞不夠的一個話題是自定義類加載器，常見的場景有：
• 實現相似進程內隔離，類加載器實際上用作不一樣的命名空間，以提供相似容器、模塊化的效果。例如，兩個模塊依賴於某個類庫的不一樣版本，若是分別被不一樣的容器加載，就能夠互不干擾。這個方面的集大成這是JavaEE和OSGI、JPMS等框架。
• 應用須要從不一樣的數據源獲取類定義信息，例如網絡數據源，而不是本地文件系統。
• 或者是須要本身操縱字節碼，動態修改或者生成類型。 咱們能夠整體上簡單理解自定義類加載過程：
• 經過指定名稱，找到其二進制實現，這裏每每就是自定義類加載器會定製的部分，例如在特定數據源根據名字獲取字節碼，或者修改或者生成字節碼。
• 而後，建立Class對象，並完成類加載過程。二進制信息到Class對象的轉換，一般就依賴defineClass,咱們無需本身實現，它是final方法。有了Class對象，後續完成加載過程就瓜熟蒂落了。