Java基础—ClassLoader的理解

##默认的三个类加载器
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)`来显示的设置。

##为什么要有Context 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就可以了。

##参考链接
[http://stackoverflow.com/questions/1771679/difference-between-threads-context-class-loader-and-normal-classloader][1]

  [1]: http://stackoverflow.com/questions/1771679/difference-between-threads-context-class-loader-and-normal-classloader