Java ClassLoader深刻讲解

【转】http://www.blogjava.net/lhulcn618/archive/2006/05/25/48230.html

【参考】http://ifeve.com/classloader/

当JVM（Java虚拟机）启动时，会造成三个类加载器组成的初始类加载器层次结构。

bootstrap classloader

　　|

extension classloader

　　|

system classloader

①，当启动一个JVM时，bootstrap classloader会加载java的核心类，例如：rt.jar中的类。bootstrap classloader是其余classloader的parent，它是惟一一个没有parent的classloader

②，接下来是extension classloader，它以bootstrap classloader做为parent，它用来从Java系统变量java.ext.dir中的jar包中加载类的；

③，最后，也是最重要的一个就是开发者使用的system classpath classloader。它是extension classloader的child，它用来从Java系统变量java.class.path下面加载类，能够经过-classpath来制定这个位置。

注意类加载器的体系并非“继承”体系，而是一个“委派”体系。大多数类加载器首先会到本身的parent中查找类或者资源，若是找不到，才会在本身的本地进行查找。事实上，类加载器被定义加载哪些在parent中没法加载到的类，这样在较高层级的类加载器上的类型可以被“赋值”为较低类加载器加载的类型。

类加载器的委托行为动机是为了不相同的类被加载屡次。（回到1995年，Java的主要方向被放在Applet上，那时候网络带宽优先，因此程序中的类直到用时才会被加载。可是事实上，Java在服务器端展现 了强劲的能力，可是服务器端要求类加载器可以反转委派原则，也就是先加载本地的类，若是加载不到，再到parent中加载。）

JavaEE 的委派模型：

每一个方块都是一个classloader，JavaEE规范推荐每一个模块的classloader先加载本身classloader的内容，若是加载不到才会到parent的classloader中尝试加载。

反转委派原则的缘由是应用服务器中所携带的类库并非应用所但愿的，也许不适合应用开发者，一个常见的例子就是log4j的以来在容器和不一样的应用中都存在，可是他们的版本大都不一样。

Tomcat的类加载顺序（开启了delegate模式）

 

在Tomcat中，莫仍的行为是先尝试在bootstrap classloader和extension classloader中进行类型加载，若是加载不到则在WebappLoader中进行加载，若是仍是找不到则在Common中进行查找。在Alibaba使用的Tomcat开启了delegate模式，所以加载类型时是会以parent classloader优先。

 

一、bootstrap classloader

bootstrap classloader-引导（也称为原始）类加载器，它负责加载Java的核心类库。在Sun的JVM中，在执行java的命令中使用-Xbootclasspath选项或使用-D选项制定sun.boot.class.path系统属性值何以制定附加的类。这个加载器是很是特殊的，它实际上不是java.lang.ClassLoader的子类，而是由JVM自身实现的。你们能够经过执行如下代码来得到bootstrap classloader加载了哪些核心类库：

import java.net.URL; public class Test { public static void main(String[] args) { URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs(); for(URL url : urls) { System.out.println(url.toExternalForm()); } } }

结果为:

file:/C:/Program%20Files/Java/jre7/lib/resources.jar file:/C:/Program%20Files/Java/jre7/lib/rt.jar file:/C:/Program%20Files/Java/jre7/lib/sunrsasign.jar file:/C:/Program%20Files/Java/jre7/lib/jsse.jar file:/C:/Program%20Files/Java/jre7/lib/jce.jar file:/C:/Program%20Files/Java/jre7/lib/charsets.jar file:/C:/Program%20Files/Java/jre7/lib/jfr.jar file:/C:/Program%20Files/Java/jre7/classes

这时你们知道了为何咱们不须要在系统属性CLASSPATH中指定这些类库了吧，由于JVM在启动的时候就自动加载他们了。

二、extension classloader

extension classloader - 扩展类加载器，它负责加载JRE的扩展目录（JAVA_HOME/jre/lib/ex或者由java.ext.dirs系统属性指定的）中JAR的类包。这为引入除Java核心类之外的新功能提供了一个标准机制。由于默认的扩展目录对全部从同一个JRE中启动的JVM都是通用的，因此放入这个目录的JAR类包对全部的JVM和system classloader都是可见的。在这个实例上调用方法getParent()老是返回空值null，由于引导加载器bootstrap classloader不是一个真正的ClassLoader实例。因此当你们执行如下代码时：

