tomcat源码阅读（三）——ClassLoader背景知识

生活如麻

前几天想了一下，最近主要学习linux和httpd，所以tomcat源码阅读先放一放，可能到9月份左右再继续。不过先把已经写好的几篇陆续贴上来
tomcat用到很多ClassLoader相关的代码，如果缺乏这方面的背景知识，阅读源码会遇到很多障碍，所以本文首先总结一下这方面的内容，和tomcat源码的关系不大
1 标准的ClassLoader体系

1.1 bootstrap
bootstrap classloader是由JVM启动的，用于加载%JAVA_HOME%/jre/lib/下的JAVA平台自身的类（比如rt.jar中的类等）。这个classloader位于JAVA类加载器链的顶端，是用C/C++开发的，而且JAVA应用中没有任何途径可以获取到这个实例，它是JDK实现的一部分
1.2 extension
entension classloader用于加载%JAVA_HOME%/jre/lib/ext/下的类，它的实现类是sun.misc.Launcher$ExtClassLoader，是一个内部类
基本上，我们开发的JAVA应用都不太需要关注这个类
1.3 system
system classloader是jvm启动时，根据classpath参数创建的类加载器（如果没有显式指定classpath，则以当前目录作为classpath）。在普通的JAVA应用中，它是最重要的类加载器，因为我们写的所有类，通常都是由它加载的。这个类加载器的实现类是sun.misc.Launch$AppClassLoader
用ClassLoader.getSystemClassLoader()，可以得到这个类加载器
1.4 custom
一般情况下，对于普通的JAVA应用，ClassLoader体系就到system为止了。平时编程时，甚至都不会感受到classloader的存在
但是对于其他一些应用，比如web server，插件加载器等，就必须和ClassLoader打交道了。这时候默认的类加载器不能满足需求了（类隔离、运行时加载等需求），需要自定义类加载器，并挂载到ClassLoader链中（默认会挂载到system classloader下面）
2 双亲委派模型
从上面的图可以看到，classloader链，是一个自上而下的树形结构。一般来说，java中的类加载，是遵循双亲委派模型的，即：
当一个classloader要加载一个类时，首先会委托给它的parent classloader来加载，如果parent找不到，才会自己加载。如果最后也找不到，则会抛出熟悉的ClassNotFoundException
这个模型，是在最基础的抽象类ClassLoader里确定的：

protected synchronized Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
// First, check if the class has already been loaded
Class c = findLoadedClass(name);
if (c == null) {
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}

自定义ClassLoader的时候，一般来说，需要做的并不是覆盖loadClass()方法，这样的话就“破坏”了双亲委派模型；需要做的只是实现findClass()方法即可
不过，从上面的代码也可以看出，双亲委派模型只是一种“建议”，并没有强制保障的措施。如果自定义的ClassLoader无视此规定，直接自行加载，不将请求委托给parent，当然也是没问题的
在实际情况中，双亲委派模型被“破坏”也是很常见的。比如在tomcat里，webappx classloader就不会委托给上层的common classloader，而是先委托给system，然后自己加载，最后才委托给common；再比如说在OSGi里，更是有意完全打破了这个规则
当然，对于普通的JAVA应用开发来说，需要自定义classloader的场景本来就不多，需要去违反双亲委派模型的场景，更是少之又少
3 自定义ClassLoader
3.1 自定义ClassLoader的一般做法
从上面的代码可以看到，自定义ClassLoader很简单，只要继承抽象类ClassLoader，再实现findClass()方法就可以了
3.2 自定义ClassLoader的场景
事实上，需要实现新的ClassLoader的场景是很少的
注意：需要增加一个自定义ClassLoader的场景很多；但是，需要自己实现一个新的ClassLoader子类的场景不多。这是两回事，不可混淆
比如，即使在tomcat里，也没有自行实现新的ClassLoader子类，只是创建了URLClassLoader的实例，作为custom classloader
3.3 ClassLoader的子类
在JDK中已经提供了若干ClassLoader的子类，在需要的时候，可以直接创建实例并使用。其中最常用的是URLClassLoader，用于读取一个URL下的资源，从中加载Class

