一步一步深入jvm（4）—jvm classloader体系结构及加载原理
我们正常遇到这样的情况，自定义一个jar文件中包含一个class【类】文件。我们想重写这个类的话直接在工程中包名及类名一致就可行。
但是对于某些类文件例如String等一些类，在我们的工程中直接重写这些类，是调用不了的。这是什么原因呢？
这和java的类的加载机制有关，那到底java是怎么加载类文件？这个问题也是下文将阐述的问题。
首选要提到的是ClassLoader，那什么是ClassLoader？
ClassLoader负责将相应的类文件（即class文件）装载到内存中。jvm中存在多种类型的ClassLoader，主要分为4类：
(1)BootStrap[启动类加载器] 是最顶层的类加载器，它是由C++编写而成,并且已经内嵌到JVM中了,主要用来读取Java的核心类库JRE/lib/rt.jar、resources.jar、charsets.jar 等
(2)Extension ClassLoader[扩展类加载器] 是用来读取Java的扩展类库，读取JRE/lib/ext/*.jar
(3)App ClassLoader[应用类加载器] 是用来读取当前应用下CLASSPATH指定的所有jar包或目录的类文件【是用户自定义类装载器的缺省父装载器】。
(4)Custom ClassLoader[用户自定义类加载器] 是用户自定义编写的，它用来读取指定类文件
不同的类装载器，只能加载相应范围的类，哪怕是同包下的类，只要他们不属于同一类装载器，都是相互隔绝的。这对一些有安全隐患的类起到了安全隔离的作用。使它不能冒充系统类来破坏程序正常运作。
这些ClassLoader组成了jvm的ClassLoader的体系结构，如下图所示为。
从图中我们可以看出，当加载一个类的时候，是先检查是当前加载器是否已经加载该类，如已加载则返回。否则委托给它的父加载器检查是否已经加载，一直检查到BootStrap【启动类加载器】，如果还是没有发现该类被加载，则BootStrap【启动类加载器】尝试加载该类，加载成功则返回，如没有加载到则将委托还给子装载器，子类加载器继续加载，一直装载到最底层的ClassLoader【可能为App ClassLoader或者Custom ClassLoader，甚至可能为Extension ClassLoader】，如果没有装载到相应的类则抛出ClassNotFoundException。整个模型也称作双亲委派模型。
总结来说 双亲委派方式的类加载，指的是优先从顶层启动类加载器开始，自顶向下的方式加载类的模型 （参见图示）。
可能有点迷糊，我们结合一个实际的源码来说明该模型。
java中的Launcher类【在sun.misc包下】，它包含两个内部类AppClassLoader、ExtClassLoader，java通过这两个类完成对应用及扩展类文件的加载，它们继承URLClassLoader类，而URLClassLoader类继SecureClassLoader类，SecureClassLoader继承抽象类ClassLoader。
它们的类图关系如下
虽然AppClassLoader、ExtClassLoader都是继承于URLClassLoader，但是AppClassLoader的父加载器为ExtClassLoader【这里就不多讲了，可以看看源码就知道了】。而对于AppClassLoader、ExtClassLoader类中并未覆盖抽象类ClassLoader的loadClass方法。ClassLoader的loadClass的方法如下
protected synchronized Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
// 首选查看类是否已经被加载
Class c = findLoadedClass(name);
//没有被加载
if (c == null) {
try {
//如果父加载器不为空，父加载器查看该类是否被加载
if (parent != null) {
c = parent.loadClass(name, false);
} else {
//如果父加载器不存在调用BootStrap查看是否已被加载
c = findBootstrapClass0(name);
}
} catch (ClassNotFoundException e) {
// If still not found, then invoke findClass in order
// to find the class.
//如果顶级装载器BootStrap未发现已加载该类，增尝试加载该类
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
而findBootstrapClass0方法如下
private Class findBootstrapClass0(String name)
throws ClassNotFoundException
{
check();
if (!checkName(name))
throw new ClassNotFoundException(name);
return findBootstrapClass(name);
}
private native Class findBootstrapClass(String name)
throws ClassNotFoundException;
它是一个本地接口的方法时C++写的。
从源码中可以看出ClassLoader总是现从下往上查看类是否已被加载，然后从上往下尝试加载类。
一般自定类加载器时loadClass是不重写，而自定义加载器重写的是findClass。从源码中我们可以看出，所有加载器的顶级加载器为BootStrap【即父加载器不存时】，同时注意到的时出于安全等因素考虑， BootStrap不会加载 lib 存在的陌生类或jar ， 开发者通过将要加载的非 JDK 自身的类放置到此目录下期待启动类加载器加载是不可能的，其他类加载器无这样的限制 。
示例代码如下
public class classLoaderTest {
public static void main( String args[] ){
classLoaderTest t = new classLoaderTest();
System.out.print( t.getClass() );
System.out.println( t.getClass().getClassLoader() ) ;
System.out.println( t.getClass().getClassLoader().getParent() ) ;
System.out.println( t.getClass().getClassLoader().getParent().getParent() ) ;
}
}
类加载器查看如下
class classLoaderTest sun.misc.Launcher$AppClassLoader@82ba41 sun.misc.Launcher$ExtClassLoader@923e30 null
第二行的结果表示 classLoaderTest 的类的加载器为 AppClassLoader
第三行的结果表示 AppClassLoader的父加载器为 ExtClassLoader
第四行的结果null表示 ExtClassLoader 的父加载器为 BootStrap
整个的加载流程如下自定类classLoaderTest，创建该类对象时，先是AppClassLoader检查是否已经加载该类，AppClassLoader并未加载该类，AppClassLoader委托给ExtClassLoader，而ExtClassLoader也未发现已经装载该类ExtClassLoader将委托交给BootStrap，BootStrap也未发现。这时BootStrap将尝试加载classLoaderTest，BootStrap未加载到，将委托交还给ExtClassLoader，ExtClassLoader未加载到，将委托交还给AppClassLoader，AppClassLoader加载到该类，并创建classLoaderTest。
这里我们回到问题为什么对于String等类，在应用重写，为什么不能覆盖系统的String类型。
从双亲委派模型 中我们可以知道，String对象存在rt.jar中它是由BootStrap负责加载，这样我们在应用中重写该类的时候无法加载自定义的String类【且是永远加载不到】，只能加载系统的String，这里也是java沙箱模型的第一保障。
备注：
用java –verbose:class ClassLoaderTest
可以查看具体的类运行的时候类加载过程
图及部分类容参考
http://www.cnblogs.com/ChrisWang/archive/2009/11/17/Inside-JVM-4-ClassLoader-Knowledge-Sharing.html