转载自 薛笛的专栏 http://blog.csdn.net/kabini/archive/2008/09/24/2975263.aspx
浅析Context Class Loader
1 前言
对于一般的Java应用而言,类装载器是透明的,我们在做普通的Java桌面应用程序和Web程序的时候也很少会与ClassLoader打交道。但是当我们深入地研究一些WebServer(如Tomcat)的时候,发现里面用到了很复杂的自定义类装载器体系结构,想要了解其工作过程首先就要理解它是如何载如类的。此外,当我们明明在ClassPath下指定了正确的jar包,却莫名其妙地受到ClassNotFound错误,或者我们放到ClassPath下的类没有被正确载入的时候,就需要和ClassLoader打交道了。这里我不打算讨论基本的JVM的类装载器体系结构和原理,因为这些东西已经在《Java深度历险》或者《Inside Of JVM》里讲的很透彻了。本文旨在分享一下我对于各种文档上都很少提及的Context Class Loader的一些理解。虽然不是点到为止,但是肯定多有疏漏之处,希望对此有研究的朋友留言帮我补充,现行谢过。
2准备
通常情况下,类装载器共有4种,即启动类装载器、EXT类装载器、App类装载器和自定义类装载器。他们之间的阶层情况如下图左面所示,他们都有着不同的载入规则,并且通过向上代理的方式来进行。而本文所提到的Context Class Loader并不是一种新的装载器类型,而是一种抽象的说法,它的具体表现形式为:调用Thread.getCurrentThread().getContextClassLoader()所返回的那个ClassLoader。它和JVM缺省的类装载器以及自定义类装载之间是什么关系呢?下面通过一个实验来看一下。
3 实战演练
(1)步骤一
上图进行了这样一个实验:首先一个名为Class(1)的类中启动MainThread(其实就是这个类里面有main函数的意思啦),注意这个类的名字后面标出了其所在的路径(即ClassPath),然后在里面进行测试,发现目前它的装载器和当前线程(MainThread)的ContextClassLoader都是AppClassLoader。然后Class(1)启动了一个新线程Class(2)。这里的Class(2)是一个Thread的子类,执行Class(2)代码的线程我称之为Thread-0。
(2)步骤二
上图可以看到Class(2)的装载器和ContextClassLoader同样都是AppClassLoader。随后我在Class(2)中创建了一个新的URLCLassLoader,并用这个ClassLoader来载入另一个和Class(1)不在同一个ClassPath下的类Class(3)。此时我们就可以看到变化:即载入Class(3)的装载器是URLClassLoader,而ContextClassLoader还仍然是AppClassLoader。
(2)步骤三
最后我们在Class(3)中启动了一个线程类Class(4),发现Class(4)也是由URLClassLoader载入的,而此时ContextClassLoader仍然是AppClassLoader。
在整个过程中,装载类的ClassLoader发生了变化,由于线程类Class(4)是由Class(3)启动的,所以装载它的类装载器就变成了URLClassLoader。与此同时,所有线程的ContextClassLoader都继承了生成该线程的ContextClassLoader--AppClassLoader。
如果我们在第二步的结尾执行了绿色框中的代码:setContextClassLoader(),则结果就会变成下面这个样子:
我们可以清楚地看到,由于Thread-0将其ContextClassLoader设置成了URLClassLoader,而Thread-1是在Thread-0里面生成的,所以就继承了其ContextClassLoader,变成了URLClassLoader。