Class Loading －－－（类装载机制，开发者不得不知道的故事）
理解CLassLoader
也许你欣然以为这样写没问题，但实际上你错了。
java.lang.Class klass = Myclass.class;
JDK中除了ClassLoader可以加载类之外，还有以下这些也可以。
java.net.URLClassLoaderjava.security.SecureClassLoaderjava.rmi.server.RMIClassLoadersun.applet.AppletClassLoader
(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 = parent.loadClass(name, false);
} else {
c = findBootstrapClass0(name);
}
} catch (ClassNotFoundException e) {
// If still not found, then invoke
// findClass to find the class.
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
public MyClassLoader(){
super(MyClassLoader.class.getClassLoader());
}
}
public MyClassLoader(){
super(getClass().getClassLoader());
}
}
protected Class findClass(String name)
throws ClassNotFoundException {
throw new ClassNotFoundException(name);
}
每个ClassLoader出来的类都是不同的， 如果有两个ClassLoader载入两各相同的程序，defineClass()定义得两个类也是不同得。详细请看（Java language specification）
根据上面得解析，既然由两个classLoader()载入Target.class得字节码 ，那defineClass()就会产生两个class的定义。
Target target1 = (Target) target2; 是不正确的 。target1 和 target2是由两个不同的classloader定义的。
上面说一个class标识是由于package+classname组成得。 对于所有实现java.io.Serializable接口的类，都是由serialVersionUID管理这些类得版本(RMI,JNDI,Security里都有这样一个ID) 。它用64位的Hash来表示 (这个Hash由classname,filed,method组成)。从技术上讲如果classname,field,mehtod所构成的Hash都一样，那就会认为是同一个版本。
log("this = " + this + "; Version.fx(1).");
}
log("this = " + this + "; Version.fx(2).");
}
%JAVA_HOME%/bin/java Test 结果如下图
图 3. classPath得目录设为v1
%JAVA_HOME%/bin/java Test
结果如下图：
图 4. classpath目录设为v2
很明显，上面的例子中能从classpath中找到先后次序。如果我们把v1,v2的version.Version。都删调。而把他们打成一个myextension.jar包，放到java.ext.dirs目录下。。这时候就通过ExtClassLoader来装载了，而不是AppClassLoader.
结果会是如下：
图 5. AppClassLoader and ExtClassLoader
注意看 sun.misc.Launcher$ExtClassLoader@a9c85c 这说明是ExtClassLoader 加载了。
继续往下看，另外一个例子。 在differentversions 目录下的例子，里面包含了RMI的ServerImpl这样一个执行引擎。Client实现了common.TaskIntf接口。 两个 client.TaskImpl分别如下：
static{
log("client.TaskImpl.class.getClassLoader
(v1) : " + TaskImpl.class.getClassLoader());
}
public void execute(){
log("this = " + this + "; execute(1)");
}
另一个则是：
static{
log("client.TaskImpl.class.getClassLoader
(v1) : " + TaskImpl.class.getClassLoader());
}
public void execute(){
log("this = " + this + "; execute(2)");
}
这样子来执行（顺序随便，这里把 %CURRENT_ROOT%/client2放在前面）：
CLASSPATH=%CURRENT_ROOT%/common;%CURRENT_ROOT%/server;
%CURRENT_ROOT%/client2;%CURRENT_ROOT%/client1
%JAVA_HOME%/bin/java server.Server
先启动Server..
分别把两个client提交给服务器执行， (即便执行程序中得client1.bat 和 client2.bat server监控屏幕如图6所示。)
图 6. Execution Engine Server console
再来看下面两个图（图7和图8），分别是client端得执行显示。
图 7. Execution Engine Client 1 console
图 8. Execution Engine Client 2 console
纵观上面三次执行结果，发现由于服务器启动得时候使用了AppClassLoader.所以无论怎么样都是载入得是client2(因为client2的classpath次序比较在前)，
这里client1 很郁闷，它在自己那执行明明是 execute(1) 通过 RMI 发送给服务器端执行就成了 execute(2)..
值得注意的是： 在client1,client2分别发送给服务器执行之后，服务器端显示的记录是：
client.TaskImpl.class.getClassLoader(v2):sun.misc.lancuher@AppClassLoader@xxxx zhiz只执行了一次。而this=client.TaskImpl@xxxxx execute(2);执行了两次
上面已经讲到过了，对于一个ClassLoader来讲 同样的page+className 只能定义一个 class,而不同的ClassLoader即便加载同一个page.className 也会定义不同的class
到这里，我才发现，解决上面提出得那个问题似乎并不容易。：（。
那如何解决呢？答案就是－－－使用自定义得classLoader ..
如果各位等不急的话， 先请看（目录中 differentversionspush 里面的代码）
很显然，我们很有必要写自定义的classloader.
如何构造使用自定义的ClassLoader
既然自定义的ClassLoader,能解决上述问题，那接下去看看，我们如何来使用自定义的ClassLoader。
结合本文种的原码－－－（在differentversionspush的目录里），有个FileSystemClassLoader，类图描述如下：
图9.
看看他的方法 findClassBytes(String className);
public byte[] findClassBytes(String className){
try{
String pathName = currentRoot +
File.separatorChar + className.
replace('.', File.separatorChar)
+ ".class";
FileInputStream inFile = new
FileInputStream(pathName);
byte[] classBytes = new
byte[inFile.available()];
inFile.read(classBytes);
return classBytes;
}
catch (java.io.IOException 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,
0, classBytes.length);
}
}
public Class findClass(String name, byte[]
classBytes)throws ClassNotFoundException{
if (classBytes==null){
throw new ClassNotFoundException(
"(classBytes==null)");
}
else{
return defineClass(name, classBytes,
0, classBytes.length);
}
}
public void execute(String codeName,
byte[] code){
Class klass = null;
try{
klass = findClass(codeName, code);
TaskIntf task = (TaskIntf)
klass.newInstance();
task.execute();
}
catch(Exception exception){
exception.printStackTrace();
}
}
这个类FileSystemClassLoader 被client使用了，用来定义class， 并且把它把client.TaskImpl(v1)转化为 byte[], 然后 byte[]发送到RMI Server执行。（上面讲了defineClass()能够执行任何字节码，来自编译后的文件，网络甚至是BCEL 字节码引擎库）, 在Server端 ，又可以通过FileSystemClassLoader 以为byte[]的形式定义出 client.TaskImpl。
请看Client端的代码：
public class Client{
public static void main (String[] args){
try{
byte[] code = getClassDefinition
("client.TaskImpl");
serverIntf.execute("client.TaskImpl",
code);
}
catch(RemoteException remoteException){
remoteException.printStackTrace();
}
}
private static byte[] getClassDefinition
(String codeName){
String userDir = System.getProperties().
getProperty("BytePath");
FileSystemClassLoader fscl1 = null;
try{
fscl1 = new FileSystemClassLoader
(userDir);
}
catch(FileNotFoundException
fileNotFoundException){
fileNotFoundException.printStackTrace();
}
return fscl1.findClassBytes(codeName);
}
}
在RMI服务器端ServerImpl 程序里， 接受到来自client的字节码（byte[]），于是FileSystemClassLoader 会从byte[]构造出一个class, 实例话，并且执行。
有一点要注意：每次接收到一个client的请求，FileSystemClassLoader都会重新实例化（执行结果中可以看出来），这就意味着，client.Impl不在是在classpath中被找到的，而是通过FileSystemClassLoader 的findClass() 来执行deFineClass()，这样每次 FileSystemClassLoader 都是创建新的实例，，自然 deFine出来的class也是不同的。 这样，我们就能在RMI的执行中区分出 这两个class来。（client.TaskImpl ！= client.TaskImp 在上篇就已经得出结论了。 ）
看看服务器端的执行代码：
public void execute(String codeName, byte[] code)throws RemoteException{
FileSystemClassLoader fileSystemClassLoader = null;
try{
fileSystemClassLoader = new FileSystemClassLoader();
fileSystemClassLoader.execute(codeName, code);
}
catch(Exception exception){
throw new RemoteException(exception.getMessage());
}
}
服务器端的执行结果：
图10，服务器端显示
下面两图分别是客户端显示的。
图11. client1的执行显示
图12. client2执行结果
哈，上面洋洋洒洒那么多，总算是一步一步的教会了大家 如何在同一个VM虚拟机中，执行“不同版本”的代码 。（这些代码有同样的类名和包名）。
Class Loaders 在 J2EE 中应用。
我的一个A_war.war的web项目中 代码是 com.mycom.Test 而我在另外一个B_war.war的wenb项目中的 代码也是com.mycom.Test 而他们照样工作的好好的。
当一个大型的 EJB项目，一台服务器上部署了多个 EJB,War工程时候，他们也不会互相影响。AppServer还会有自己的装载策略，比如你web中用的jar包，会优先于AppServer本身所带有的。
另外，J2EE的ClassLoader机制更详细的能容你可以参考Tss上的这篇文章。 Understanding J2EE Application Server Class Loading Architectures "
资源文件：
Sample code for this article JDK 1.5 API Docs The Java language specification " Understanding Extension Class Loading " in the Java tutorial " Inside Class Loaders " from ONJava " Inside Class Loaders: Debugging " from ONJava " What version is your Java code? " from JavaWorld " Understanding J2EE Application Server Class Loading Architectures " from TheServerSide Byte Code Engineering Library Server-Based Java Programming by Ted Neward
原文：
http://www.onjava.com/pub/a/onjava/2005/01/26/classloading.htm