http://seanhe.iteye.com/blog/841723

?

由于平時項目中用到的還是JBoss 4.2.x所以我這里的分析時針對這個版本的，不一定適用其他JBoss版本。
下面言歸正傳。
JBoss為了實現類的共享引入了class loader repository的概念，并且設計了org.jboss.mx.loading.UnifiedClassLoader3 (UCL)來完成sharing classes的主要功能。
UCL和UnifiedLoaderRepository3 一對多的關系，默認情況下一個jboss實例中只有一個UnifiedLoaderRepository3實例，這個UnifiedLoaderRepository實例會和所有的UCL關聯。
NoAnnotationClassLoader是UCL的父classloader用來加載$JBOSS_HOME/lib下的jar,system class loader是NoAnnotationClassLoader的父classloader。
這幾個對象的關系請見下圖

從上圖可以看出默認情況下所有的UCL共享一個Repository，通過Repository可以實現class的共享。 UnifiedLoaderRepository3實例中維護著兩個容器，一個是class cache：這個容器很明顯緩存了一些class，這樣可以提高loadClass方法的執行效率；另一個是packagesMap：這個map維護的是 類的包名和UCL的mapping關系。具體UCL按什么邏輯load class的請看下面的活動圖：

UnifiedClassLoader3的繼承結構如下圖所示，UnifiedClassLoader3的父類RepositoryClassLoader重寫了URLClassLoader的loadClass方法，實現了上圖的邏輯

下面請看一下相關代碼：
RepositoryClassLoader.java

Java代碼 ?

public?Class?loadClass(String?name,?boolean?resolve)??

??????throws?ClassNotFoundException??

???{??

??????boolean?trace?=?log.isTraceEnabled();??

??????if?(trace)??

?????????log.trace("loadClass?"?+?this?+?"?name="?+?name+",?loadClassDepth="+loadClassDepth);??

??????Class?clazz?=?null;??

??????try??

??????{??

?????????if?(repository?!=?null)??

?????????{??

????????????clazz?=?repository.getCachedClass(name);//先從cache中load?class??

????????????if?(clazz?!=?null)??

????????????{??

???????????????if(?log.isTraceEnabled()?)??

???????????????{??

??????????????????StringBuffer?buffer?=?new?StringBuffer("Loaded?class?from?cache,?");??

??????????????????ClassToStringAction.toString(clazz,?buffer);??

??????????????????log.trace(buffer.toString());??

???????????????}??

???????????????return?clazz;??

????????????}??

?????????}??

?????????//loadClassImpl中會調用的LoadMgr3的一些方法實現上面流程圖的邏輯，具體的代碼實現比較冗長，這里就不貼出來了??

?????????clazz?=?loadClassImpl(name,?resolve,?Integer.MAX_VALUE);??

?????????return?clazz;??

??????}??

??????finally??

??????{??

?????????if?(trace)??

?????????{??

????????????if?(clazz?!=?null)??

???????????????log.trace("loadClass?"?+?this?+?"?name="?+?name?+?"?class="?+?clazz?+?"?cl="?+?clazz.getClassLoader());??

????????????else??

???????????????log.trace("loadClass?"?+?this?+?"?name="?+?name?+?"?not?found");??

?????????}??

??????}??

???}??

有幾點結論可以加深一些印象：

JBoss做為Application Server可以部署ear包也可以war包。但是jboss在默認情況下處理ear和war是兩種class load機制。

當部署ear時，JBOSS默認使用我前面提到的class load機制。一個ear包里的所有的jar由一個UCL統一加載和管理

需要注意的是ear里的war的部署有點特別。它只是將自身添加到ucl的classpath域中，而war下的WEB-INF/lib/*.jar，則是由WebAppClassloader來加載

由于jboss對所有UCL的共享機制就會導致出現一些class的版本沖突問題，一些應用加載不到自己的應用需要的class。對于這個問題JBOSS提供了一些解決措施：http://community.jboss.org/wiki/ClassLoadingConfiguration。后面我會再整理一下此前我遇到過的一個class沖突的case和解決辦法。

Tomcat6/7 class loader機制
Tomcat class loader層次結構

Tomcat的class load機制較Jboss來說要簡單
當web應用需要load class時先調用WebAppClassloader的loadClass方法，loadClass內部邏輯如下：

調用findLoadedClass(String)檢查此class是否已經加載，如果以加載則直接返回，如果沒有則繼續做下一步。

調用system class loader的loadClass的方法，這樣可以加載到JDK核心的類，如果沒有找到符合的類則繼續做下一步。

如果WebAppClassloader的delegate屬性是true或者正在處理的class在過濾列表里，會先從父class loader中加載類。如果沒有則繼續做下一步。一般這一步不會執行。

WebAppClassloader在自己的類庫（WEB-INF/classes和WEB-INF/lib）中查找class。如果沒有則繼續做下一步。

如果前面第3步已經跳過這一步會繼續執行。如果前面第3步已經執行過，這一步就不會再執行。這一步的執行邏輯同第3步。

具體的代碼可以看WebAppClassloader.loadClass(..)

?

參考文檔：
http://community.jboss.org/wiki/JBossClassLoadingUseCases
http://community.jboss.org/wiki/ClassLoadingConfiguration
http://community.jboss.org/wiki/EnableClassloaderLogging
http://agapple.iteye.com/blog/791940

http://www.iteye.com/topic/826661

轉載于:https://www.cnblogs.com/lingxue3769/archive/2012/03/01/2375997.html

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的JBoss、Tomcat Classloader不完全分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。