前言

對(duì)spring boot本身啟動(dòng)原理的分析，請(qǐng)參考：http://www.dbjr.com.cn/article/141478.htm

Spring boot里的ClassLoader繼承關(guān)系
可以運(yùn)行下面提供的demo，分別在不同的場(chǎng)景下運(yùn)行，可以知道不同場(chǎng)景下的Spring boot應(yīng)用的ClassLoader繼承關(guān)系。

https://github.com/hengyunabc/spring-boot-inside/tree/master/demo-classloader-context

分三種情況：

在IDE里，直接run main函數(shù)
則Spring的ClassLoader直接是SystemClassLoader。ClassLoader的urls包含全部的jar和自己的target/classes

========= Spring Boot Application ClassLoader Urls =============
ClassLoader urls: sun.misc.Launcher$AppClassLoader@2a139a55
file:/Users/hengyunabc/code/java/spring-boot-inside/demo-classloader-context/target/classes/
file:/Users/hengyunabc/.m2/repository/org/springframework/cloud/spring-cloud-starter/1.1.9.RELEASE/spring-cloud-starter-1.1.9.RELEASE.jar
file:/Users/hengyunabc/.m2/repository/org/springframework/boot/spring-boot-starter/1.4.7.RELEASE/spring-boot-starter-1.4.7.RELEASE.jar
...

以fat jar運(yùn)行

mvn clean package
java -jar target/demo-classloader-context-0.0.1-SNAPSHOT.jar

執(zhí)行應(yīng)用的main函數(shù)的ClassLoader是LaunchedURLClassLoader，它的parent是SystemClassLoader。

========= ClassLoader Tree=============
org.springframework.boot.loader.LaunchedURLClassLoader@1218025c
- sun.misc.Launcher$AppClassLoader@6bc7c054
-- sun.misc.Launcher$ExtClassLoader@85ede7b

并且LaunchedURLClassLoader的urls是 fat jar里的BOOT-INF/classes!/目錄和BOOT-INF/lib里的所有jar。

========= Spring Boot Application ClassLoader Urls =============
ClassLoader urls: org.springframework.boot.loader.LaunchedURLClassLoader@1218025c
jar:file:/Users/hengyunabc/code/java/spring-boot-inside/demo-classloader-context/target/demo-classloader-context-0.0.1-SNAPSHOT.jar!/BOOT-INF/classes!/
jar:file:/Users/hengyunabc/code/java/spring-boot-inside/demo-classloader-context/target/demo-classloader-context-0.0.1-SNAPSHOT.jar!/BOOT-INF/lib/spring-boot-1.4.7.RELEASE.jar!/
jar:file:/Users/hengyunabc/code/java/spring-boot-inside/demo-classloader-context/target/demo-classloader-context-0.0.1-SNAPSHOT.jar!/BOOT-INF/lib/spring-web-4.3.9.RELEASE.jar!/
...

SystemClassLoader的urls是demo-classloader-context-0.0.1-SNAPSHOT.jar本身。

========= System ClassLoader Urls =============
ClassLoader urls: sun.misc.Launcher$AppClassLoader@6bc7c054
file:/Users/hengyunabc/code/java/spring-boot-inside/demo-classloader-context/target/demo-classloader-context-0.0.1-SNAPSHOT.jar

以解壓目錄運(yùn)行

mvn clean package
cd target
unzip demo-classloader-context-0.0.1-SNAPSHOT.jar -d demo
cd demo
java org.springframework.boot.loader.PropertiesLauncher

執(zhí)行應(yīng)用的main函數(shù)的ClassLoader是LaunchedURLClassLoader，它的parent是SystemClassLoader。

========= ClassLoader Tree=============
org.springframework.boot.loader.LaunchedURLClassLoader@4aa298b7
- sun.misc.Launcher$AppClassLoader@2a139a55
-- sun.misc.Launcher$ExtClassLoader@1b6d3586

LaunchedURLClassLoader的urls是解壓目錄里的BOOT-INF/classes/和/BOOT-INF/lib/下面的jar包。

========= Spring Boot Application ClassLoader Urls =============
ClassLoader urls: org.springframework.boot.loader.LaunchedURLClassLoader@4aa298b7
file:/Users/hengyunabc/code/java/spring-boot-inside/demo-classloader-context/target/demo/BOOT-INF/classes/
jar:file:/Users/hengyunabc/code/java/spring-boot-inside/demo-classloader-context/target/demo/BOOT-INF/lib/bcpkix-jdk15on-1.55.jar!/
jar:file:/Users/hengyunabc/code/java/spring-boot-inside/demo-classloader-context/target/demo/BOOT-INF/lib/bcprov-jdk15on-1.55.jar!/
jar:file:/Users/hengyunabc/code/java/spring-boot-inside/demo-classloader-context/target/demo/BOOT-INF/lib/classmate-1.3.3.jar!/

