Java ClassLoader

　Java的ClassLoader就是用来动态装载class的，ClassLoader对一个class只会装载一次，JVM使用的ClassLoader一共有4种：

　　启动类装载器，标准扩展类装载器，类路径装载器和网络类装载器。

　　这4种ClassLoader的优先级依次从高到低，使用所谓的“双亲委派模型”。确切地说，假如一个网络类装载器被请求装载一个java.lang.Integer，它会首先把请求发送给上一级的类路径装载器，假如返回已装载，则网络类装载器将不会装载这个java.lang.Integer，假如上一级的类路径装载器返回未装载，它才会装载java.lang.Integer.

　　类似的，类路径装载器收到请求后（无论是直接请求装载还是下一级的ClassLoader上传的请求），它也会先把请求发送到上一级的标准扩展类装载器，这样一层一层上传，于是启动类装载器优先级最高，假如它按照自己的方式找到了java.lang.Integer，则下面的ClassLoader 都不能再装载java.lang.Integer，尽管你自己写了一个java.lang.Integer，试图取代核心库的java.lang.Integer是不可能的，因为自己写的这个类根本无法被下层的ClassLoader装载。

　　再说说Package权限。Java语言规定，在同一个包中的class，假如没有修饰符，默认为Package权限，包内的class都可以访问。但是这还不够准确。确切的说，只有由同一个ClassLoader装载的class才具有以上的Package权限。比如启动类装载器装载了java.lang.String，类路径装载器装载了我们自己写的java.lang.Test，它们不能互相访问对方具有Package权限的方法。这样就阻止了恶意代码访问核心类的Package权限方法。

　　为了深入了解Java的ClassLoader机制，我们先来做以下实验：

　　package java.lang;public class Test {　public static void main(String[] args) {　char[] c = "1234567890".toCharArray();　String s = new String(0, 10, c);}}

 

String类有一个Package权限的构造函数String（int offset， int length， char[] array），按照默认的访问权限，由于Test属于java.lang包，因此理论上应该可以访问String的这个构造函数。编译通过！执行时结果如下：

　　package java.lang;

　　public class Test {

　　public static void main(String[] args) {

　　char[] c = "1234567890".toCharArray();

　　String s = new String(0, 10, c);

　　}

　　}

 

 

　Java中一共有四个类加载器，之所以叫类加载器，是程序要用到某个类的时候，要用类加载器载入内存。

　　这四个类加载器分别为：Bootstrap ClassLoader、Extension ClassLoader、AppClassLoader

　　和URLClassLoader，他们的作用其实从名字就可以大概推测出来了。其中AppClassLoader在很多地方被叫做System ClassLoader

　　Bootstrap ClassLoader是在JVM开始运行的时候加载java的核心类，是用C++编写的，它用来加载核心类库，在JVM源代码中这样写道：

　　static const char classpathFormat[] =

　　"%/lib/rt.jar:"

　　"%/lib/i18n.jar:"

　　"%/lib/sunrsasign.jar:"

　　"%/lib/jsse.jar:"

　　"%/lib/jce.jar:"

　　"%/lib/charsets.jar:"

　　"%/classes";

　　Extension ClassLoader是用来加载扩展类，即/lib/ext中的类。

　　AppClassLoader用来加载Classpath的类，是和我们关系最密切的类。

　　URLClassLoader用来加载网络上远程的类，暂且不讨论。

　　它们之间的关系:

　　1.Parent-Child，按顺序从大到小。不是简单的继承关系。

　　2.ClassLoader有个getParent的方法，但是Ext ClassLoader调用后得到的是null，bootstrap是JVM自己的，用户看不到。

　　3.classloader的委托机制：当等级比较低的ClassLoader要加载某个类的时候，它首先会请求Parent加载器来加载，Parent再请求它的Parent

　　比如现在Ext要加载了，它往上请求。如果最大的Bootstrap找不到，那么Boot会叫Ext自己找找，Ext找不到，是不会让下一级的App去找的，此时就报出ClassNotFoundException

　　4.类A调用类B，B会要求调用它的类的类加载器来加载它，也就是B会要求加载A的加载器来加载B。这就会有个问题，如果他们在一起，那没关系，肯定某个classloader会把它们俩都加载好。但是如果A在/lib/ext文件夹中，而B在Classpath中呢？过程是这样的首先加载A，那么一层层上到Bootstrap Classloader，boot没找到所以ext自己找，找到了，没问题；加载B，因为A调用了B，所以也从bootstrap来找，没找到，然后A的ext classloader来找还是没找到，但是再也不会往下调用了，于是报出ClassNotFoundException。

　　但是现实生活中有很多应用，比如JDBC核心方法在核心库而驱动在扩展库，是必定在两个地方的，那怎么办呢？要用到Context ClassLoader我们在建立一个线程Thread的时候，可以为这个线程通过setContextClassLoader方法来指定一个合适的classloader作为这个线程的context classloader，当此线程运行的时候，我们可以通过getContextClassLoader方法来获得此context classloader，就可以用它来载入我们所需要的Class。默认的是system classloader。利用这个特性，我们可以“打破”classloader委托机制了，父classloader可以获得当前线程的context classloader，而这个context classloader可以是它的子classloader或者其他的classloader，那么父classloader就可以从其获得所需的 Class，这就打破了只能向父classloader请求的限制了。这个机制可以满足当我们的classpath是在运行时才确定,并由定制的 classloader加载的时候,由system classloader(即在jvm classpath中)加载的class可以通过context classloader获得定制的classloader并加载入特定的class(通常是抽象类和接口,定制的classloader中是其实现),例如web应用中的servlet就是用这种机制加载的.