JAVA ClassLoader

ClassLoader主要对类的请求提供服务，当JVM需要某类时，它根据名称向ClassLoader要求这个类，然后由ClassLoader返回这个类的class对象。

几个相关概念

ClassLoader负责载入系统的所有Resources（Class，文件，来自网络的字节流等），通过ClassLoader从而将资源载入JVM；每个class都有一个reference，指向自己的ClassLoader；array的ClassLoader就是其元素的ClassLoader，若是基本数据类型，则这个array没有ClassLoader。

主要方法和工作过程

ClassLoader主要方法：Class loadClass(String name, boolean resolve); ClassLoader.loadClass()是ClassLoader的入口点  

defineClass方法是ClassLoader的主要诀窍。该方法接受由原始字节组成的数组并把它转换成Class对象。原始数组包含如从文件系统或网络装入的数据。
findSystemClass方法从本地文件系统装入文件。它在本地文件系统中寻找类文件，如果存在，就使用defineClass将原始字节转换成Class对象，以将该文件转换成类。当运行 Java 应用程序时，这是 JVM 正常装入类的缺省机制。  
resolveClass可以不完全地（不带解析）装入类，也可以完全地（带解析）装入类。当编写我们自己的loadClass时，可以调用resolveClass，这取决于loadClass的resolve参数的值。
findLoadedClass充当一个缓存：当请求loadClass装入类时，它调用该方法来查看ClassLoader是否已装入这个类，这样可以避免重新装入已存在类所造成的麻烦。应首先调用该方法  。
一般load方法过程如下：  
调用 findLoadedClass 来查看是否存在已装入的类。  
如果没有，那么采用某种特殊的神奇方式来获取原始字节（通过IO从文件系统，来自网络的字节流等）。
如果已有原始字节，调用 defineClass 将它们转换成 Class 对象。
如果没有原始字节，然后调用 findSystemClass 查看是否从本地文件系统获取类。
如果 resolve 参数是 true，那么调用 resolveClass 解析 Class 对象。
如果还没有类，返回 ClassNotFoundException。
否则，将类返回给调用程序。

委托模型

自从JDK1.2以后，ClassLoader做了改进，使用了委托模型，所有系统中的ClassLoader组成一棵树，ClassLoader在载入类库时先让Parent寻找，Parent找不到才自己找。  

JVM在运行时会产生三个ClassLoader，Bootstrap ClassLoader、Extension ClassLoader和App ClassLoader。其中，Bootstrap ClassLoader是用C++编写的，在Java中看不到它，是null。它用来加载核心类库，就是在lib下的类库，Extension ClassLoader加载lib/ext下的类库，App ClassLoader加载Classpath里的类库，三者的关系为:App ClassLoader的Parent是Extension ClassLoader，而Extension ClassLoader的Parent为Bootstrap ClassLoader。加载一个类时，首先BootStrap进行寻找，找不到再由Extension ClassLoader寻找，最后才是App ClassLoader。
将ClassLoader设计成委托模型的一个重要原因是出于安全考虑，比如在Applet中，如果编写了一个java.lang.String类并具有破坏性。假如不采用这种委托机制，就会将这个具有破坏性的String加载到了用户机器上，导致破坏用户安全。但采用这种委托机制则不会出现这种情况。因为要加载java.lang.String类时，系统最终会由Bootstrap进行加载，这个具有破坏性的String永远没有机会加载。
委托模型还带来了一些问题，在某些情况下会产生混淆，如下是Tomcat的ClassLoader结构图:  

                Bootstrap 
                  | 
                System 
                  | 
                Common 
                /     
            Catalina  Shared 
                      /     
                   Webapp1  Webapp2 ... 

由 Common 类装入器装入的类决不能（根据名称）直接访问由 Web 应用程序装入的类。使这些类联系在一起的唯一方法是通过使用这两个类集都可见的接口。在这个例子中，就是包含由 Java servlet 实现的 javax.servlet.Servlet。
如果在lib或者lib/ext等类库有与应用中同样的类，那么应用中的类将无法被载入。通常在jdk新版本出现有类库移动时会出现问题，例如最初我们使用自己的xml解析器，而在jdk1.4中xml解析器变成标准类库，load的优先级也高于我们自己的xml解析器，我们自己的xml解析器永远无法找到，将可能导致我们的应用无法运行。
相同的类，不同的ClassLoader，将导致ClassCastException异常  

线程中的ClassLoader

每个运行中的线程都有一个成员contextClassLoader，用来在运行时动态地载入其它类，可以使用方法Thread.currentThread().setContextClassLoader(...);更改当前线程的contextClassLoader，来改变其载入类的行为；也可以通过方法Thread.currentThread().getContextClassLoader()来获得当前线程的ClassLoader。

