ClassLoader的理解
2015-02-15 19:42 248 0
出处:http://www.cnblogs.com/zhanjindong/p/3952445.html
默认的三个类加载器
Java默认是有三个ClassLoader，按层次关系从上到下依次是：
-
Bootstrap ClassLoader
-
Ext ClassLoader
-
System ClassLoader
Bootstrap ClassLoader是最顶层的ClassLoader,它比较特殊，是用C++编写集成在JVM中的，是JVM启动的时候用来加载一些核心类的，比如：rt.jar,resources.jar,charsets.jar,jce.jar等，可以运行下面代码看都有哪些:
URL\[\] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();
for (int i = 0; i < urls.length; i++) {
System.out.println(urls\[i\].toExternalForm());
}
其余两个ClassLoader都是继承自ClassLoader这个类。Java的类加载采用了一种叫做“双亲委托”的方式（稍后解释），所以除了Bootstrap ClassLoader其余的ClassLoader都有一个“父”类加载器， 不是通过集成，而是一种包含的关系。
//ClassLoader.java
public abstract class ClassLoader {
...
// The parent class loader for delegation
private ClassLoader parent;
...
“双亲委托”
所谓“双亲委托”就是当加载一个类的时候会先委托给父类加载器去加载，当父类加载器无法加载的时候再尝试自己去加载，所以整个类的加载是“自上而下”的，如果都没有加载到则抛出ClassNotFoundException异常。
上面提到Bootstrap ClassLoader是最顶层的类加载器，实际上Ext ClassLoader和System ClassLoader就是一开始被它加载的。
Ext ClassLoader称为扩展类加载器，负责加载Java的扩展类库，默认加载JAVA_HOME/jre/lib/ext/目录下的所有的jar（包括自己手动放进去的jar包）。
System ClassLoader叫做系统类加载器，负责加载应用程序classpath目录下的所有jar和class文件，包括我们平时运行jar包指定cp参数下的jar包。
运行下面的代码可以验证上面内容：
ClassLoader loader = Debug.class.getClassLoader();
while(loader != null) {
System.out.println(loader);
loader = loader.getParent();
}
System.out.println(loader);
“双亲委托”的作用
之所以采用“双亲委托”这种方式主要是为了安全性，避免用户自己编写的类动态替换Java的一些核心类，比如String，同时也避免了重复加载， 因为JVM中区分不同类，不仅仅是根据类名，相同的class文件被不同的ClassLoader加载就是不同的两个类，如果相互转型的话会抛java.lang.ClassCaseException.
自定义类加载器
除了上面说的三种默认的类加载器，用户可以通过继承ClassLoader类来创建自定义的类加载器，之所以需要自定义类加载器是因为有时候我们需要通过一些特殊的途径创建类，比如网络。
至于自定义类加载器是如何发挥作用的，ClassLoader类的loadClass方法已经把算法定义了：
protected synchronized Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
// First, check if the class has already been loaded
Class c = findLoadedClass(name);
if (c == null) {
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
>1. Invoke findLoadedClass(String) to check if the class has already been loaded.
>2. Invoke the loadClass method on the parent class loader. If the parent is null the class loader built-in to the virtual machine is used, instead.
>3. Invoke the findClass(String) method to find the class.
看上面的Javadoc可以知道，自定义的类加载器只要重载findClass就好了。
Context ClassLoader
首先Java中ClassLoader就上面提到的四种，Bootstrap ClassLoader，Ext ClassLoader，System ClassLoader以及用户自定义的,所以Context ClassLoader并不是一种新的类加载器，肯定是这四种的一种。
首先关于类的加载补充一点就是如果类A是被一个加载器加载的，那么类A中引用的B也是由这个加载器加载的(如果B还没有被加载的话)，通常情况下就是类B必须在类A的classpath下。
但是考虑多线程环境下不同的对象可能是由不同的ClassLoader加载的，那么当一个由ClassLoaderC加载的对象A从一个线程被传到 另一个线程ThreadB中，而ThreadB是由ClassLoaderD加载的，这时候如果A想获取除了自己的classpath以外的资源的话，它 就可以通过Thread.currentThread().getContextClassLoader()来获取线程上下文的ClassLoader了，一般就是ClassLoaderD了，可以通过Thread.currentThread().setContextClassLoader(ClassLoader)来显示的设置。
为什么要有Contex ClassLoader
之所以有Context ClassLoader是因为Java的这种“双亲委托”机制是有局限性的:
- 举网上的一个例子:
> JNDI为例，JNDI的类是由bootstrap ClassLoader从rt.jar中间载入的，但是JNDI具体的核心驱动是由正式的实现提供的，并且通常会处于-cp参数之下（注：也就是默认的 System ClassLoader管理），这就要求bootstartp ClassLoader去载入只有SystemClassLoader可见的类，正常的逻辑就没办法处理。怎么办呢？parent可以通过获得当前调用 Thread的方法获得调用线程的>Context ClassLoder 来载入类。
- 我上面提到的加载资源的例子。
Contex ClassLoader提供了一个突破这种机制的后门。
Context ClassLoader一般在一些框架代码中用的比较多，平时写代码的时候用类的ClassLoader就可以了。
