使用this.getClass().getResource()獲取文件時遇到的坑

最近在工作中遇到需要讀取配置文件，然后第一想法就是將文件放到項目的resources目錄下,

然后使用：

String fileName = "config/zh.md"
String path = this.getClass().getResource("/").getPath()  + fileName;
System.out.println(path);// D:/example/exam01/target/classes/config/zh.md

在IDE工具中開發(fā)及Debug時一切都正常，但是打成Jar包發(fā)布到線上時就會出現(xiàn)java.io.FileNotFoundException

java.io.FileNotFoundException: file:/usr/local/exam01-1.0-SNAPSHOT.jar!/BOOT-INF/classes!/config/zh.md (No such file or directory)

錯誤信息也已經(jīng)很明顯了，就是因為文件不存在，但是在IDE中是可以正常運行了，那為什么打成jar包放到服務器中就不行了呢？

仔細檢查報錯路徑發(fā)現(xiàn)在磁盤確實不存在這樣一條路徑，因為路徑從 .../exam01-1.0-SNAPSHOT.jar/...開始，后面的文件路徑都是打到Jar包中的，磁盤沒有后面 .../BOOT-INF/classes!/config/zh.md這樣的目錄；

在Jar包中的文件在磁盤是沒有實際路徑的，所以這時候通過 this.getClass()..getResource() 無法獲取文件。

解決方式一

直接將需要的文件上傳到服務器指定的文件夾下，如果把文件路徑寫死，就太low了，也不符合編碼規(guī)范。

而且存在各種隱患例如：不同的環(huán)境發(fā)布到不同的服務器上，開發(fā)一個服務器，測試一個服務器，生產(chǎn)一個服務器，每個服務器中都要上傳一份；如果誤刪或者遷移項目忘記遷移這個文件就麻煩了；

解決方式二

可以通過 this.getClass()..getResourceAsStream("/config/zh.md") 能夠正常獲取到文件流。

xxx.class.getResource("") 和 xxx.class.getClassLoader().getResource("")

上面問題已經(jīng)解決了，我們看下xxx.class.getResource("") 和 **xxx.class.getClassLoader().getResource("")**的區(qū)別；

1.其實

class.getResource("/") == class.getClassLoader().getResource("");

Class.getResource和ClassLoader.getResource本質(zhì)上是一樣的，都是使用ClassLoader.getResource加載資源的。

對于Class.getResource：

先獲取文件的路徑path，不以’/‘開頭時，默認是從此類所在的包下取資源；path以’/'開頭時，則是從項目的ClassPath根下獲取資源。

對于ClassLoader.getResource：

同樣先獲取文件的路徑，path不以’/'開頭時，首先通過雙親委派機制，使用的逐級向上委托的形式加載的，最后發(fā)現(xiàn)雙親沒有加載到文件，最后通過當前類加載classpath根下資源文件。

對于getResource("/")，’/'表示Boot ClassLoader中的加載范圍，因為這個類加載器是C++實現(xiàn)的，所以加載范圍為null。

2.以上兩種方法返回的都是 java.net.URL對象

如果需要得到相應的String類型，可以用以下方法：

xxx.class.getResource("").getPath();

xxx.class.getResource("").getFile();

或者通過

InputStream input = getClass().getClassLoader().getResourceAsStream("config\\config.properties");

獲取IO流;

3.類加載器ClassLoader

我們都知道 Java 文件被運行，第一步，需要通過 javac 編譯器編譯為 class 文件；第二步，JVM 運行 class 文件，實現(xiàn)跨平臺。

而 JVM 虛擬機第一步肯定是 加載 class 文件，所以，類加載器實現(xiàn)的就是（來自《深入理解Java虛擬機》）：

通過一個類的全限定名來獲取描述此類的二進制字節(jié)流

類加載器有幾個重要的特性：

• 每個類加載器都有自己的預定義的搜索范圍，用來加載 class 文件；
• 每個類和加載它的類加載器共同確定了這個類的唯一性，也就是說如果一個 class 文件被不同的類加載器加載到了 JVM 中， 那么這兩個類就是不同的類，雖然他們都來自同一份 class 文件；

3.1 雙親委派模型

• 所有的類加載器都是有層級結構的，每個類加載器都有一個父類類加載器（通過組合實現(xiàn)，而不是繼承），除了啟動類加載器（Bootstrap ClassLoader）
• 當一個類加載器接收到一個類加載請求時，首先將這個請求委派給它的父加載器去加載，所以每個類加載請求最終都會傳遞到頂層的啟動類加載器，如果父加載器無法加載時，子類加載器才會去嘗試自己去加載；

通過雙親委派模型就實現(xiàn)了類加載器的三個特性：

• 委派（delegation）：子類加載器委派給父類加載器加載；
• 可見性（visibility）：子類加載器可訪問父類加載器加載的類，父類不能訪問子類加載器加載的類；
• 唯一性（uniqueness）：可保證每個類只被加載一次，比如 Object 類是被 Bootstrap ClassLoader 加載的，因為有了雙親委派模型，所有的 Object 類加載請求都委派到了 Bootstrap ClassLoader，所以保證了只被加載一次。

3.2 Java 中的類加載器

從 JVM 虛擬機的角度來看，只存在兩種不同的類加載器：

• 啟動類加載器（Bootstrap ClassLoader），是虛擬機自身的一部分；
• 所有其他的類加載器，獨立于虛擬機外部，都繼承自抽象類 java.lang.ClassLoader

而絕大多數(shù) Java 應用都會用到如下 3 中系統(tǒng)提供的類加載器：

• 啟動類加載器（Bootstrap/Primordial/NULL ClassLoader）：頂層的類加載器，沒有父類加載器。負責加載 /lib 目錄下的，或則被 -Xbootclasspath 參數(shù)所指定路徑中的，

并被 JVM 識別的（僅按文件名識別，如 rt.jar，名字不符合的類庫即使放在 lib 目錄也不會被加載）類庫加載到虛擬機內(nèi)存中。所有被 Bootstrap classloader 加載的類，

它的 Class.getClassLoader 方法返回的都是 null，所以也稱作 NULL ClassLoader。

• 擴展類加載器（Extension CLassLoader）：由 sun.misc.Launcher$ExtClassLoader 實現(xiàn)，負責加載 <JAVA_HOME>/lib/ext 目錄下，或被 java.ext.dirs 系統(tǒng)變量所指定的目錄下的所有類庫；
• 應用程序類加載器（Application/System ClassLoader）：由 sun.misc.Launcher$AppClassLoader 實現(xiàn)。它是 ClassLoader.getSystemClassLoader() 方法的默認返回值，

所以也稱為系統(tǒng)類加載器（System ClassLoader）。它負責加載 classpath 下所指定的類庫，如果應用程序沒有自定義過自己的類加載器，一般情況下這個就是程序中默認的類加載器。

如下，就是 Java 程序中的類加載器層級結構圖：

總結

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論