@Deprecated
public class StandardClassLoader
extends URLClassLoader
implements StandardClassLoaderMBean {
public StandardClassLoader(URL repositories[]) {
super(repositories);
}
public StandardClassLoader(URL repositories[], ClassLoader parent) {
super(repositories, parent);
}
}

可以看到，tomcat就是在URLClassLoader的基础上，包装了StandardClassLoader，实际上并没有任何功能上的区别
3.4 设置parent
在抽象类ClassLoader中定义了一个parent字段，保存的是父加载器。但是这个字段是private的，并且没有setter方法
这就意味着只能在构造方法中，一次性地设置parent classloader。如果没有设置的话，则会默认将system classloader设置为parent，这也是在ClassLoader类中确定的：

protected ClassLoader(ClassLoader parent) {
this(checkCreateClassLoader(), parent);
}
protected ClassLoader() {
this(checkCreateClassLoader(), getSystemClassLoader());
}


4 ClassLoader隐性传递
“隐性传递”这个词是我乱造的，在网上和注释中没有找到合适的描述的词
试想这样一种场景：在应用中需要加载100个类，其中70个在classpath下，默认由system来加载，这部分不需要额外处理；另外30个类，由自定义classloader加载，比如在tomcat里：

Class<?> startupClass = catalinaLoader.loadClass("org.apache.catalina.startup.Catalina");
Object startupInstance = startupClass.newInstance();

如上，org.apache.catalina.startup.Catalina是由自定义类加载器加载的，需要额外编程来处理（如果是system加载的，直接new就可以了）
如果30个类，都要通过这种方式来加载，就太麻烦了。不过classloader有一个特性，就是“隐性传递”，即：
如果一个ClassA是由某个ClassLoader加载的，那么ClassA中依赖的需要加载的类，默认也会由同一个ClassLoader加载
这个机制是由JVM保证的，对于程序员来说是透明的
5 current classloader
5.1 定义
与前面说的extension、system等不同，在运行时并不存在一个实际的“current classloader”，只是一个抽象的概念。指的是一个类“当前的”类加载器。一个对象实例所属的Class，是由哪一个ClassLoader加载的，这个ClassLoader就是这个对象实例的current classloader
获得的方法是：

this.getClass().getClassLoader();


5.2 实例
current classloader概念的意义，主要在于它会影响Class.forName()方法的表现，贴一段代码进行说明：