SystemClassLoader的urls只有當(dāng)前目錄：

========= System ClassLoader Urls =============
ClassLoader urls: sun.misc.Launcher$AppClassLoader@2a139a55
file:/Users/hengyunabc/code/java/spring-boot-inside/demo-classloader-context/target/demo/

其實(shí)還有兩種運(yùn)行方式：mvn spring-boot:run 和 mvn spring-boot:run -Dfork=true，但是比較少使用，不單獨(dú)討論。感覺(jué)興趣的話(huà)可以自行跑下。

總結(jié)spring boot里ClassLoader的繼承關(guān)系

在IDE里main函數(shù)執(zhí)行時(shí)，只有一個(gè)ClassLoader，也就是SystemClassLoader

在以fat jar運(yùn)行時(shí)，有一個(gè)LaunchedURLClassLoader，它的parent是SystemClassLoader

LaunchedURLClassLoader的urls是fat jar里的BOOT-INF/classes和BOOT-INF/lib下的jar。SystemClassLoader的urls是fat jar本身。

在解壓目錄（exploded directory）運(yùn)行時(shí)，和fat jar類(lèi)似，不過(guò)url都是目錄形式。目錄形式會(huì)有更好的兼容性。

spring boot 1.3. 和 1.4. 版本的區(qū)別

在spring boot 1.3.* 版本里

1. 應(yīng)用的類(lèi)和spring boot loader的類(lèi)都是打包在一個(gè)fat jar里
2. 應(yīng)用依賴(lài)的jar放在fat jar里的/lib下面。
3. 在spring boot 1.4.* 版本后

spring boot loader的類(lèi)放在fat jar里

1. 應(yīng)用的類(lèi)打包放在fat jar的BOOT-INF/classes目錄里
2. 應(yīng)用依賴(lài)的jar放在fat jar里的/lib下面。

spring boot 1.4的打包結(jié)構(gòu)改動(dòng)是這個(gè)commit引入的
https://github.com/spring-projects/spring-boot/commit/87fe0b2adeef85c842c009bfeebac1c84af8a5d7

這個(gè)commit的本意是簡(jiǎn)化classloader的繼承關(guān)系，以一種直觀的parent優(yōu)先的方式來(lái)實(shí)現(xiàn)LaunchedURLClassLoader，同時(shí)打包結(jié)構(gòu)和傳統(tǒng)的war包應(yīng)用更接近。

但是這個(gè)改動(dòng)引起了很多復(fù)雜的問(wèn)題，從上面我們分析的ClassLoader繼承關(guān)系就有點(diǎn)頭暈了。

目前的ClassLoader繼承關(guān)系帶來(lái)的一些影響

有很多用戶(hù)可能會(huì)發(fā)現(xiàn)，一些代碼在IDE里跑得很好，但是在實(shí)際部署運(yùn)行時(shí)不工作。很多時(shí)候就是ClassLoader的結(jié)構(gòu)引起的，下面分析一些案例。

demo.jar!/BOOT-INF/classes!/ 這樣子url不工作

因?yàn)閟pring boot是擴(kuò)展了標(biāo)準(zhǔn)的jar協(xié)議，讓它支持多層的jar in jar，還有directory in jar。參考spring boot應(yīng)用啟動(dòng)原理分析

在spring boot 1.3的時(shí)候盡管會(huì)有jar in jar，但是一些比較健壯的代碼可以處理這種情況，比如tomcat8自己就支持jar in jar。

但是絕大部分代碼都不會(huì)支持像demo.jar!/BOOT-INF/classes!/ 這樣子directory in jar的多重url，所以在spring boot1.4里，很多庫(kù)的代碼都會(huì)失效。

demo.jar!/META-INF/resources 下的資源問(wèn)題

在servlet 3.0規(guī)范里，應(yīng)用可以把靜態(tài)資源放在META-INF/resources下面，servlet container會(huì)支持讀取。但是從上面的繼承結(jié)果，我們可以發(fā)現(xiàn)一個(gè)問(wèn)題：

1. 應(yīng)用以fat jar來(lái)啟動(dòng)，啟動(dòng)embedded tomcat的ClassLoader是LaunchedURLClassLoader
2. LaunchedURLClassLoader的urls并沒(méi)有fat jar本身
3. 應(yīng)用的main函數(shù)所在的模塊的src/main/resources/META-INF/resources目錄被打包到了fat jar里，也就是demo.jar!/META-INF/resources
4. 應(yīng)用的fat jar是SystemClassLoader的url，也就是LaunchedURLClassLoader的parent