实际上，在Java应用中所有程序都运行在线程里，如果在程序中没有手工设置过ClassLoader，对于一般的java类如下两种方法获得的ClassLoader通常都是同一个：
this.getClass.getClassLoader()；  
Thread.currentThread().getContextClassLoader()；  
方法一得到的Classloader是静态的，表明类的载入者是谁；方法二得到的Classloader是动态的，谁执行（某个线程），就是那个执行者的Classloader。对于单例模式的类，静态类等，载入一次后，这个实例会被很多程序（线程）调用，对于这些类，载入的Classloader和执行线程的Classloader通常都不同。

Web应用中的ClassLoader

回到上面的例子，在Tomcat里，WebApp的ClassLoader的工作原理有点不同，它先试图自己载入类（在ContextPath/WEB-INF/...中载入类），如果无法载入，再请求父ClassLoader完成。

由此可得：
对于WEB APP线程，它的contextClassLoader是WebAppClassLoader；
对于Tomcat Server线程，它的contextClassLoader是CatalinaClassLoader 。

获得ClassLoader的几种方法

可以通过如下3种方法得到ClassLoader： 

this.getClass.getClassLoader(); // 使用当前类的ClassLoader  
Thread.currentThread().getContextClassLoader(); // 使用当前线程的ClassLoader  
ClassLoader.getSystemClassLoader(); // 使用系统ClassLoader，即系统的入口点所使用的ClassLoader（注意，system ClassLoader与根ClassLoader并不一样。JVM下system ClassLoader通常为App ClassLoader）。

几种扩展应用

用户定制自己的ClassLoader可以实现以下的一些应用：

安全性：类进入JVM之前先经过ClassLoader，所以可以在这边检查是否有正确的数字签名等。
加密：java字节码很容易被反编译，通过定制ClassLoader使得字节码先加密防止别人下载后反编译，这里的ClassLoader相当于一个动态的解码器。
归档：可能为了节省网络资源，对自己的代码做一些特殊的归档，然后用定制的ClassLoader来解档。
自展开程序：把java应用程序编译成单个可执行类文件，这个文件包含压缩的和加密的类文件数据，同时有一个固定的ClassLoader，当程序运行时它在内存中完全自行解开，无需先安装。
动态生成：可以生成应用其他还未生成类的类，实时创建整个类并可在任何时刻引入JVM。

资源载入

所有资源都通过ClassLoader载入到JVM里，那么在载入资源时当然可以使用ClassLoader，只是对于不同的资源还可以使用一些别的方式载入，例如对于类可以直接new，对于文件可以直接做IO等。

类载入

载入类的几种方法：假设有类A和类B，A在方法amethod里需要实例化B，可能的方法有3种。对于载入类的情况，用户需要知道B类的完整名字（包括包名，例如"com.rain.B"）  

1. 使用Class静态方法 Class.forName  
    Class cls = Class.forName("com.rain.B"); 
    B b = (B)cls.newInstance(); 
2. 使用ClassLoader  
    /* Step 1. Get ClassLoader */ 
    ClassLoader cl; // 如何获得ClassLoader参考1.6 
    /* Step 2. Load the class */ 
    Class cls = cl.loadClass("com.rain.B"); // 使用第一步得到的ClassLoader来载入B 
    /* Step 3. new instance */ 
    B b = (B)cls.newInstance(); // 有B的类得到一个B的实例 
3. 直接new  
    B b = new B(); 

文件载入（例如配置文件等）

假设在com.rain.A类里想读取文件夹 /com/rain/config 里的文件sys.properties，读取文件可以通过绝对路径或相对路径，绝对路径很简单，在Windows下以盘号开始，在Unix下以"/"开始。

对于相对路径，其相对值是相对于ClassLoader的，因为ClassLoader是一棵树，所以这个相对路径和ClassLoader树上的任何一个ClassLoader相对比较后可以找到文件，那么文件就可以找到，当然，读取文件也使用委托模型。

用户程序通常在classes目录下，如果想读取classes目录里的文件，可以使用ClassLoader，如果想读取其他的文件，一般使用ServletContext.getResource()，如果使用ServletContext.getResource(path)方法，路径必须以"/"开始，路径被解释成相对于ContextRoot的路径，此处载入文件的方法和ClassLoader不同，举例"/WEB-INF/web.xml","/download/WebExAgent.rar"。

public class SysPropertiesUtil{    private static SysPropertiesUtil oInstance = new SysPropertiesUtil();    private static Properties oProperties;    protected final Log logger = LogFactory.getLog(getClass());    protected void loadProperties()    {        try        {            oProperties = new Properties();            ClassLoader oClassLoader = Thread.currentThread().getContextClassLoader();            if (oClassLoader == null)            {                oClassLoader = oInstance.getClass().getClassLoader();            }            InputStream is = oClassLoader.getResourceAsStream("system.properties");            if (is != null)            {                oProperties.load(is);                is.close();            }            else            {                this.logger.error("SysPropertiesUtil can not load property files!");            }        }        catch (Exception e)        {            this.logger.error(e);        }    }}