Tomcat?Catalina為什么不new出來(lái)原理解析
一、Catalina為什么不new出來(lái)?
掌握了Java的類加載器和雙親委派機(jī)制,現(xiàn)在我們就可以回答正題上來(lái)了,Tomcat的類加載器是怎么設(shè)計(jì)的?
1.Web容器的特性
Web容器有其自身的特殊性,所以在類加載器這塊是不能完全使用JVM的類加載器的雙親委派機(jī)制的。在Web容器中我們應(yīng)該要滿足如下的特性:
隔離性:
部署在同一個(gè)Web容器上的兩個(gè)Web應(yīng)用程序所使用的Java類庫(kù)可以實(shí)現(xiàn)相互隔離。設(shè)想一下,兩個(gè)Web應(yīng)用,一個(gè)使用了Spring3.0,另一個(gè)使用了新的的5.0,應(yīng)用服務(wù)器使用一個(gè)類加載器,Web應(yīng)用將會(huì)因?yàn)閖ar包覆蓋而無(wú)法啟動(dòng)。
靈活性:
Web應(yīng)用之間的類加載器相互獨(dú)立,那么就能針對(duì)一個(gè)Web應(yīng)用進(jìn)行重新部署,此時(shí)Web應(yīng)用的類加載器會(huì)被重建,而且不會(huì)影響其他的Web應(yīng)用。如果采用一個(gè)類加載器,類之間的依賴是雜亂復(fù)雜的,無(wú)法完全移出某個(gè)應(yīng)用的類。
性能:
性能也是一個(gè)比較重要的點(diǎn)。部署在同一個(gè)Web容器上的兩個(gè)Web應(yīng)用程序所使用的Java類庫(kù)可以互相共享。這個(gè)需求也很常見(jiàn),例如,用戶可能有10個(gè)使用Spring框架的應(yīng)用程序部署在同一臺(tái)服務(wù)器上,如果把10份Spring分別存放在各個(gè)應(yīng)用程序的隔離目錄中,將會(huì)是很大的資源浪費(fèi)——這主要倒不是浪費(fèi)磁盤空間的問(wèn)題,而是指類庫(kù)在使用時(shí)都要被加載到Web容器的內(nèi)存,如果類庫(kù)不能共享,虛擬機(jī)的方法區(qū)就會(huì)很容易出現(xiàn)過(guò)度膨脹的風(fēng)險(xiǎn)。
2.Tomcat類加載器結(jié)構(gòu)
明白了Web容器的類加載器有多個(gè),再來(lái)看tomcat的類加載器結(jié)構(gòu)。
首先上張圖,整體看下tomcat的類加載器:
可以看到在原先的java類加載器基礎(chǔ)上,tomcat新增了幾個(gè)類加載器,包括3個(gè)基礎(chǔ)類加載器和每個(gè)Web應(yīng)用的類加載器,其中3個(gè)基礎(chǔ)類加載器可在conf/catalina.properties中配置,具體介紹下:
Common:
以應(yīng)用類加載器為父類,是tomcat頂層的公用類加載器,其路徑由conf/catalina.properties中的common.loader指定,默認(rèn)指向${catalina.base}/lib下的包。
Catalina:
以Common類加載器為父類,是用于加載Tomcat應(yīng)用服務(wù)器的類加載器,其路徑由server.loader指定,默認(rèn)為空,此時(shí)tomcat使用Common類加載器加載應(yīng)用服務(wù)器。
Shared:
以Common類加載器為父類,是所有Web應(yīng)用的父類加載器,其路徑由shared.loader指定,默認(rèn)為空,此時(shí)tomcat使用Common類加載器作為Web應(yīng)用的父加載器。
Web應(yīng)用:
以Shared類加載器為父類,加載/WEB-INF/classes目錄下的未壓縮的Class和資源文件以及/WEB-INF/lib目錄下的jar包,該類加載器只對(duì)當(dāng)前Web應(yīng)用可見(jiàn),對(duì)其他Web應(yīng)用均不可見(jiàn)。
默認(rèn)情況下,Common、Catalina、Shared類加載器是同一個(gè),但可以配置3個(gè)不同的類加載器,使他們各司其職。
首先,Common類加載器復(fù)雜加載Tomcat應(yīng)用服務(wù)器內(nèi)部和Web應(yīng)用均可見(jiàn)的類,如Servlet規(guī)范相關(guān)包和一些通用工具包。
其次,Catalina類加載器負(fù)責(zé)只有Tomcat應(yīng)用服務(wù)器內(nèi)部可見(jiàn)的類,這些類對(duì)Web應(yīng)用不可見(jiàn)。比如,想實(shí)現(xiàn)自己的會(huì)話存儲(chǔ)方案,而且該方案依賴了一些第三方包,當(dāng)然是不希望這些包對(duì)Web應(yīng)用可見(jiàn),這時(shí)可以配置server.load,創(chuàng)建獨(dú)立的Catalina類加載器。
再次,Shared類復(fù)雜加載Web應(yīng)用共享類,這些類tomcat服務(wù)器不會(huì)依賴
3.Tomcat源碼分析
3.1 CatalinClassLoader
首先來(lái)看看Tomcat的類加載器的繼承結(jié)構(gòu)
可以看到繼承的結(jié)構(gòu)和我們上面所寫的類加載器的結(jié)構(gòu)不同。
大家需要注意雙親委派機(jī)制并不是通過(guò)繼承來(lái)實(shí)現(xiàn)的,而是相互之間組合而形成的。
所以AppClassLoader沒(méi)有繼承自 ExtClassLoader,WebappClassLoader也沒(méi)有繼承自AppClassLoader。
至于Common ClassLoader ,Shared ClassLoader,Catalina ClassLoader則是在啟動(dòng)時(shí)初始化的三個(gè)不同名字的URLClassLoader。
先來(lái)看看Bootstrap#init()方法。init方法會(huì)調(diào)用initClassLoaders,同樣也會(huì)將Catalina ClassLoader設(shè)置到當(dāng)前線程設(shè)置到當(dāng)前線程,進(jìn)入initClassLoaders來(lái)看看。
private void initClassLoaders() { try { // 創(chuàng)建 commonLoader catalinaLoader sharedLoader commonLoader = createClassLoader("common", null); if (commonLoader == null) { // no config file, default to this loader - we might be in a 'single' env. commonLoader = this.getClass().getClassLoader(); } // 默認(rèn)情況下 server.loader 和 shared.loader 都為空則會(huì)返回 commonLoader 類加載器 catalinaLoader = createClassLoader("server", commonLoader); sharedLoader = createClassLoader("shared", commonLoader); } catch (Throwable t) { handleThrowable(t); log.error("Class loader creation threw exception", t); System.exit(1); } }
我們可以看到在initClassLoaders()方法中完成了CommonClassLoader, CatalinaClassLoader,和SharedClassLoader的創(chuàng)建,而且進(jìn)入到createClassLoader方法中。
可以看到這三個(gè)基礎(chǔ)類加載器所加載的資源剛好對(duì)應(yīng)conf/catalina.properties中的common.loader,server.loader,shared.loader
3.2 層次結(jié)構(gòu)
Common/Catalina/Shared ClassLoader的創(chuàng)建好了之后就會(huì)維護(hù)相互之間的組合關(guān)系
其實(shí)也就是設(shè)置了父加載器
3.3 具體的加載過(guò)程
源碼比較長(zhǎng),直接進(jìn)入到 WebappClassLoaderBase
中的 LoadClass方法
@Override public Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { if (log.isDebugEnabled()) { log.debug("loadClass(" + name + ", " + resolve + ")"); } Class<?> clazz = null; // Log access to stopped class loader checkStateForClassLoading(name); // (0) Check our previously loaded local class cache // 檢查WebappClassLoader中是否加載過(guò)此類 clazz = findLoadedClass0(name); if (clazz != null) { if (log.isDebugEnabled()) { log.debug(" Returning class from cache"); } if (resolve) { resolveClass(clazz); } return clazz; } // (0.1) Check our previously loaded class cache // 如果第一步?jīng)]有找到,則繼續(xù)檢查JVM虛擬機(jī)中是否加載過(guò)該類 clazz = findLoadedClass(name); if (clazz != null) { if (log.isDebugEnabled()) { log.debug(" Returning class from cache"); } if (resolve) { resolveClass(clazz); } return clazz; } // (0.2) Try loading the class with the bootstrap class loader, to prevent // the webapp from overriding Java SE classes. This implements // SRV.10.7.2 // 如果前兩步都沒(méi)有找到,則使用系統(tǒng)類加載該類(也就是當(dāng)前JVM的ClassPath)。 // 為了防止覆蓋基礎(chǔ)類實(shí)現(xiàn),這里會(huì)判斷class是不是JVMSE中的基礎(chǔ)類庫(kù)中類。 String resourceName = binaryNameToPath(name, false); ClassLoader javaseLoader = getJavaseClassLoader(); boolean tryLoadingFromJavaseLoader; try { // Use getResource as it won't trigger an expensive // ClassNotFoundException if the resource is not available from // the Java SE class loader. However (see // https://bz.apache.org/bugzilla/show_bug.cgi?id=58125 for // details) when running under a security manager in rare cases // this call may trigger a ClassCircularityError. // See https://bz.apache.org/bugzilla/show_bug.cgi?id=61424 for // details of how this may trigger a StackOverflowError // Given these reported errors, catch Throwable to ensure any // other edge cases are also caught URL url; if (securityManager != null) { PrivilegedAction<URL> dp = new PrivilegedJavaseGetResource(resourceName); url = AccessController.doPrivileged(dp); } else { url = javaseLoader.getResource(resourceName); } tryLoadingFromJavaseLoader = (url != null); } catch (Throwable t) { // Swallow all exceptions apart from those that must be re-thrown ExceptionUtils.handleThrowable(t); // The getResource() trick won't work for this class. We have to // try loading it directly and accept that we might get a // ClassNotFoundException. tryLoadingFromJavaseLoader = true; } if (tryLoadingFromJavaseLoader) { try { clazz = javaseLoader.loadClass(name); if (clazz != null) { if (resolve) { resolveClass(clazz); } return clazz; } } catch (ClassNotFoundException e) { // Ignore } } // (0.5) Permission to access this class when using a SecurityManager if (securityManager != null) { int i = name.lastIndexOf('.'); if (i >= 0) { try { securityManager.checkPackageAccess(name.substring(0,i)); } catch (SecurityException se) { String error = sm.getString("webappClassLoader.restrictedPackage", name); log.info(error, se); throw new ClassNotFoundException(error, se); } } } // 檢查是否 設(shè)置了delegate屬性,設(shè)置為true,那么就會(huì)完全按照J(rèn)VM的"雙親委托"機(jī)制流程加載類。 boolean delegateLoad = delegate || filter(name, true); // (1) Delegate to our parent if requested if (delegateLoad) { if (log.isDebugEnabled()) { log.debug(" Delegating to parent classloader1 " + parent); } try { clazz = Class.forName(name, false, parent); if (clazz != null) { if (log.isDebugEnabled()) { log.debug(" Loading class from parent"); } if (resolve) { resolveClass(clazz); } return clazz; } } catch (ClassNotFoundException e) { // Ignore } } // (2) Search local repositories // 若是沒(méi)有委托,則默認(rèn)會(huì)首次使用WebappClassLoader來(lái)加載類。通過(guò)自定義findClass定義處理類加載規(guī)則。 // findClass()會(huì)去Web-INF/classes 目錄下查找類。 if (log.isDebugEnabled()) { log.debug(" Searching local repositories"); } try { clazz = findClass(name); if (clazz != null) { if (log.isDebugEnabled()) { log.debug(" Loading class from local repository"); } if (resolve) { resolveClass(clazz); } return clazz; } } catch (ClassNotFoundException e) { // Ignore } // (3) Delegate to parent unconditionally // 若是WebappClassLoader在/WEB-INF/classes、/WEB-INF/lib下還是查找不到class, // 那么無(wú)條件強(qiáng)制委托給System、Common類加載器去查找該類。 if (!delegateLoad) { if (log.isDebugEnabled()) { log.debug(" Delegating to parent classloader at end: " + parent); } try { clazz = Class.forName(name, false, parent); if (clazz != null) { if (log.isDebugEnabled()) { log.debug(" Loading class from parent"); } if (resolve) { resolveClass(clazz); } return clazz; } } catch (ClassNotFoundException e) { // Ignore } } } throw new ClassNotFoundException(name); }
Web應(yīng)用類加載器默認(rèn)的加載順序是:
- (1).先從緩存中加載;
- (2).如果沒(méi)有,則從JVM的Bootstrap類加載器加載;
- (3).如果沒(méi)有,則從當(dāng)前類加載器加載(按照WEB-INF/classes、WEB-INF/lib的順序);
- (4).如果沒(méi)有,則從父類加載器加載,由于父類加載器采用默認(rèn)的委派模式,所以加載順序是AppClassLoader、Common、Shared。
tomcat提供了delegate屬性用于控制是否啟用java委派模式,默認(rèn)false(不啟用),當(dāng)設(shè)置為true時(shí),tomcat將使用java的默認(rèn)委派模式,這時(shí)加載順序如下:
- (1).先從緩存中加載;
- (2).如果沒(méi)有,則從JVM的Bootstrap類加載器加載;
- (3).如果沒(méi)有,則從父類加載器加載,加載順序是AppClassLoader、Common、Shared。
- (4).如果沒(méi)有,則從當(dāng)前類加載器加載(按照WEB-INF/classes、WEB-INF/lib的順序)
以上就是Tomcat Catalina為什么不new出來(lái)原理解析的詳細(xì)內(nèi)容,更多關(guān)于Tomcat Catalina原理的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
Tomcat部署時(shí)war和war exploded區(qū)別及問(wèn)題匯總
這篇文章主要介紹了Tomcat部署時(shí)war和war exploded區(qū)別的相關(guān)資料,需要的朋友可以參考下2017-06-06tomcat啟動(dòng)報(bào)錯(cuò)jar not loaded的問(wèn)題
這篇文章主要介紹了tomcat啟動(dòng)報(bào)錯(cuò)jar not loaded的問(wèn)題,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2023-09-09如何在IntelliJ IDEA 2018上配置Tomcat并運(yùn)行第一個(gè)JavaWeb項(xiàng)目
這篇文章主要介紹了在IntelliJ IDEA 2018上配置Tomcat并運(yùn)行第一個(gè)JavaWeb項(xiàng)目,需要的朋友可以參考下2020-09-09詳解從源碼分析tomcat如何調(diào)用Servlet的初始化
這篇文章主要介紹了詳解從源碼分析tomcat如何調(diào)用Servlet的初始化,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2021-04-04Tomcat 7-dbcp配置數(shù)據(jù)庫(kù)連接池詳解
這篇文章主要介紹了Tomcat 7-dbcp配置數(shù)據(jù)庫(kù)連接池詳解的相關(guān)資料,需要的朋友可以參考下2017-04-04Centos7安裝配置tomcat9并設(shè)置自動(dòng)啟動(dòng)的方法
這篇文章主要介紹了Centos7安裝配置tomcat9并設(shè)置自動(dòng)啟動(dòng)的方法,小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,也給大家做個(gè)參考。一起跟隨小編過(guò)來(lái)看看吧2018-09-09Tomcat starup.bat腳本開(kāi)機(jī)自啟動(dòng)的實(shí)現(xiàn)
本文主要介紹了Tomcat starup.bat腳本開(kāi)機(jī)自啟動(dòng)的實(shí)現(xiàn),文中通過(guò)示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2022-04-04Linux下重啟多個(gè) tomcat 服務(wù)的腳本(推薦)
由于修改tomcat的配置文件或手動(dòng)操作數(shù)據(jù)庫(kù)數(shù)據(jù)后,tomcat的緩存和redis的緩存很嚴(yán)重,需要經(jīng)常重啟tomcat來(lái)釋放緩存,經(jīng)常就是手動(dòng)重啟。下面給大家分享Linux下重啟多個(gè) tomcat 服務(wù)的腳本,一起看看吧2017-06-06