這樣子就造成了一些奇怪的現(xiàn)象：

1. 應(yīng)用直接用自己的ClassLoader.getResources()是可以獲取到META-INF/resources的資源的
2. 但是embedded tomcat并沒(méi)有把fat jar本身加入到它的 ResourcesSet 里，因?yàn)樗趩?dòng)時(shí)ClassLoader是LaunchedURLClassLoader，它只掃描自己的ClassLoader的urls
3. 應(yīng)用把資源放在其它的jar包的META-INF/resources下可以訪問(wèn)到，把資源放在自己的main函數(shù)的src/main/resources/META-INF/resources下時(shí)，訪問(wèn)不到了

另外，spring boot的官方j(luò)sp的例子只支持war的打包格式，不支持fat jar，也是由這個(gè)引起的。

getResource("") 和 getResources("") 的返回值的問(wèn)題

getResource("")的語(yǔ)義是返回ClassLoader的urls的第一個(gè)url，很多時(shí)候使用者以為這個(gè)就是它們自己的classes的目錄，或者是jar的url。

但是實(shí)際上，因?yàn)镃lassLoader加載urls列表時(shí)，有隨機(jī)性，和OS低層實(shí)現(xiàn)有關(guān)，并不能保證urls的順序都是一樣的。所以getResource("")很多時(shí)候返回的結(jié)果并不一樣。

但是很多庫(kù)，或者應(yīng)用依賴(lài)這個(gè)代碼來(lái)定位掃描資源，這樣子在spring boot下就不工作了。

另外，值得注意的是spring boot在三種不同形式下運(yùn)行，getResources("")返回的結(jié)果也不一樣。用戶(hù)可以自己改下demo里的代碼，打印下結(jié)果。

簡(jiǎn)而言之，不要依賴(lài)這兩個(gè)API，最好自己放一個(gè)資源來(lái)定位?；蛘咧苯永胹pring自身提供的資源掃描機(jī)制。

類(lèi)似 classpath*:**-service.xml 的通配問(wèn)題

用戶(hù)有多個(gè)代碼模塊，在不同模塊下都放了多個(gè)*-service.xml的spring配置文件。

用戶(hù)如果使用類(lèi)似classpath*:**-service.xml的通配符來(lái)加載資源的話(huà)，很有可能出現(xiàn)在IDE里跑時(shí)，可以正確加載，但是在fat jar下，卻加載不到的問(wèn)題。

從spring自己的文檔可以看到相關(guān)的解析：

https://docs.spring.io/spring/docs/4.3.9.RELEASE/javadoc-api/org/springframework/core/io/support/PathMatchingResourcePatternResolver.html

WARNING: Note that “classpath:” when combined with Ant-style patterns will only work reliably with at least one root directory before the pattern starts, unless the actual target files reside in the file system. This means that a pattern like “classpath:*.xml” will not retrieve files from the root of jar files but rather only from the root of expanded directories. This originates from a limitation in the JDK's ClassLoader.getResources() method which only returns file system locations for a passed-in empty String (indicating potential roots to search). This ResourcePatternResolver implementation is trying to mitigate the jar root lookup limitation through URLClassLoader introspection and “java.class.path” manifest evaluation; however, without portability guarantees.

就是說(shuō)使用 classpath*來(lái)匹配其它的jar包時(shí)，需要有一層目錄在前面，不然的話(huà)是匹配不到的，這個(gè)是ClassLoader.getResources() 函數(shù)導(dǎo)致的。

因?yàn)樵贗DE里跑時(shí)，應(yīng)用所依賴(lài)的其它模塊通常就是一個(gè)classes目錄，所以通常沒(méi)有問(wèn)題。

但是當(dāng)以fat jar來(lái)跑時(shí)，其它的模塊都被打包為一個(gè)jar，放在BOOT-INF/lib下面，所以這時(shí)通配就會(huì)失敗。

總結(jié)

1. 這個(gè)新的BOOT-INF打包格式有它的明顯好處：更清晰，更接近war包的格式。
2. spring boot的ClassLoader的結(jié)構(gòu)修改帶來(lái)的復(fù)雜問(wèn)題，并非當(dāng)初修改的人所能預(yù)見(jiàn)的
3. 很多問(wèn)題需要理解spring boot的ClassLoader結(jié)構(gòu)，否則不能找到根本原因

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論