JAVA 筆記 ClassLoader.getResourceAsStream() 與 Class.getResourceAsStream()的差別

原文位址為： JAVA 筆記 ClassLoader.getResourceAsStream() 與 Class.getResourceAsStream()的差別

    Class.getResourceAsStream() 會指定要加載的資源路徑與目前類所在包的路徑一緻。

     例如你寫了一個MyTest類在包com.test.mycode 下，那麼MyTest.class.

getResourceAsStream("name")

會在com.test.mycode包下查找相應的資源。

     如果這個name是以 '/' 開頭的，那麼就會從classpath的根路徑下開始查找。

    ClassLoader.getResourceAsStream()  無論要查找的資源前面是否帶'/' 都會從classpath的根路徑下查找。

    是以: MyTest.getClassLoader().getResourceAsStream("name") 和 

            MyTest.getClassLoader().getResourceAsStream("name") 的效果是一樣的。

   順便提下JAVA中類的加載器：

一共有三種加載器

bootstrap classloader ：負責加載JAVA核心類( jre 下lib和class目錄中的内容)

extension classloader ：負責加載JAVA擴充類(jre 下lib/ext 目錄中的内容)

system classloader ：負責加載應用指定的類 (環境變量classpath中配置的内容)

一個類的加載順序也是按上面的排列來的，這樣就能保證系統的類能先加載。

與此同時使用者也可以自己定義ClassLoader，用來加載特殊的資源。

這裡就涉及到 Class.getClassLoader()  和  Thread.currentThread.getContextClassLoader()的差別。

舉一個簡單的例子：

   假如某天JAVA給我們提供了一個叫 StartCamera 的類用來啟動電腦的标準攝像頭，并将這個類打包在一個jar中。

   正常情況下，我們要啟動攝像頭時隻需将這個jar配置到classpath中。系統啟動時system classloader會将這個類加載到應用中。

   但因為攝像頭的生産廠家不一樣，針對新的裝置會有多個不同的StartCamera實作，在應用中我們不知道實際的使用者會用到哪種。于是我們就自定義了一個ClassLoader，用來針對具體的裝置類型加載相應的StartCamera類。

   這樣一來就出現：優先加載我們定義的類，加載不到的情況下再加載系統的。 這樣的需求，是系統預設的父委托加載機制無法滿足的。

   Thread.currentThread.getContextClassLoader() 就是這樣産生的。 我們使用Thread.currentThread.setContextClassLoader() 可以為目前線程指定相應的ClassLoader，然後用get的方式來擷取。

   那麼上面的加載代碼就可能是這樣子的：

public  void useCamera(){

  StartCamera s =  this.findClassLoader().loadClass("StartCamera");

  s.start();

}

private ClassLoader findClassLoader(){

  ClassLoader loader = Thread.currentThread().getContextClassLoader();

   if(loader== null){

     loader = ClassLoader.getSystemClassLoader();

  }

   return loader;

}

轉載請注明本文位址： JAVA 筆記 ClassLoader.getResourceAsStream() 與 Class.getResourceAsStream()的差別