http://blog.csdn.net/totodo/archive/2005/01/28/271798.aspx
也许你认为Class Load是一个高级话题,不管怎样,作为开发者你还是要了解它。
java.lang.Class klass = Myclass.class;
而实例化一个类,可以是:Myclass myclass = new Myclass() 也可以是: myclass.newInstance();
java.net.URLClassLoader
java.security.SecureClassLoader
java.rmi.server.RMIClassLoader
sun.applet.AppletClassLoader
图 3.
classPath得目录设为v1
图 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虚拟机中,执行“不同版本”的代码 。(这些代码有同样的类名和包名)。
原文:
http://www.onjava.com/pub/a/onjava/2005/01/26/classloading.htm
Class Loading ---(类装载机制,开发者不得不知道的故事)