深入Spring Boot：ClassLoader的繼承關係和影響

橫雲斷嶺發表於2018-12-09
Spring Boot繼承

前言

對spring boot本身啟動原理的分析，請參考：hengyunabc.github.io/spring-boot…

Spring boot裡的ClassLoader繼承關係

可以執行下面提供的demo，分別在不同的場景下執行，可以知道不同場景下的Spring boot應用的ClassLoader繼承關係。

github.com/hengyunabc/…

分三種情況：

在IDE裡，直接run main函式

則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執行

mvn clean package
java -jar target/demo-classloader-context-0.0.1-SNAPSHOT.jar
複製程式碼

執行應用的main函式的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
複製程式碼

以解壓目錄執行

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

執行應用的main函式的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只有當前目錄：

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

其實還有兩種執行方式：mvn spring-boot:run 和 mvn spring-boot:run -Dfork=true，但是比較少使用，不單獨討論。感覺興趣的話可以自行跑下。

總結spring boot裡ClassLoader的繼承關係

  • 在IDE裡main函式執行時，只有一個ClassLoader，也就是SystemClassLoader

  • 在以fat jar執行時，有一個LaunchedURLClassLoader，它的parent是SystemClassLoader

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

  • 在解壓目錄（exploded directory）執行時，和fat jar類似，不過url都是目錄形式。目錄形式會有更好的相容性。

spring boot 1.3.* 和 1.4.* 版本的區別

在spring boot 1.3.* 版本里

  • 應用的類和spring boot loader的類都是打包在一個fat jar裡
  • 應用依賴的jar放在fat jar裡的/lib下面。

在spring boot 1.4.* 版本後

  • spring boot loader的類放在fat jar裡
  • 應用的類打包放在fat jar的BOOT-INF/classes目錄裡
  • 應用依賴的jar放在fat jar裡的/lib下面。

spring boot 1.4的打包結構改動是這個commit引入的 github.com/spring-proj…

這個commit的本意是簡化classloader的繼承關係，以一種直觀的parent優先的方式來實現LaunchedURLClassLoader，同時打包結構和傳統的war包應用更接近。

但是這個改動引起了很多複雜的問題，從上面我們分析的ClassLoader繼承關係就有點頭暈了。

目前的ClassLoader繼承關係帶來的一些影響

有很多使用者可能會發現，一些程式碼在IDE裡跑得很好，但是在實際部署執行時不工作。很多時候就是ClassLoader的結構引起的，下面分析一些案例。

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

因為spring boot是擴充套件了標準的jar協議，讓它支援多層的jar in jar，還有directory in jar。參考spring boot應用啟動原理分析

在spring boot 1.3的時候儘管會有jar in jar，但是一些比較健壯的程式碼可以處理這種情況，比如tomcat8自己就支援jar in jar。

但是絕大部分程式碼都不會支援像demo.jar!/BOOT-INF/classes!/ 這樣子directory in jar的多重url，所以在spring boot1.4裡，很多庫的程式碼都會失效。

demo.jar!/META-INF/resources 下的資源問題

在servlet 3.0規範裡，應用可以把靜態資源放在META-INF/resources下面，servlet container會支援讀取。但是從上面的繼承結果，我們可以發現一個問題：

  • 應用以fat jar來啟動，啟動embedded tomcat的ClassLoader是LaunchedURLClassLoader
  • LaunchedURLClassLoader的urls並沒有fat jar本身
  • 應用的main函式所在的模組的src/main/resources/META-INF/resources目錄被打包到了fat jar裡，也就是demo.jar!/META-INF/resources
  • 應用的fat jar是SystemClassLoader的url，也就是LaunchedURLClassLoader的parent

這樣子就造成了一些奇怪的現象：

  • 應用直接用自己的ClassLoader.getResources()是可以獲取到META-INF/resources的資源的
  • 但是embedded tomcat並沒有把fat jar本身加入到它的 ResourcesSet 裡，因為它在啟動時ClassLoader是LaunchedURLClassLoader，它只掃描自己的ClassLoader的urls
  • 應用把資源放在其它的jar包的META-INF/resources下可以訪問到，把資源放在自己的main函式的src/main/resources/META-INF/resources下時，訪問不到了

另外，spring boot的官方jsp的例子只支援war的打包格式，不支援fat jar，也是由這個引起的。

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

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

但是實際上，因為ClassLoader載入urls列表時，有隨機性，和OS低層實現有關，並不能保證urls的順序都是一樣的。所以getResource("")很多時候返回的結果並不一樣。

但是很多庫，或者應用依賴這個程式碼來定位掃描資源，這樣子在spring boot下就不工作了。

另外，值得注意的是spring boot在三種不同形式下執行，getResources("")返回的結果也不一樣。使用者可以自己改下demo裡的程式碼，列印下結果。

簡而言之，不要依賴這兩個API，最好自己放一個資源來定位。或者直接利用spring自身提供的資源掃描機制。

類似 classpath*:**-service.xml 的通配問題

使用者有多個程式碼模組，在不同模組下都放了多個*-service.xml的spring配置檔案。

使用者如果使用類似classpath*:**-service.xml的萬用字元來載入資源的話，很有可能出現在IDE裡跑時，可以正確載入，但是在fat jar下，卻載入不到的問題。

從spring自己的文件可以看到相關的解析：

docs.spring.io/spring/docs…

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.

就是說使用 classpath*來匹配其它的jar包時，需要有一層目錄在前面，不然的話是匹配不到的，這個是ClassLoader.getResources() 函式導致的。

因為在IDE裡跑時，應用所依賴的其它模組通常就是一個classes目錄，所以通常沒有問題。

但是當以fat jar來跑時，其它的模組都被打包為一個jar，放在BOOT-INF/lib下面，所以這時通配就會失敗。

總結

  • 這個新的BOOT-INF打包格式有它的明顯好處：更清晰，更接近war包的格式。
  • spring boot的ClassLoader的結構修改帶來的複雜問題，並非當初修改的人所能預見的
  • 很多問題需要理解spring boot的ClassLoader結構，否則不能找到根本原因

微信公眾號

橫雲斷嶺的專欄

橫雲斷嶺的專欄

相關文章