一案例驱动
二源码分析
三类加载器ClassLoader
四总结
五参考
一案例驱动
最近加载文件的时候遇到了一个问题，很有意思！ 具体看下面案例代码

public class TestClassLoader {public static void main(String[] args) {System.out.println(TestClassLoader.class.getResource("ehcache.xml"));System.out.println(TestClassLoader.class.getResource("/ehcache.xml"));System.out.println();System.out.println(TestClassLoader.class.getClassLoader().getResource("ehcache.xml"));System.out.println(TestClassLoader.class.getClassLoader().getResource("/ehcache.xml"));}
}

file:/C:/myroad/utalitityUtils/target/classes/com/zsk/java/
file:/C:/myroad/utalitityUtils/target/classes/

file:/C:/myroad/utalitityUtils/target/classes/
null

那这两种方式有什么区别呢？下面跟源码一探究竟。
二源码分析
首先我们跟一下这段源码：

TestClassLoader.class.getResource("ehcache.xml")

 public java.net.URL getResource(String name) {name = resolveName(name);ClassLoader cl = getClassLoader0();// 获取加载该Class的ClassLoader，sun.misc.Launcher$AppClassLoader@18b4aac2if (cl==null) { //如果加载该Class的ClassLoader为null，则表示这是一个系统class// A system class.return ClassLoader.getSystemResource(name); //如果是系统class}return cl.getResource(name);//调用ClassLoader的getResource方法}

下面是ClassLoader的getResource方法

public URL getResource(String name) {URL url;if (parent != null) {//这里的parent为sun.misc.Launcher$ExtClassLoader@7d4793a8url = parent.getResource(name);//这里是一个递归调用，再次进入之后parent为null} else {url = getBootstrapResource(name);//到达系统启动类加载器}if (url == null) {//系统启动类加载器没有加载到，递归回退到第一次调用然后是扩展类加载器url = findResource(name);}return url;//最后如果都没有加载到，双亲委派加载失败，则加载应用本身自己的加载器。}

关于上面的

sun.misc.Launcher$AppClassLoader@18b4aac2

sun.misc.Launcher$ExtClassLoader@7d4793a8

后面原理会详细介绍，源码没看明白，也许看了下面的原理 就豁然开朗了。

下面我们跟一下getClassLoader源码看一下调用过程：

System.out.println(TestClassLoader.class.getClassLoader().getResource(""));

    public URL getResource(String name) {URL url;if (parent != null) {url = parent.getResource(name);} else {url = getBootstrapResource(name);}if (url == null) {url = findResource(name);}return url;}

可以发现其实，Class.getResource和ClassLoader.getResource 最终调用的是ClassLoader 类的getResource方法。只不过Class.getResource是先调用Class 的 getResource 方法，在这个getResource 方法中，再去调用ClassLoader 类的getResource方法

那么Class类中的getResource方法做了什么呢，主要的一句是 name = resolveName(name);

我们看一下这个代码实现：

 private String resolveName(String name) {if (name == null) {return name;}if (!name.startsWith("/")) {  //对于不以/开头的文件，Class<?> c = this;   //获取当前加载类的完整的类路径，我这里是com.zsk.java.TestClassLoaderwhile (c.isArray()) {c = c.getComponentType();}String baseName = c.getName();int index = baseName.lastIndexOf('.');//找到文件的包名称if (index != -1) {name = baseName.substring(0, index).replace('.', '/')+"/"+name;//将包名称中的.替换为/ 并在最后加上/ 文件名}} else {name = name.substring(1);  //对于/开头的文件名，会只保留文件名称部分。}return name;}

TestClassLoader.class.getResource("")
Class类中的getResource方法返回的是com/zsk/java/

ClassLoader类中的getResource方法返回的是 file:/C:/myroad/utalitityUtils/target/classes/com/zsk/java/

TestClassLoader.class.getResource("/")
Class类中的getResource方法返回的是""

ClassLoader类中的getResource方法返回的是 file:/C:/myroad/utalitityUtils/target/classes/

这也就解释了，为什么我们放在resource文件夹中的文件，第一个返回null ，而第二个可以正常访问了。

（JDK设置这样的规则，是很好理解的，path不以’/‘开头时，我们就能获取与当前类所在的路径相同的资源文件，而以’/'开头时可以获取ClassPath根下任意路径的资源。）

TestClassLoader.class.getClassLoader().getResource("")
ClassLoader类中的getResource方法返回的是 file:/C:/myroad/utalitityUtils/target/classes/

TestClassLoader.class.getClassLoader().getResource("/")
ClassLoader类中的getResource方法返回的是 null

对于ClassLoader.getResource， 直接调用的就是ClassLoader 类的getResource方法，那么对于getResource("")，path不以’/‘开头时，首先通过双亲委派机制，使用的逐级向上委托的形式加载的，最后发现双亲没有加载到文件，最后通过当前类加载classpath根下资源文件。对于getResource("/")，’/'表示Boot ClassLoader中的加载范围，因为这个类加载器是C++实现的，所以加载范围为null。

三类加载器ClassLoader

1、类加载器（ClassLoader）

我们都知道 Java 文件被运行，第一步，需要通过 javac 编译器编译为 class 文件；第二步，JVM 运行 class 文件，实现跨平台。而 JVM 虚拟机第一步肯定是 加载 class 文件，所以，类加载器实现的就是（来自《深入理解Java虚拟机》）：

通过一个类的全限定名来获取描述此类的二进制字节流

类加载器有几个重要的特性：

每个类加载器都有自己的预定义的搜索范围，用来加载 class 文件；
每个类和加载它的类加载器共同确定了这个类的唯一性，也就是说如果一个 class 文件被不同的类加载器加载到了 JVM 中，那么这两个类就是不同的类，虽然他们都来自同一份 class 文件；
双亲委派模型。
2.1 双亲委派模型

所有的类加载器都是有层级结构的，每个类加载器都有一个父类类加载器（通过组合实现，而不是继承），除了启动类加载器（Bootstrap ClassLoader）；
当一个类加载器接收到一个类加载请求时，首先将这个请求委派给它的父加载器去加载，所以每个类加载请求最终都会传递到顶层的启动类加载器，如果父加载器无法加载时，子类加载器才会去尝试自己去加载；
通过双亲委派模型就实现了类加载器的三个特性：

委派（delegation）：子类加载器委派给父类加载器加载；
可见性（visibility）：子类加载器可访问父类加载器加载的类，父类不能访问子类加载器加载的类；
唯一性（uniqueness）：可保证每个类只被加载一次，比如 Object 类是被 Bootstrap ClassLoader 加载的，因为有了双亲委派模型，所有的 Object 类加载请求都委派到了 Bootstrap ClassLoader，所以保证了只被加载一次。
以上就是类加载器的一些特性，那么在 Java 中类加载器是如何实现的呢？

2.2 Java 中的类加载器

从 JVM 虚拟机的角度来看，只存在两种不同的类加载器：

启动类加载器（Bootstrap ClassLoader），是虚拟机自身的一部分；
所有其他的类加载器，独立于虚拟机外部，都继承自抽象类 java.lang.ClassLoader。
而绝大多数 Java 应用都会用到如下 3 中系统提供的类加载器：

启动类加载器（Bootstrap/Primordial/NULL ClassLoader）：顶层的类加载器，没有父类加载器。负责加载 /lib 目录下的，或则被 -Xbootclasspath 参数所指定路径中的，并被 JVM 识别的（仅按文件名识别，如 rt.jar，名字不符合的类库即使放在 lib 目录也不会被加载）类库加载到虚拟机内存中。所有被 Bootstrap classloader 加载的类，它的 Class.getClassLoader 方法返回的都是 null，所以也称作 NULL ClassLoader。
扩展类加载器（Extension CLassLoader）：由 sun.misc.Launcher$ExtClassLoader实现，负责加载<JAV{A}_{H}OME>/lib/ext目录下，或被java.ext.dirs系统变量所指定的目录下的所有类库；应用程序类加载器（Application/SystemClassLoader）：由sun.misc.Launcher$AppClassLoader 实现。它是 ClassLoader.getSystemClassLoader() 方法的默认返回值，所以也称为系统类加载器（System ClassLoader）。它负责加载 classpath 下所指定的类库，如果应用程序没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
如下，就是 Java 程序中的类加载器层级结构图：

以上，我们介绍了 Java 系统的类加载器，

四总结
最后进行一个总结，Class.getResource和ClassLoader.getResource的区别，就是在加载资源文件的时候，加载方式的不同，

class.getResource("/") == class.getClassLoader().getResource("")
其实，Class.getResource和ClassLoader.getResource本质上是一样的，都是使用ClassLoader.getResource加载资源的。

Class.getResource真正调用ClassLoader.getResource方法之前，会先获取文件的路径（path不以’/‘开头时，默认是从此类所在的包下取资源；path以’/'开头时，则是从项目的ClassPath根下获取资源）。

ClassLoader.getResource方法会通过双亲委派机制，先委派双亲去加载类，如果双亲没有加载到，则再由自己加载。