类加载器Classloader

“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到java虚拟机外部去实现，以便让引用程序自己决定如何去获取所需要的类。实现这个动作的代码模块被称为类加载器。

    类加载器(ClassLoader)用来加载 class字节码到 Java 虚拟机中。一般来说，Java 虚拟机使用 Java 类的方式如下：Java 源文件在经过 Javac之后就被转换成 Java 字节码文件(.class 文件)。类加载器负责读取 Java 字节代码，并转换成 java.lang.Class 类的一个实例。每一个这样的实例用来表示一个 Java 类。实际的情况可能更加复杂，比如 Java 字节代码可能是通过工具动态生成的，也可能是通过网络下载

    类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远远不限于类加载阶段。对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟中的唯一性。说通俗一些，比较两个类是否“相等”，只有在两个类是由同一个类加载器的前提之下才有意义，否则，即使这两个类来源于同一个class文件，只要加载它的类加载器不同，那这两个类必定不相等。这里所指的“相等”包括代表类的Class对象的equal方法、isAssignableFrom()、isInstance()方法及instance关键字返回的结果。

 

 

Bootstrap Loader  - 负责加载系统类 

这个类加载器负责将存放在<java_home>\lib目录中的，或者被-xbootclasspath参数所指定的路径中的，并且是虚拟机识别的类库加载到虚拟机内存中。启动类加载器无法被java程序猿直接引用。

ExtClassLoader  - 负责加载扩展类 

这个加载器负责加载<java_home>\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器

AppClassLoader  - 负责加载应用类 

这个类加载器是lassloader中的getsystemClassloader（）方法的返回值，所以一般也成它为系统类加载器。负责加载用户类路径上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中的默认的类加载器。

如果一个类加载器收到了类加载的请求，它首先不会自己去加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求时，子类加载器才会尝试自己去加载。

 

JVM在运行时会产生三个ClassLoader，Bootstrap ClassLoader、Extension ClassLoader和AppClassLoader.其中，Bootstrap是用C++编写的，我们在Java中看不到它，是null。它用来加载核心类库，在JVM源代码中这样写道：
static const char classpathFormat[] =
"%/lib/rt.jar:"
"%/lib/i18n.jar:"
"%/lib/sunrsasign.jar:"
"%/lib/jsse.jar:"
"%/lib/jce.jar:"
"%/lib/charsets.jar:"
"%/classes";
知道为什么不需要在classpath中加载这些类了吧？人家在JVM启动的时候就自动加载了，并且在运行过程中根本不能修改Bootstrap加载路径。
Extension ClassLoader用来加载扩展类，即/lib/ext中的类。
最后AppClassLoader才是加载Classpath的。
ClassLoader加载类用的是委托模型。即先让Parent类(而不是Super，不是继承关系)寻找，Parent找不到才自己找。看来ClassLoader还是蛮孝顺的。三者的关系为:AppClassLoader的Parent是ExtClassLoader，而ExtClassLoader的Parent为Bootstrap ClassLoader。加载一个类时，首先BootStrap先进行寻找，找不到再由ExtClassLoader寻找，最后才是AppClassLoader。
为什么要设计的这么复杂呢？其中一个重要原因就是安全性。比如在Applet中，如果编写了一个java.lang.String类并具有破坏性。假如不采用这种委托机制，就会将这个具有破坏性的String加载到了用户机器上，导致破坏用户安全。但采用这种委托机制则不会出现这种情况。因为要加载java.lang.String类时，系统最终会由Bootstrap进行加载，这个具有破坏性的String永远没有机会加载。
我们来看这段代码：
//A.java
public class A{
public static void main(String[] args){
A a=new A();
System.out.println(System.getProperty("java.ext.dirs"));
System.out.println(a.getClass().getClassLoader());
B b=new B();
b.print();
}
}
//B.java
public class B{
public void print(){
System.out.println(this.getClass().getClassLoader());
}
}
1、我们将它放在Classpath中，则打印出
sun.misc.Launcher$AppClassLoader@92e78c
sun.misc.Launcher$AppClassLoader@92e78c
可见都是由AppClassLoader来加载的。
2、我们将其放在%jre%/lib/ext/classes(即ExtClassLoader的加载目录。其加载/lib/ext中的jar文件或者子目录classes中的class文件)中。则会打印出：
sun.misc.Launcher$ExtClassLoader
sun.misc.Launcher$ExtClassLoader
3、我们将A.class放到%jre%/lib/ext/classes中，而将B.class放到classpaht中又会怎么样呢？结果是：
sun.misc.Launcher$ExtClassLoader
Exception in thread "main" java.lang.NoClassDefFoundError:B
at A.main(A.java:6)
怎么会这样呢？这其中有一个重要的问题：A类当然是由ExtClassLoader来加载的，B类要由哪个加载呢？B类要由调用它自己的类的类加载器(真拗口)。也就是说，A调用了B，所以B由A的类加载器ExtClassLoader来加载。ExtClassLoader根据委托机制，先拜托Bootstrap加载，Bootstrap没有找到。然后它再自己寻找B类，还是没找到，所以抛出异常。ExtClassLoader不会请求AppClassLoader来加载!你可能会想：这算什么问题，我把两个类放到一起不就行了？
呵呵，没这么简单。比如JDBC是核心类库，而各个数据库的JDBC驱动则是扩展类库或在classpath中定义的。所以JDBC由Bootstrap ClassLoader加载，而驱动要由AppClassLoader加载。等等，问题来了，Bootstrap不会请求AppClassLoader加载类啊。那么，他们怎么实现的呢？我就涉及到一个Context ClassLoader的问题，调用Thread.getContextClassLoader