public class Test {
public void tryForName() {
System.out.println("current classloader: "
+ this.getClass().getClassLoader());
try {
Class.forName("net.kyfxbl.test.cl.Target");
System.out.println("load class success");
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
}
}

这个类调用了Class.forName()方法，试图加载net.kyfxbl.test.cl.Target类（Target是一个空类，作为加载目标，不重要）。这个类在运行时能否加载Target成功，取决于它的current classloader，能不能加载到Target
首先，将Test和Target打成jar包，放到classpath之外，jar包中内容如下：

然后在工程中删除Target类（classpath中加载不到Target了）
在Main中用system 加载Test，此时Test的current classloader是system，加载Target类失败

public static void main(String[] args) {
Test t = new Test();
t.tryForName();
}

然后，这次用自定义的classloader来加载

public static void main(String[] args) throws Exception {
ClassLoader cl = createClassLoader();
Class<?> startupClass = cl.loadClass("net.kyfxbl.test.cl.Test");
Object startupInstance = startupClass.newInstance();
String methodName = "tryForName";
Class<?>[] paramTypes = new Class[0];
Object[] paramValues = new Object[0];
Method method = startupInstance.getClass().getMethod(methodName,
paramTypes);
method.invoke(startupInstance, paramValues);
}
private static ClassLoader createClassLoader() throws MalformedURLException {
String filePath = "c://hehe.jar";
File file = new File(filePath);
URL url = file.toURI().toURL();
URL[] urls = new URL[] { url };
ClassLoader myClassLoader = new URLClassLoader(urls);
return myClassLoader;
}

在想象中，这次Test的current classloader应该变成URLClassLoader，并且加载Target成功。但是还是失败了
这是因为前面说过的“双亲委派模型”，URLClassLoader的parent是system classloader，由于工程里的Test类没有删除，所以classpath里还是能找到Test类，所以Test类的current classloader依然是system classloader，和第一次一样

接下来把工程里的Test类也删除，这次就成功了

5.3 Class.forName()
前面说的是单个参数的forName()方法，默认使用current ClassLoader
除此之外，Class类还定义了3个参数的forName()方法，方法签名如下：

public static Class<?> forName(String name, boolean initialize,
ClassLoader loader)
throws ClassNotFoundException

这个方法的最后一个参数，可以传递一个ClassLoader，会用这个ClassLoader进行加载。这个方法很重要
比如像JNDI，主体类是在JDK包里，由bootstrap加载。而SPI的实现类，则是由厂商提供，一般在classpath里。那么在JNDI的主体类里，要加载SPI的实现类，直接用Class.forName()方法肯定是不行的，这时候就要用到3个参数的Class.forName()方法了
6 ContextClassLoader
6.1 获取ClassLoader的API
前面说过，已经有2种方式可以获取到ClassLoader的引用
一种是ClassLoader.getSystemClassLoader()，获取的是system classloader
另一种是getClass().getClassLoader()，获取的是current classloader
这2种API都只能获取classloader，没有办法用来传递
6.2 传递ClassLoader
每一个thread，都有一个contextClassLoader，并且有getter和setter方法，用来在线程之间传递ClassLoader
有2条默认的规则：
首先，contextClassLoader默认是继承的，在父线程中创建子线程，那么子线程会继承父线程的contextClassLoader
其次，主线程，也就是执行main()方法的那个线程，默认的contextClassLoader是system classloader
6.3 例子
对上面例子中的Test和Main稍微改一下（Test和Target依然打到jar包里，然后从工程中删除，避免被system classloader加载到）

public class Test {
public void tryForName() {
System.out.println("current classloader: "
+ getClass().getClassLoader());
System.out.println("thread context classloader: "
+ Thread.currentThread().getContextClassLoader());
try {
Class.forName("net.kyfxbl.test.cl.Target");
System.out.println("load class success");
} catch (Exception exc) {
exc.printStackTrace();
}
}
}


public static void main(String[] args) throws Exception {
ClassLoader cl = createClassLoader();
Class<?> startupClass = cl.loadClass("net.kyfxbl.test.cl.Test");
final Object startupInstance = startupClass.newInstance();
new Thread(new Runnable() {
@Override
public void run() {
String methodName = "tryForName";
Class<?>[] paramTypes = new Class[0];
Object[] paramValues = new Object[0];
try {
Method method = startupInstance.getClass().getMethod(
methodName, paramTypes);
method.invoke(startupInstance, paramValues);
} catch (Exception exc) {
exc.printStackTrace();
}
}
}).start();
}

这次的tryForName()方法在一个子线程中被调用，并依次打印出current classloader和contextClassLoader，如图：

可以看到，子线程继承了父线程的contextClassLoader
同时可以注意到，contextClassLoader对Class.forName()方法没有影响，contextClassLoader只是起到在线程之间传递ClassLoader的作用
6.4 题外话
从这个例子还可以看出，一个方法在运行时的表现，在编译期是无法确定的
在运行时的表现，有时候取决于方法所在的类是被哪个ClassLoader加载；有时候取决于是运行在单线程环境下，还是多线程环境下
这在编译期是不可知的，所以在编程的时候，要考虑运行时的情况。比如所谓“线程安全”的类，并不是说它“一定”会运行在多线程环境下，而是说它“可以”运行在多线程环境下
7 总结
本文大致总结了ClassLoader的背景知识。掌握了背景，再阅读tomcat的源码，基本就不会遇到ClassLoader方面的困难
本文介绍了ClassLoader的标准体系、双亲委派模型、自定义ClassLoader的方法、以及current classloader和contextClassLoader的概念
其中最重要的是current classloader和contextClassLoader
用于获取ClassLoader的API主要有3种：
ClassLoader.getSystemClassLoader();
Class.getClassLoader();
Thread.getContextClassLoader();
第一个是静态方法，返回的永远是system classloader，也就是说，没什么用
后面2个都是实例方法，一个是返回实例所属的类的ClassLoader；另一个返回当前线程的contextClassLoader，具体的结果都要在运行时才能确定
其中，contextClassLoader可以起到传递ClassLoader的作用，所以特别重要