System.out.println(System.getProperty("java.ext.dirs")); ClassLoader extensionClassLoader = ClassLoader.getSystemClassLoader().getParent(); System.out.println("the parent of extension classloader :" + extensionClassLoader.getParent());

 结果为:

C:\Program Files\Java\jre7\lib\ext;C:\Windows\Sun\Java\lib\ext the parent of extension classloader :null

extension classloader 是system classloader的parent，而bootstrap classloader是extension classloader的parent，但它不是一个实际的classloader，因此为null.

三、system classloader

system classloader - 系统（也称为应用）类加载器，它负责在JVM被启动时，加载来自在命令java中的-classpath或者java.class.path系统属性或者CLASSPATH操做系统属性所指定的JAR类包和类路径。

（.;%JAVA_HOME%\lib;%JAVA_HOME%\lib\tools.jar）

总能经过静态方法ClassLoader.getSystemClassLoader()找到该类加载器。若是没有特别指定，则用户自定义的任何类加载器都将该类加载器做为它的父加载器。执行如下代码便可得到：

System.out.println(System.getProperty("java.class.path"));

输出结果则为用户在系统属性里面设置的CLASSPATH。

四、ClassLoader的全盘负责机制和Cache机制

classloader加载类用的是全盘负责委托机制。所谓全盘负责，便是当一个classloader加载一个class的时候，这个Class所依赖的和引用的全部Class也由这个classloader负责载入(例如父类)，除非是显示的使用另一个classloader载入；委托机制则是先让parent（父）类加载器寻找（而不是super，它与parent classloader类不是继承关系），只有在parent找不到的时候才从本身的类路劲中去寻找。此外类加载还采用了cache机制，也就是若是cache中保存了这个Class就直接返回它，若是没有才从文件中读取和转换成Class，并存入cache，这就是为何咱们修改了Class可是必须从新启动JVM才能生效的缘由。

每一个ClassLoader加载Class的过程：

①，检测此Class是否载入过（即在cache中是否存在此Class），若是有到⑧，不然到②；

②，若是parent classloader不存在（没有parent，那parent必定是bootstrap classloader），到④；

③，请求parent classloader载入，若是成功到⑧，不然到⑤；

④，请求JVM从bootstrap class中载入，若是成功到⑧；

⑤，寻找Class文件（从与此classloader相关的类路径中寻找），若是找不到则到⑦；

⑥，从文件中载入Class，到⑧；

⑦，抛出ClassNotFoundException;

⑧，返回Class;

 其中⑤、⑥步咱们能够经过覆盖ClassLoader的findClass方法来实现本身的载入策略。甚至覆盖loadClass方法来实现本身的载入过程。

五、类加载器的顺序：

先是bootstrap classloader，而后是extension classloader，最后才是system classloader。你们会发现加载的Class越重要的越在前面。这样作的缘由是处于安全性的考虑，试想若是system classloader亲自加载一个具备破坏性的“java.lang.System”类的后果吧。这种委托机制保证了用户即便具备一个这样的类，也把它加入到了类路径中，可是它永远不会被载入，由于这个类老是由bootstrap classloader来加载的。你们能够执行一下如下的代码：

System.out.println(System.class.getClassLoader()); 结果：null

结果是null，这就代表java.lang.System是由bootstrap classloader加载的，觉得bootstrap classloader不是一个真正的ClassLoader实例，而是由JVM实现的，正如前面已经说过的、

类 Bootstrap package com.sun.jdi; import com.sun.tools.jdi.VirtualMachineManagerImpl; public class Bootstrap { public Bootstrap() { } public static synchronized VirtualMachineManager virtualMachineManager() { return VirtualMachineManagerImpl.virtualMachineManager(); } }

 六、JVM创建类加载器的结构

下面就让咱们来看看JVM是如何来为咱们创建类加载器的结构的：

sum.misc.Launcher，顾名思义，当你执行java命令的时候，JVM会先使用bootstrap classloader载入并初始化一个Launcher，执行如下代码：

