Java類隔離加載實現原理是什麼？ JVM 提供一個全局類加載器的設置接口，直接替換全局類加載器，但無法解決多個自定義類加載器同時存在的問題。然而JVM會選擇當前類的類加載器來加載所有該類的引用的類。
類隔離技術是什麼？
只要Java 代碼寫得足夠多就一定會出現這種情況：系統新引入了一個中間件的 jar 包，編譯的時候一切正常，一運行就報錯：java.lang.NoSuchMethodError，然後就哼哧哼哧的開始找解決方法，最後在幾百個依賴包裡面找的眼睛都快瞎了才找到衝突的 jar，把問題解決之後就開始吐槽中間件為啥搞那麼多不同版本的 jar，寫代碼五分鐘，排包排了一整天。
上面這種情況就是Java 開發過程中常見的情況，原因也很簡單，不同 jar 包依賴了某些通用 jar 包（如日誌組件）的版本不一樣，編譯的時候沒問題，到了運行時就會因為加載的類跟預期不符合導致報錯。
舉個例子：A 和 B 分別依賴了 C 的 v1 和 v2 版本，v2 版本的 Log 類比 v1 版本新增了 error 方法，現在工程裡面同時引入了 A、B 兩個 jar 包，以及 C 得 v0.1、v0.2 版本，打包的時候 maven 只能選擇一個 C 的版本，假設選擇了 v1 版本。到了運行的時候，默認情況下一個項目的所有類都是用同一個類加載器加載的，所以不管你依賴了多少個版本的 C，最終只會有一個版本的 C 被加載到 JVM 中。當 B 要去訪問 Log.error，就會發現 Log 壓根就沒有 error 方法，然後就拋異常java.lang.NoSuchMethodError。這就是類衝突的一個典型案例。
類衝突的問題如果版本是向下兼容的其實很好解決，把低版本的排除掉就完事了。但要是遇到版本不向下兼容的那就陷入了「救媽媽還是救女朋友」的兩難處境了。
為了避免兩難選擇，有人就提出了類隔離技術來解決類衝突的問題。類隔離的原理也很簡單，就是讓每個模塊使用獨立的類加載器來加載，這樣不同模塊之間的依賴就不會互相影響。如下圖所示，不同的模塊用不同的類加載器加載。
為什麼這樣做就能解決類衝突呢？這裡用到了 Java 的一個機制：不同類加載器加載的類在 JVM 看來是兩個不同的類，因為在 JVM 中一個類的唯一標誌是 類加載器+類名。通過這種方式我們就能夠同時加載 C 的兩個不同版本的類，即使它類名是一樣的。注意，這裡類加載器指的是類加載器的實例，並不是一定要定義兩個不同類加載器，例如圖中的 PluginClassLoaderA 和 PluginClassLoaderB 可以是同一個類加載器的不同實例。
實現類隔離的原理是什麼？
類隔離就是讓不同模塊的 jar 包用不同的類加載器加載，要做到這一點，就需要讓 JVM 能夠使用自定義的類加載器加載我們寫的類以及其關聯的類。
那麼如何實現呢？一個很簡單的做法就是 JVM 提供一個全局類加載器的設置接口，這樣我們直接替換全局類加載器就行了，但是這樣無法解決多個自定義類加載器同時存在的問題。
實際上 JVM 提供了一種非常簡單有效的方式，我把它稱為類加載傳導規則：JVM 會選擇當前類的類加載器來加載所有該類的引用的類。例如我們定義了 TestA 和 TestB 兩個類，TestA 會引用 TestB，只要我們使用自定義的類加載器加載 TestA，那麼在運行時，當 TestA 調用到 TestB 的時候，TestB 也會被 JVM 使用 TestA 的類加載器加載。
依此類推，只要是 TestA 及其引用類關聯的所有 jar 包的類都會被自定義類加載器加載。通過這種方式，我們只要讓模塊的 main 方法類使用不同的類加載器加載，那麼每個模塊的都會使用 main 方法類的類加載器加載的，這樣就能讓多個模塊分別使用不同類加載器。這也是 OSGi 和 SofaArk 能夠實現類隔離的核心原理。
了解類隔離的實現原理之後，從重寫類加載器開始進行實操。要實現類加載器，首先讓自定義的類加載器繼承 java.lang.ClassLoader，然後重寫類加載的方法，這裡有兩個選擇，一是重寫 findClass(String name)，二是重寫 loadClass(String name)。