类加载是java语言提供的最强大的机制之一尽管类加载并不是讨论的热点话题但所有的编程人员都应该了解其工作机制明白如何做才能让其满足我们的需要这能有效节省我们的编码时间从不断调试ClassNotFoundException ClassCastException的工作中解脱出来
这篇文章从基础讲起比如代码与数据的不同之处是什么他们是如何构成一个实例或对象的然后深入探讨java虚拟机（JVM）是如何利用类加载器读取代码以及java中类加载器的主要类型接着用一个类加载的基本算法看一下类加载器如何加载一个内部类本文的下一节演示一段代码来说明扩展和开发属于自己的类加载器的必要性紧接着解释如何使用定制的类加载器来完成一个一般意义上的任务使其可以加载任意远端客户的代码在JVM中定义实例化并执行它本文包括了JEE关于类加载的规范——事实上这已经成为了JEE的标准之一
类与数据
一个类代表要执行的代码而数据则表示其相关状态状态时常改变而代码则不会当我们将一个特定的状态与一个类相对应起来也就意味着将一个类事例化尽管相同的类对应的实例其状态千差万别但其本质都对应着同一段代码在JAVA中一个类通常有着一个class文件但也有例外在JAVA的运行时环境中（Java runtime）每一个类都有一个以第一类(firstclass)的Java对象所表现出现的代码其是javalangClass的实例我们编译一个JAVA文件编译器都会嵌入一个public static final修饰的类型为javalangClass名称为class的域变量在其字节码文件中因为使用了public修饰我们可以采用如下的形式对其访问
javalangClass klass = Myclassclass;
一旦一个类被载入JVM中同一个类就不会被再次载入了（切记同一个类）这里存在一个问题就是什么是同一个类？正如一个对象有一个具体的状态即标识一个对象始终和其代码(类)相关联同理载入JVM的类也有一个具体的标识我们接下来看
在JAVA中一个类用其完全匹配类名(fully qualified class name)作为标识这里指的完全匹配类名包括包名和类名但在JVM中一个类用其全名和一个加载类ClassLoader的实例作为唯一标识因此如果一个名为Pg的包中有一个名为Cl的类被类加载器KlassLoader的一个实例kl加载Cl的实例即Cclass在JVM中表示为(Cl Pg kl)这意味着两个类加载器的实例(Cl Pg kl) 和 (Cl Pg kl)是不同的被它们所加载的类也因此完全不同互不兼容的那么在JVM中到底有多少种类加载器的实例？下一节我们揭示答案
类加载器
在JVM中每一个类都被javalangClassLoader的一些实例来加载类ClassLoader是在包中javalang里开发者可以自由地继承它并添加自己的功能来加载类
无论何时我们键入java MyMainClass来开始运行一个新的JVM引导类加载器(bootstrap class loader)负责将一些关键的Java类如javalangObject和其他一些运行时代码先加载进内存中运行时的类在JRE\lib\rtjar包文件中因为这属于系统底层执行动作我们无法在JAVA文档中找到引导类加载器的工作细节基于同样的原因引导类加载器的行为在各JVM之间也是大相径庭
同理如果我们按照如下方式
log(javalangStringclassgetClassLoader());
来获取java的核心运行时类的加载器
就会得到null
接下来介绍java的扩展类加载器扩展库提供比java运行代码更多的特性我们可以把扩展库保存在由javaextdirs属性提供的路径中
(编辑注javaextdirs属性指的是系统属性下的一个key所有的系统属性可以通过SystemgetProperties()方法获得在编者的系统中javaextdirs的value是 C:\Program Files\Java\jdk_\jre\lib\ext下面将要谈到的如javaclasspath也同属系统属性的一个key)
类ExtClassLoader专门用来加载所有javaextdirs下的jar文件开发者可以通过把自己的jar文件或库文件加入到扩展目录的classpath使其可以被扩展类加载器读取
从开发者的角度第三种同样也是最重要的一种类加载器是AppClassLoader这种类加载器用来读取所有的对应在javaclasspath系统属性的路径下的类
Sun的java指南中文章理解扩展类加载（Understanding Extension Class Loading）对以上三个类加载器路径有更详尽的解释这是其他几个JDK中的类加载器
●URLClassLoader
●javasecuritySecureClassLoader
●javarmiserverRMIClassLoader
●sunappletAppletClassLoader
javalangThread包含了public ClassLoader getContextClassLoader()方法这一方法返回针对一具体线程的上下文环境类加载器此类加载器由线程的创建者提供以供此线程中运行的代码在需要加载类或资源时使用如果此加载器未被建立缺省是其父线程的上下文类加载器原始的类加载器一般由读取应用程序的类加载器建立
类加载器如何工作？
除了引导类加载器所有的类加载器都有一个父类加载器不仅如此所有的类加载器也都是javalangClassLoader类型以上两种类加载器是不同的而且对于开发者自订制的类加载器的正常运行也至关重要最重要的方面是正确设置父类加载器任何类加载器其父类加载器是加载该类加载器的类加载器实例（记住类加载器本身也是一个类！）
使用loadClass()方法可以从类加载器中获得该类我们可以通过javalangClassLoader的源代码来了解该方法工作的细节如下
protected synchronized Class<?> loadClass
(String name boolean resolve)
throws ClassNotFoundException{
// First check if the class is already loaded
Class c = findLoadedClass(name);
if (c == null) {
try {
if (parent != null) {
c = parentloadClass(name false);
} else {
c = findBootstrapClass(name);
}
} catch (ClassNotFoundException e) {
// If still not found then invoke
// findClass to find the class
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
我们可以使用ClassLoader的两种构造方法来设置父类加载器
public class MyClassLoader extends ClassLoader{
public MyClassLoader(){
super(MyClassLoaderclassgetClassLoader());
}
}
或
public class MyClassLoader extends ClassLoader{
public MyClassLoader(){
super(getClass()getClassLoader());
}
}
第一种方式较为常用因为通常不建议在构造方法里调用getClass()方法因为对象的初始化只是在构造方法的出口处才完全完成因此如果父类加载器被正确建立当要示从一个类加载器的实例获得一个类时如果它不能找到这个类它应该首先去访问其父类如果父类不能找到它(即其父类也不能找不这个类等等)而且如果findBootstrapClass()方法也失败了则调用findClass()方法findClass()方法的缺省实现会抛出ClassNotFoundException当它们继承javalangClassLoader来订制类加载器时开发者需要实现这个方法findClass()的缺省实现方式如下
protected Class<?> findClass(String name)
throws ClassNotFoundException {
throw new ClassNotFoundException(name);
}
在findClass()方法内部类加载器需要获取任意来源的字节码来源可以是文件系统URL数据库可以产生字节码的另一个应用程序及其他类似的可以产生java规范的字节码的来源你甚至可以使用BCEL (Byte Code Engineering Library字节码工程库)它提供了运行时创建类的捷径BCEL已经被成功地使用在以下方面编译器优化器混淆器代码产生器及其他分析工具一旦字节码被检索此方法就会调用defineClass()方法此行为对不同的类加载实例是有差异的因此如果两个类加载实例从同一个来源定义一个类所定义的结果是不同的
JAVA语言规范（Java language specification）详细解释了JAVA执行引擎中的类或接口的加载（loading）链接（linking）或初始化（initialization）过程
图一显示了一个主类称为MyMainClass的应用程序依照之前的阐述MyMainClassclass会被AppClassLoader加载 MyMainClass创建了两个类加载器的实例CustomClassLoader 和 CustomClassLoader他们可以从某数据源（比如网络）获取名为Target的字节码这表示类Target的类定义不在应用程序类路径或扩展类路径在这种情况下如果MyMainClass想要用自定义的类加载器加载Target类CustomClassLoader和CustomClassLoader会分别独立地加载并定义Targetclass类这在java中有重要的意义如果Target类有一些静态的初始化代码并且假设我们只希望这些代码在JVM中只执行一次而这些代码在我们目前的步骤中会执行两次——分别被不同的CustomClassLoaders加载并执行如果类Target被两个CustomClassLoaders加载并创建两个实例Target和Target如图一显示它们不是类型兼容的换句话说在JVM中无法执行以下代码
Target target = (Target) target;
以上代码会抛出一个ClassCastException这是因为JVM把他们视为分别不同的类因为他们被不同的类加载器所定义这种情况当我们不是使用两个不同的类加载器CustomClassLoader 和 CustomClassLoader而是使用同一个类加载器CustomClassLoader的不同实例时也会出现同样的错误这些会在本文后边用具体代码说明
图 在同一个JVM中多个类加载器加载同一个目标类
关于类加载定义和链接的更多解释请参考Andreas Schaefer的Inside Class Loaders
为什么我们需要我们自己的类加载器
原因之一为开发者写自己的类加载器来控制JVM中的类加载行为java中的类靠其包名和类名来标识对于实现了javaioSerializable接口的类serialVersionUID扮演了一个标识类版本的重要角色这个唯一标识是一个类名接口名成员方法及属性等组成的一个位的哈希字段而且也没有其他快捷的方式来标识一个类的版本严格说来如果以上的都匹配那么则属于同一个类
但是让我们思考如下情况我们需要开发一个通用的执行引擎可以执行实现某一特定接口的任何任务当任务被提交到这个引擎首先需要加载这个任务的代码假设不同的客户对此引擎提交了不同的任务凑巧这些所有的任务都有一个相同的类名和包名现在面临的问题就是这个引擎是否可以针对不同的用户所提交的信息而做出不同的反应这一情况在下文的参考一节有可供下载的代码样例samepath 和 differentversions这两个目录分别演示了这一概念
图 显示了文件目录结构有三个子目录samepath differentversions 和 differentversionspush里边是例子
图 文件夹结构组织示例
在samepath 中类versionVersion保存在v和v两个子目录里两个类具有同样的类名和包名唯一不同的是下边这行
public void fx(){
log(this = + this + ; Versionfx());
}
V中日志记录中有Versionfx()而在v中则是Versionfx()把这个两个存在细微不同的类放在一个classpath下然后运行Test类
set CLASSPATH=;%CURRENT_ROOT%\v;%CURRENT_ROOT%\v
%JAVA_HOME%\bin\java Test
图显示了控制台输出我们可以看到对应着Versionfx()的代码被执行了因为类加载器在classpath首先看到此版本的代码
图 在类路径中samepath测试排在最前面的version
再次运行类路径做如下微小改动
set CLASSPATH=;%CURRENT_ROOT%\v;%CURRENT_ROOT%\v
%JAVA_HOME%\bin\java Test
控制台的输出变为图对应着Versionfx()的代码被加载因为类加载器在classpath中首先找到它的路径
图 在类路径中samepath测试排在最前面的version
根据以上例子可以很明显地看出类加载器加载在类路径中被首先找到的元素如果我们在v和v中删除了versionVersion做一个非versionVersion形式的jar文件如myextensionjar把它放到对应javaextdirs的路径下再次执行后看到versionVersion不再被AppClassLoader加载而是被扩展类加载器加载如图所示
图 AppClassLoader及ExtClassLoader
继续这个例子文件夹differentversions包含了一个RMI执行引擎客户端可以提供给执行引擎任何实现了commonTaskIntf接口的任务子文件夹client 和 client包含了类clientTaskImpl有个细微不同的两个版本两个类的区别在以下几行
static{
log(clientTaskImplclassgetClassLoader
(v) : + TaskImplclassgetClassLoader());
}
public void execute(){
log(this = + this + ; execute());
}
在client和client里分别有getClassLoader(v) 与 execute()和getClassLoader(v) 与 execute()的的log语句并且在开始执行引擎RMI服务器的代码中我们随意地将client的任务实现放在类路径的前面
CLASSPATH=%CURRENT_ROOT%\common;%CURRENT_ROOT%\server;
%CURRENT_ROOT%\client;%CURRENT_ROOT%\client
%JAVA_HOME%\bin\java serverServer
如图的屏幕截图在客户端VM各自的clientTaskImpl类被加载实例化并发送到服务端的VM来执行从服务端的控制台可以明显看到clientTaskImpl代码只被服务端的VM执行一次这个单一的代码版本在服务端多次生成了许多实例并执行任务
图 执行引擎服务器控制台
图显示了服务端的控制台加载并执行两个不同的客户端的请求如图７８所示需要注意的是代码只被加载了一次（从静态初始化块的日志中也可以明显看出）但对于客户端的调用这个方法被执行了两次
图７ 执行引擎客户端 控制台
图７中客户端VM加载了含有clientTaskImplclassgetClassLoader(v)的日志内容的类TaskImpl的代码并提供给服务端的执行引擎图的客户端VM加载了另一个TaskImpl的代码并发送给服务端
图 执行引擎客户端 控制台
在客户端的VM中类clientTaskImpl被分别加载初始化并发送到服务端执行图还揭示了clientTaskImpl的代码只在服务端的VM中加载了一次但这唯一的一次却在服务端创造了许多实例并执行或许客户端该不高兴了因为并不是它的clientTaskImpl(v)的方法调用被服务端执行了而是其他的一些代码如何解决这一问题？答案就是实现定制的类加载器
定制类加载器
要较好地控制类的加载就要实现定制的类加载器所有自定义的类加载器都应继承自javalangClassLoader而且在构造方法中我们也应该设置父类加载器然后重写findClass()方法differentversionspush文件夹包含了一个叫做FileSystemClassLoader的自订制的类加载器其结构如图所示
图 定制类加载器关系
以下是在commonFileSystemClassLoader实现的主方法
public byte[] findClassBytes(String className){
try{
String pathName = currentRoot +
FileseparatorChar + className
replace( FileseparatorChar)
+ class;
FileInputStream inFile = new
FileInputStream(pathName);
byte[] classBytes = new
byte[inFileavailable()];
inFileread(classBytes);
return classBytes;
}
catch (javaioIOException ioEx){
return null;
}
}
public Class findClass(String name)throws
ClassNotFoundException{
byte[] classBytes = findClassBytes(name);
if (classBytes==null){
throw new ClassNotFoundException();
}
else{
return defineClass(name classBytes
classByteslength);
}
}
public Class findClass(String name byte[]
classBytes)throws ClassNotFoundException{
if (classBytes==null){
throw new ClassNotFoundException(
(classBytes==null));
}
else{
return defineClass(name classBytes
classByteslength);
}
}
public void execute(String codeName
byte[] code){
Class klass = null;
try{
klass = findClass(codeName code);
TaskIntf task = (TaskIntf)
klassnewInstance();
taskexecute();
}
catch(Exception exception){
exceptionprintStackTrace();
}
}
这个类供客户端把clientTaskImpl(v)转换成字节数组之后此字节数组被发送到RMI服务端在服务端一个同样的类用来把字节数组的内容转换回代码客户端代码如下
public class Client{
public static void main (String[] args){
try{
byte[] code = getClassDefinition
(clientTaskImpl);
serverIntfexecute(clientTaskImpl
code);
}
catch(RemoteException remoteException){
remoteExceptionprintStackTrace();
}
}
private static byte[] getClassDefinition
(String codeName){
String userDir = SystemgetProperties()
getProperty(BytePath);
FileSystemClassLoader fscl = null;
try{
fscl = new FileSystemClassLoader
(userDir);
}
catch(FileNotFoundException
fileNotFoundException){
fileNotFoundExceptionprintStackTrace();
}
return fsclfindClassBytes(codeName);
}
}
在执行引擎中从客户端收到的代码被送到定制的类加载器中定制的类加载器把其从字节数组定义成类实例化并执行需要指出的是对每一个客户请求我们用类FileSystemClassLoader的不同实例来定义客户端提交的clientTaskImpl而且clientTaskImpl并不在服务端的类路径中这也就意味着当我们在FileSystemClassLoader调用findClass()方法时findClass()调用内在的defineClass()方法类clientTaskImpl被特定的类加载器实例所定义因此当FileSystemClassLoader的一个新的实例被使用类又被重新定义为字节数组因此对每个客户端请求类clientTaskImpl被多次定义我们就可以在相同执行引擎JVM中执行不同的clientTaskImpl的代码
public void execute(String codeName byte[] code)throws RemoteException{
FileSystemClassLoader fileSystemClassLoader = null;
try{
fileSystemClassLoader = new FileSystemClassLoader();
fileSystemClassLoaderexecute(codeName code);
}
catch(Exception exception){
throw new RemoteException(exceptiongetMessage());
}
}
示例在differentversionspush文件夹下服务端和客户端的控制台界面分别如图所示
图 定制类加载器执行引擎
图显示的是定制的类加载器控制台我们可以看到clientTaskImpl的代码被多次加载实际上针对每一个客户端类都被加载并初始化
图 定制类加载器客户端
图中含有clientTaskImplclassgetClassLoader(v)的日志记录的类TaskImpl的代码被客户端的VM加载然后送到服务端图 另一个客户端把包含有clientTaskImplclassgetClassLoader(v)的类代码加载并送往服务端
图 定制类加载器客户端
这段代码演示了我们如何利用不同的类加载器实例来在同一个VM上执行不同版本的代码
JEE的类加载器
JEE的服务器倾向于以一定间隔频率丢弃原有的类并重新载入新的类在某些情况下会这样执行而有些情况则不同样对于一个web服务器如果要丢弃一个servlet实例可能是服务器管理员的手动操作也可能是此实例长时间未相应当一个JSP页面被首次请求容器会把此JSP页面翻译成一个具有特定形式的servlet代码一旦servlet代码被创建容器就会把这个servlet翻译成class文件等待被使用对于提交给容器的每次请求容器都会首先检查这个JSP文件是否刚被修改过是的话就重新翻译此文件这可以确保每次的请求都是及时更新的企业级的部署方案以ear war rar等形式的文件同样需要重复加载可能是随意的也可能是依照某种配置方案定期执行对所有的这些情况——类的加载卸载重新加载……全部都是建立在我们控制应用服务器的类加载机制的基础上的实现这些需要扩展的类加载器它可以执行由其自身所定义的类Brett Peterson已经在他的文章 Understanding JEE Application Server Class Loading Architectures给出了JEE应用服务器的类加载方案的详细说明详见网站
结要
本文探讨了类载入到虚拟机是如何进行唯一标识的以及类如果存在同样的类名和包名时所产生的问题因为没有一个直接可用的类版本管理机制所以如果我们要按自己的意愿来加载类时需要自己订制类加载器来扩展其行为我们可以利用许多JEE服务器所提供的热部署功能来重新加载一个新版本的类而不改动服务器的VM即使不涉及应用服务器我们也可以利用定制类加载器来控制java应用程序载入类时的具体行为Ted Neward的书ServerBased Java Programming中详细阐述java的类加载JEE的API以及使用他们的最佳途径
