CLassLoader载入类的原理

构造类的时候可以动态地载入内存，这样可以从一定程度上提高效率，所有类的载入都需要有ClassLoader。

显式的动态载入类有两种方法：一种是Class.forName()，一种是ClassLoader.loadClass()，它们得到的都是Class对象，也就是相应类的元数据，然后调用newInstance()方法就可以构造这个类的对象了。这两种方法的原理都是有一个ClassLoader来载入类。我们可以直接使用默认的CLassLoader来载入类，也可以实现自己的ClassLoader(URLClassLoader就是一个例子)来载入。

JVM有三个ClassLoader

                        Bootstrap Loader（这个转载器是C++写的，直接与JVM打交道）

                        ExtClassLoader

                        AppClassLoader

默认情况下先请求AppClassLoader来搜索class文件，AppClassLoader再向其parent类ExtClassClassLoader请求，ExtClassClassLoader再请求其parent“类”Bootstrap Loader搜索。如果父装载器在其搜索路径里找不到class文件就再由子装载器搜索，如果一直到AppClassLoader找不到就会抛出NoClassDefFoundError。这就是ClassLoader Hierarchy，简而言之就是所有转载请求一直发送到Bootstrap Loader，然后找不到才由子装载器装载。

Bootstrap ClassLoader：也称为primordial(root) class loader。主要是负责装载jre/lib下的jar文件，当然，你也可以通过-Xbootclasspath参数定义。该ClassLoader不能被Java代码实例化，因为它是JVM本身的一部分。

Extention ClassLoader：该ClassLoader是Bootstrap classLoader的子class loader。它主要负责加载jre/lib/ext/下的所有jar文件。只要jar包放置这个位置，就会被虚拟机加载。一个常见的、类似的问题是，你将mysql的低版本驱动不小心放置在这儿，但你的Web应用程序的lib下有一个新的jdbc驱动，但怎么都报错，譬如不支持JDBC2.0的 DataSource，这时你就要当心你的新jdbc可能并没有被加载。这就是ClassLoader的delegate现象。常见的有log4j、 common-log、dbcp会出现问题，因为它们很容易被人塞到这个ext目录，或是Tomcat下的common/lib目录。

Application ClassLoader：也称为System ClassLoaer。它负责加载CLASSPATH环境变量下的classes。缺省情况下，它是用户创建的任何ClassLoader的父 ClassLoader，我们创建的standalone应用的main class缺省情况下也是由它加载(通过Thread.currentThread().getContextClassLoader()查看)。

我们实际开发中，用ClassLoader更多时候是用其加载classpath下的资源，特别是配置文件，如ClassLoader.getResource()，比FileInputStream直接。

 

ClassLoader是一种分级(hierarchy)的代理(delegation)模型。

Delegation：其实是Parent Delegation，当需要加载一个class时，当前线程的ClassLoader首先会将请求代理到其父classLoader，递归向上，如果该 class已经被父classLoader加载，那么直接拿来用，譬如典型的ArrayList，它最终由Bootstrap ClassLoader加载。并且，每个ClassLoader只有一个父ClassLoader。

Class查找的位置和顺序依次是：Cache、parent、self。

Hierarchy：上面的delegation已经暗示了一种分级结构，同时它也说明：一个ClassLoader只能看到被它自己加载的 classes，或是看到其父(parent) ClassLoader或祖先(ancestor) ClassLoader加载的Classes。

在一个单虚拟机环境下，标识一个类有两个因素：class的全路径名、该类的ClassLoader。

 

我碰到的一个典型的例子是：在做WAS的SSO开发时，由于我们的类是由WAS在启动时加载，该ClassLoader比下面的部署的Applicaton的ClassLoader的级别高。所以，在我们自己的类中没法用到应用程序的连接池，必须自建。

代理模型是Java安全模型的保证。譬如，我们自己写一个String.java，并且编译、package到自己的java.lang包下。按照代理模型，当前线程的ClassLoader会将其代理到父ClassLoader，父ClassLoader(最终会是Bootstrap)会找到 rt.jar下的String.class，也就是说我们的String.class不会捣乱。

 

自定义ClassLoader

我们前面说过，自定义ClassLoader的缺省父ClassLoader是Application ClassLoader。一般的应用开发用不到它，但我们最好理解。因为在内存泄漏查找、应用程序部署出问题时，很多都和它有关。

譬如，内存泄漏是怎么产生的？这就涉及到ClassLoader和Class的生命周期。我曾经碰到这样一个问题：我们的程序用到了 Webwork和Spring框架，当部署到Tomcat下时没有任何问题，但部署到WAS下，报告找不到Webwork的xml的DTD文件，而且 Spring的日志也总是失效。Why？因为解析xml dtd时，用的是IBM的Xerces，不是我们的。而Spring日志问题是因为应用程序用的是WAS的Common-log.jar，而不是我们的。将应用的ClassLoader从默认的Parent-First，改成Parent-Last就可以解决，不过我们项目中用到其它库，又发生了其它问题。

 

一般来说，用到自定义ClassLoader有三种情况：

1、应用框架可以自己控制Classes的目录，并且自动部署。

我读过Jive公司的Wildfire(著名的即时通讯服务器)，它自己有一套应用框架，非常灵活，遵循该框架插件规范的的第三方的plug-in放置在指定目录可以自动部署，实现某些扩展功能，如文件传输、语音聊天。

2、区分用户代码

这被广泛应用在Servlet容器和类似容器，譬如EJB Container设计中，大家看到Tomcat下有common、server、share三个目录吧(ClassLoader顺序从左到有)，另外也有用户应用的WEB-INF目录，它是我们自己开发的。

3、允许Classes卸载

如果没有自定义的ClassLoader，那么我们自己应用中的classes永远都不能被卸载，因为这些类被Application ClassLoader加载后cache起来了，我们的classes一直对该ClassLoader有引用，而该系统级的ClassLoader永远都不会被卸载，除非JVM shutdown了。JSP和Servlet的动态部署就用到这个特性。