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;
}