当JVM（Java虚拟机）启动时，会形成由三个类加载器组成的初始类加载器层次结构：



       bootstrap classloader

       extension classloader

       system classloader



bootstrap classloader －引导（也称为原始）类加载器，它负责加载Java的核心类。在Sun的JVM中，在执行java的命令中使用-Xbootclasspath选项或使用 - D选项指定sun.boot.class.path系统属性值可以指定附加的类。这个加载器的是非常特殊的，它实际上不是 java.lang.ClassLoader的子类，而是由JVM自身实现的。大家可以通过执行以下代码来获得bootstrap classloader加载了那些核心类库：

   URL[] urls=sun.misc.Launcher.getBootstrapClassPath().getURLs();

   for (int i = 0; i < urls.length; i++) {

     System.out.println(urls.toExternalform());

   }

在我的计算机上的结果为：

文件:/C:/j2sdk1.4.1_01/jre/lib/endorsed/dom.jar

文件:/C:/j2sdk1.4.1_01/jre/lib/endorsed/sax.jar

文件:/C:/j2sdk1.4.1_01/jre/lib/endorsed/xalan-2.3.1.jar

文件:/C:/j2sdk1.4.1_01/jre/lib/endorsed/xercesImpl-2.0.0.jar

文件:/C:/j2sdk1.4.1_01/jre/lib/endorsed/xml-apis.jar

文件:/C:/j2sdk1.4.1_01/jre/lib/endorsed/xsltc.jar

文件:/C:/j2sdk1.4.1_01/jre/lib/rt.jar

文件:/C:/j2sdk1.4.1_01/jre/lib/i18n.jar

文件:/C:/j2sdk1.4.1_01/jre/lib/sunrsasign.jar

文件:/C:/j2sdk1.4.1_01/jre/lib/jsse.jar

文件:/C:/j2sdk1.4.1_01/jre/lib/jce.jar

文件:/C:/j2sdk1.4.1_01/jre/lib/charsets.jar

文件:/C:/j2sdk1.4.1_01/jre/classes

这时大家知道了为什么我们不需要在系统属性CLASSPATH中指定这些类库了吧，因为JVM在启动的时候就自动加载它们了。



extension classloader －扩展类加载器，它负责加载JRE的扩展目录（JAVA_HOME/jre/lib/ext或者由java.ext.dirs系统属性指定的）中JAR的类包。这为引入除Java核心类以外的新功能提供了一个标准机制。因为默认的扩展目录对所有从同一个JRE中启动的JVM都是通用的，所以放入这个目录的 JAR类包对所有的JVM和system classloader都是可见的。在这个实例上调用方法getParent()总是返回空值null，因为引导加载器bootstrap classloader不是一个真正的ClassLoader实例。所以当大家执行以下代码时：

   System.out.println(System.getProperty("java.ext.dirs"));

   ClassLoader extensionClassloader=ClassLoader.getSystemClassLoader().getParent();

   System.out.println("the parent of extension classloader : "+extensionClassloader.getParent());

结果为：

C:\j2sdk1.4.1_01\jre\lib\ext

the parent of extension classloader : null

extension classloader是system classloader的parent，而bootstrap classloader是extension classloader的parent，但它不是一个实际的classloader，所以为null。



system classloader －系统（也称为应用）类加载器，它负责在JVM被启动时，加载来自在命令java中的-classpath或者java.class.path系统属性或者 CLASSPATH*作系统属性所指定的JAR类包和类路径。总能通过静态方法ClassLoader.getSystemClassLoader()找到该类加载器。如果没有特别指定，则用户自定义的任何类加载器都将该类加载器作为它的父加载器。执行以下代码即可获得：

   System.out.println(System.getProperty("java.class.path"));

输出结果则为用户在系统属性里面设置的CLASSPATH。

classloader 加载类用的是全盘负责委托机制。所谓全盘负责，即是当一个classloader加载一个Class的时候，这个Class所依赖的和引用的所有 Class也由这个classloader负责载入，除非是显式的使用另外一个classloader载入；委托机制则是先让parent（父）类加载器 (而不是super，它与parent classloader类不是继承关系)寻找，只有在parent找不到的时候才从自己的类路径中去寻找。此外类加载还采用了cache机制，也就是如果 cache中保存了这个Class就直接返回它，如果没有才从文件中读取和转换成Class，并存入cache，这就是为什么我们修改了Class但是必须重新启动JVM才能生效的原因。





每个ClassLoader加载Class的过程是：

1.检测此Class是否载入过（即在cache中是否有此Class），如果有到8,如果没有到2

2.如果parent classloader不存在（没有parent，那parent一定是bootstrap classloader了），到4

3.请求parent classloader载入，如果成功到8，不成功到5

4.请求jvm从bootstrap classloader中载入，如果成功到8

5.寻找Class文件（从与此classloader相关的类路径中寻找）。如果找不到则到7.

6.从文件中载入Class，到8.

7.抛出ClassNotFoundException.

8.返回Class.



其中5.6步我们可以通过覆盖ClassLoader的findClass方法来实现自己的载入策略。甚至覆盖loadClass方法来实现自己的载入过程。



类加载器的顺序是：

先是bootstrap classloader，然后是extension classloader，最后才是system classloader。大家会发现加载的Class越是重要的越在靠前面。这样做的原因是出于安全性的考虑，试想如果system classloader“亲自”加载了一个具有破坏性的“java.lang.System”类的后果吧。这种委托机制保证了用户即使具有一个这样的类，也把它加入到了类路径中，但是它永远不会被载入，因为这个类总是由bootstrap classloader来加载的