System.out.println("The Launcher`s classloader is " + sun.misc.Launcher.class.getClassLoader()); 结果：The Launcher`s classloader is null

由于使用bootstrap classloader加载，因此classloader is null。

Launcher会根据系统和命令设定初始化好classloader结构，JVM就用它来得到extension classloader和system classloader并载入全部须要载入的Class，最后执行java命令指定的带有静态的main方法的Class。extension classloader其实是sun.misc.Launcher$ExtClassLoader类的一个实例。system classloader其实是sun.misc.Launcher$APPClassLoader类的一个实例。而且都是java.net.URLClassLoader的子类。

让咱们来看看Laucher初始化的过程的部分代码：

public class Launcher { public Launcher() { ExtClassLoader localExtClassLoader; try { //初始化extension classloader
            localExtClassLoader = ExtClassLoader.getExtClassLoader(); } catch (IOException localIOException1) { throw new InternalError("Could not create extension class loader"); } try { //初始化system classloader，parent是extension classl
            this.loader = AppClassLoader.getAppClassLoader(localExtClassLoader); } catch (IOException localIOException2) { throw new InternalError("Could not create application class loader"); } //将system classloader设置成当前线程的context classloader（将在后面介绍）
        Thread.currentThread().setContextClassLoader(this.loader); String str = System.getProperty("java.security.manager"); if (str != null) { SecurityManager localSecurityManager = null; if (("".equals(str)) || ("default".equals(str))) { localSecurityManager = new SecurityManager(); } else { try { localSecurityManager = (SecurityManager) this.loader .loadClass(str).newInstance(); } catch (IllegalAccessException localIllegalAccessException) { } catch (InstantiationException localInstantiationException) { } catch (ClassNotFoundException localClassNotFoundException) { } catch (ClassCastException localClassCastException) { } } if (localSecurityManager != null) { System.setSecurityManager(localSecurityManager); } else { throw new InternalError("Could not create SecurityManager: "
                        + str); } } } ...... //返回system classloader
    public ClassLoader getClassLoader() { return this.loader; } }

再看一下extension classloader的部分代码：（Launcher$ExtClassLoader内部类）

static class ExtClassLoader extends URLClassLoader { public static ExtClassLoader getExtClassLoader() throws IOException { File[] arrayOfFile = getExtDirs(); try { (ExtClassLoader)AccessController.doPrivileged(new PrivilegedExceptionAction() { public Launcher.ExtClassLoader run() throws IOException { int i = this.val$dirs.length; for (int j = 0; j < i; j++) { MetaIndex.registerDirectory(this.val$dirs[j]); } return new Launcher.ExtClassLoader(this.val$dirs); } }); } catch (PrivilegedActionException localPrivilegedActionException) { throw ((IOException)localPrivilegedActionException.getException()); } } void addExtURL(URL paramURL) { super.addURL(paramURL); } public ExtClassLoader(File[] paramArrayOfFile) throws IOException { super(null, Launcher.factory); } private static File[] getExtDirs() { //得到系统属性java.ext.dirs
        String str = System.getProperty("java.ext.dirs"); File[] arrayOfFile; if (str != null) { StringTokenizer localStringTokenizer = new StringTokenizer(str, File.pathSeparator); int i = localStringTokenizer.countTokens(); arrayOfFile = new File[i]; for (int j = 0; j < i; j++) { arrayOfFile[j] = new File(localStringTokenizer.nextToken()); } } else { arrayOfFile = new File[0]; } return arrayOfFile; } 
　　...
 }

 再看system classloader的部分代码：（Launcher$AppClassLoader内部类）

static class AppClassLoader extends URLClassLoader { public static ClassLoader getAppClassLoader(final ClassLoader paramClassLoader)    throws IOException { //得到系统属性“java.class.path”
        String str = System.getProperty("java.class.path"); final File[] arrayOfFile = str == null ? new File[0] : Launcher.getClassPath(str); (ClassLoader)AccessController.doPrivileged(new PrivilegedAction() { public Launcher.AppClassLoader run() { URL[] arrayOfURL = this.val$s == null ? new URL[0] : Launcher.pathToURLs(arrayOfFile); return new Launcher.AppClassLoader(arrayOfURL, paramClassLoader); } }); } }

看了源代码你们就清楚了吧，extension classloader是使用系统属性“java.ext.dirs”设置类搜索路径的，并无使用parent。system classloader是使用系统属性“java.class.path”设置类搜索路径的，而且有一个parent classloader。Launcher初始化extension classloader，system classloader，并将system classloader设置成为context classloader，可是仅仅返回system classloader给JVM。

这里怎么又出来一个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就是这种机制加载的。

七、动态载入和更新

好了，如今咱们了解了classloader的结构和工做原理，那么咱们如何实如今运行时的动态载入和更新呢？只要咱们可以动态改变类搜索路径和清除classloader的cache中已经载入的Class就好了，有两个方案。一是咱们继承一个classloader，覆盖loadclass方法，动态的寻找Class文件并使用defineClass方法；另外一个则很是简单实用，只要从新使用一个新的类搜索路劲来new一个classloader就好了，这样即更新了类搜索路径以便来载入新的Class，也从新生成了一个空白的cache（固然，类搜索路径不必定必须更改）。咱们几乎不用作什么工做，java.netURLClassLoader正是一个符合咱们要求的classloader，咱们能够直接使用或者继承它就能够了！

Constructor and Description: URLClassLoader(URL[] urls) Constructs a new URLClassLoader for the specified URLs using the default delegation parent ClassLoader. URLClassLoader(URL[] urls, ClassLoader parent) Constructs a new URLClassLoader for the given URLs. URLClassLoader(URL[] urls, ClassLoader parent, URLStreamHandlerFactory factory) Constructs a new URLClassLoader for the specified URLs, parent class loader, and URLStreamHandlerFactory.

其中URL[] urls就是咱们要设置的类搜索路径，parent就是这个classloader的parent classloader，默认的是system classloader。

如今咱们可以动态的载入Class了，这样咱们就能够利用newInstance来得到一个Object。但咱们若是将此Object造型呢？能够将此Object造型成它本省的Class吗？

首先让咱们来分析一下java源文件的编译，运行吧！javac命令是调用“JAVA_HOM/lib/tools.jar”中的“com.sun.tools.javac.Main”的compile方法来编译：

public static int compile(String as[]); public static int compile(String as[], PrintWriter printwriter);

返回0表示编译成功，字符串数组as则是咱们使用javac命令编译时的参数，以空格划分。例如：

javac -classpath c:\foo\bar.jar;. -d c:\Some.java

则字符串数组as为{"-classpath","c:\\foo\\bar.jar;.","-d","c:\\","c:\\Some.java"}，若是带有PrintWriter参数，则会把编译信息输出到这个指定的printwriter中。默认的输出是System.err。

其中Main是由JVM使用Launcher初始化system classloader载入的，根据全盘负责原则，编译器在解析这个java源文件时所发现的它所依赖和引用的全部Class也将由system classloader载入，若是system classloader不能载入某个Class，编译器将抛出一个“cannot resolve symbol”错误。

因此首先变异就不会经过，也就是编译器没法编译一个引用了在CLASSPATH中位置Class的java源文件，而因为拼写错误或者没有吧所需类库放到CLASSPATH中，你们必定常常看到这个“cannot resolve symbol”这个编译错误吧！

其次，就是咱们把这个Class放到编译路径中，成功的进行了编译，而后在运行的时候不把它放到CLASSPATH中而利用咱们本身的classloader来动态载入这个Class，这时候也会出现“java.lang.NoClassDefFoundError”的违例，为何呢？

咱们再来分析一下，首先调用这个造型语句的可执行的Class必定是由JVM使用Laucher初始化的system classloader载入的，根据全盘负责原则，但咱们进行造型的时候，JVM也会使用system classloader来蚕食载入这个Class来对实例进行造型，天然在system classloader寻找不到这个Class时就会抛出“java.lang.NoClassDefFoundError”的违例。

OK，如今咱们总结一下，java文件的变异和Class的载入执行，都是适应Launcher初始化system classloader做为类载入器的，咱们没法动态的改变system classloader，更没法让JVM使用咱们本身的classloader来替换system classloader，根据全盘负责原则，就限制了编译和运行时，咱们没法直接显示的使用system classloader寻找不到的Class，即咱们只能使用Java核心类库，扩展类库和CLASSPATH中的类库中的Class。

还不死心！再尝试一下这种状况：咱们把这个Class也放到CLASSPATH中，让system classloader可以识别和载入。而后咱们经过本身的classloader来从指定的class文件中载入这个Class（不可以委托parent载入，由于这样会被system classloader从CLASSPATH中将其载入）。而后实例化一个Object，并造型成这个Class，这样JVM也是别这个Class（由于system classloader可以从CLASSPATH中定位和载入这个Class），载入的也不是CLASSPATH中的这个Class，而是从CLASSPATH外动态载入的，这样总行了吧，十分不幸的是，这时会出现“java.lang.ClassCastException”违例。

为何呢？咱们也来分析一下，不错，咱们虽然从CLASSPATH外使用咱们本身的classload动态载入了这个Class，但将它的实例造型的时候是JVM使用system classloader来在此载入这个Class，而咱们使用的是本身classloader并载入的这个Class的一个实力造型。你们发现什么问题了吗？也就是咱们尝试将从一个classloader载入的Class的一个实例造型是另一个classloader载入的Class，虽然两个Class的名字同样，甚至是从同一个class文件中载入。但不幸的是JVM却认为这两个Class是不一样的，即JVM认为不一样的classloader载入的相同的名字的Class是不一样的（即便是从同一个class文件中载入的）！这样作的缘由我想大概也是主要出于安全性考虑，这样就保证全部的和兴Java类都是system classloader载入的，咱们没法用本身的classloader载入相同名字的Class的实例来替换他们的实例。

到这里，应该就想到了该如何动态载入咱们的Class，实例化，造型并调用了。

那就是利用面向对象的基本特性之一的多态性。咱们把咱们动态载入的Class的实例造型成它的一个system classloader所能识别的父类就好了，这是为何呢，咱们仍是要再分析一下。当咱们用咱们本身的classloader来动态载入这个Class的时候，发现它有一个父类Class，在载入它以前JVM必须先载入这个父类的Class，这个父类Class是system classloader所能识别的，根据委托机制，它将由system classloader载入，而后咱们的classloader再载入这个子类Class，建立一个实例，造型为这个父类Class，注意了，造型成这个父类Class的时候（向上转型）是面向对象的java语言所容许的而且JVM也是支持的，JVM就是用system classloader再次载入这个父类Class，而后将此子类实例造型为这个父类的Class。你们能够从这个过程当中发现这个父类Class都是有system classloader载入的，也就是同一个class loader载入的同一个Class，因此造型的时候不会出现任何异常。而根据多态性，调用这个父类的方法时，真正执行的是这个子类Class（非父类Class）的覆盖了父类的方法。这些方法中也能够引用system classloader不能识别的Class，由于根据全盘负责原则，只要载入这个Class的classloader即咱们本身定义的classloader可以定位和载入这些Class就好了。（即牛人说的Java文件在生成class文件的编译过程当中，代码就已经写好了的）

这样咱们就能够事先定义好一组接口或者基类并放入CLASSPATH中，而后在执行的时候动态的载入实现或者继承了这些接口或基类的子类。好比Servlet，web application server可以载入任何继承了Servlet的Class并正确的执行它们，无论它实际的Class是什么，就是都把它们实例化称为一个Servlet Class，而后执行Servlet init doPost doGet destroy..等方法的，而无论这个Servlet是从web-inf/lib和web-inf/classes下由system classloader的子classloader（即定制的classloader）动态载入的。说了这么多但愿你们都明白了。再applet，ejb容器中，都是采用了这种机制。

对于以上各类状况，但愿你们实际编写一些example来实验一下。

最后说点别的，classloader虽然称为类加载器，但并不意味着只能用来加载Class，咱们还能够利用它来得到图片，音频文件等资源的URL，固然，这些资源必须在CLASSPATH中的jar类库或者目录下。在API的doc中关于ClassLoader的两个寻找资源和Class的方法描述吧：

public URL getResource(String name) 用指定的名字来查找资源，一个资源是一些可以被class代码访问的在某种程度上依赖于代码位置的数据（图片，音频，文本等等）。一个资源的名字是以'/'号分隔肯定资源的路径名的。这个方法将先请求parent classloader搜索资源，若是没有parent，则会在内置在虚拟机中的classloader（即bootstrap classloader）的路径中搜索。若是失败，这个方法将调用findResource(String)来寻找资源。 public static URL getSystemResource(String name) 从用来载入类的搜索路径中查找一个指定名字的资源。这个方法使用system class loader来定位资源。即至关于ClassLoader.getSystemClassLoader().getResource(name)。

例如：

System.out.println(ClassLoader.getSystemResource("java/lang/String.class")); 结果：jar:file:/C:/Program%20Files/Java/jre7/lib/rt.jar!/java/lang/String.class

代表String.class文件在rt。jar的java/lang目录中。

所以咱们能够将图片等资源随同Class一同打包到jar类库中（固然，也能够单独打包这些资源），并添加他们到class loader的搜索路径中，咱们就能够无需关心这些资源的具体位置，让class loader来帮咱们寻找了。