java类加载器学习2——自定义类加载器和父类委托机制带来的问题/JAVA类加载的委托模型/Java的委托

http://blog.sina.com.cn/s/blog_67aaf44401015krv.html

一、自定义类加载器的一般步骤
 
Java的类加载器自从JDK1.2开始便引入了一条机制叫做父类委托机制。一个类需要被加载的时候，JVM先会调用他的父类加载器进行加载，父类调用父类的父类，一直到顶级类加载器。如果父类加载器加载不了，依次再使用其子类进行加载。当然这类所说的父类加载器，不一定他们之间是继承的关系，有可能仅仅是包装的关系。
 
Java之所以出现这条机制，因为是处于安全性考虑。害怕用户自己定义class文件然后自己写一个类加载器来加载原本应该是JVM自己加载的类。这样会是JVM虚拟机混乱或者说会影响到用户的安全。下面我们来自己实现一个类加载器，其中主要就是继承ClassLoader类。我们有必要明白：
 
虽然在绝大多数情况下系统默认提供的类加载器实现已经可以满足需求。但是在某些情况下，您还是需要为应用开发出自己的类加载器。比如您的应用通过网络来传输Java类的字节代码，为了保证安全性，这些字节码经过了加密处理。这个时候您就需要自己的类加载器来从某个网络地址上读取加密后的字节代码，接着进行解密和验证，最后定义出要在Java
虚拟机中运行的类来。下面将通过两个具体的实例来说明类加载器的开发。
 
①ClassLoader加载类的顺序
1调用findLoadedClass(String) 来检查是否已经加载类
2在父类加载器上调用loadClass方法。如果父亲不能加载，一次一级一级传给子类
3调用子类findClass(String)方法查找类。若还加载不了就返回ClassNotFoundException，不交给发起请求的加载器的子加载器
 
②实现自己的类加载器
1 获取类的class文件的字节数组，如loadClassData方法
2将字节数组转换为Class类的实例，重写findClass中调用的defineClass方法
package cn.M_ClassLoader2;
import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.FileInputStream;

public class ClassLoaderTest
{
public static void main(String[] args) throwsInstantiationException, IllegalAccessException, ClassNotFoundException
{
// 新建一个类加载器
MyClassLoader cl = newMyClassLoader("myClassLoader");

// 加载类，得到Class对象
Class<?>clazz = cl.loadClass("cn.M_ClassLoader2.Animal");

// 得到类的实例
Animal animal = (Animal)clazz.newInstance();
animal.say();
}
}
class Animal
{
public void say()
{
System.out.println("helloworld!");
}
}
class MyClassLoader extends ClassLoader
{
// 类加载器的名称
private String name;

// 类存放的路径
private String path =MyClassLoader.getSystemClassLoader().getResource("").getPath();;
MyClassLoader(String name)
{
this.name = name;
}
MyClassLoader(ClassLoader parent, Stringname)
{
super(parent);
this.name = name;
}

@Override
public Class<?>findClass(String name)
{
byte[] data =loadClassData(name);
return this.defineClass(name,data, 0, data.length);
}
public byte[] loadClassData(String name)
{
try
{
name =name.replace(".", "//");
FileInputStreamis = new FileInputStream(new File(path + name + ".myclass"));
ByteArrayOutputStreambaos = new ByteArrayOutputStream();
int b =0;
while ((b =is.read()) != -1)
{
baos.write(b);
}
System.out.println("我是自定义类加载器哦！");
returnbaos.toByteArray();
}
catch (Exception e)
{
e.printStackTrace();
}
return null;
}
}

一般来说自己开发的类加载器只需要覆写

findClass(Stringname)

方法即可。

java.lang.ClassLoader

类的方法

loadClass()

封装了前面提到的代理模式的实现。该方法会首先调用

findLoadedClass()

方法来检查该类是否已经被加载过；如果没有加载过的话，会调用父类加载器的

loadClass()

方法来尝试加载该类；如果父类加载器无法加载该类的话，就调用

findClass()

方法来查找该类。因此，为了保证类加载器都正确实现代理模式，在开发自己的类加载器时，最好不要覆写

loadClass()

方法，而是覆写

findClass()

方法。
 
 
二、自定义类加载器的运行问题
 
由于只重写了findClass方法并没有重写loadClass方法，故没有改变父类委托机制。也就数说如果某个.class可以被父类加载，我们自定义的类加载器就不会被执行了。比如Animal.java被自动编译为Animal.class放在bin目录下，AppClassLoader完全可以加载，所以就不调用自定义的加载器了。
 
尝试办法1：把Animal.class放在别的目录中比如D盘的根目录下
报 Class A can not access amember of class B with modifiers""错。Java语言中的包访问成员实际上指的是运行时包访问可见，而不是编译时。因此当你试图访问不在同一个runtimepackage的成员时，即便在编译时它们在同一个包内，但是却由不同的classloader加载，也同样会得到java.lang.IllegalAccessException:
Class A can notaccess a member of class B with modifiers "" 这样的异常。
 
尝试办法2：把该Animal.class的后缀名为.myClass，让AppClassLoader找不到
网上有人说可以解决，但是我实验的结果是会和办法1报一样的异常。
 
尝试办法3：解决方案是通过扩展自定义的ClassLoader，重写loadClass方法先从当前类加载器加载再从父类加载器加载。
该解决办法是可以解决的，网址是http://blog.csdn.net/zhangxinrun/article/details/6161426
 
 
参考博客
http://blog.csdn.net/zhangxinrun/article/details/6161426
http://blog.csdn.net/zhouysh/article/details/762300
http://blog.csdn.net/a352193394/article/details/7343385
http://blog.csdn.net/huangbiao86/article/details/6910152
http://www.cnblogs.com/feiling/archive/2012/08/29/2662909.html (加密字节码)

================================================================================

关于JAVA的类加载器，网上有很多这方面资料，这里只做测试，不多累述。JVM有三个内置加载器:          
bootstrapClassLoader(由C语言编写，固化在jvm上）、ExtClassLoader、AppClassLoader。三个加载器从上到下呈父子关系，形成了“类加载委托模型”：即儿子的事情，父亲能做的，他一定会代劳（以免累到儿子），父亲的事情，一定会自已做，即使自已无法完成，也不会劳及儿子。三个类的加载路径分别为(更多细节参考google)：

BootstrapClassLoader:    sun.boot.class.path 

ExtClassLoader:     java.ext.dirs                                                                                   AppClassLoader:     java.class.path

 

 首先定义两个类：
package loader;

public class ClassA {
public static void main(String args[]){
System.out.println("ClassA: " + ClassA.class.getClassLoader());
ClassB a = new ClassB();
System.out.println("ClassB: " + ClassA.class.getClassLoader());
}
}
//
package loader;

public class ClassB {
}

拷贝三份到：C:\Java\jre6\classes(bootstrapClassLoader的搜索目录之一)，C:\Java\jre6\lib\ext\classes(extClassLoader的搜索目录之一)，F:\javawork\study\bin目录下，其中C:\Java\jre6为我JRE目录。一定不要搞错，因为你的机器可能会有很多JRE。

CMD到F:\javawork\study\bin目录

1. F:\javawork\study\bin>Java loader.ClassA

ClassA: null

ClassB: null

两个都为空，这是因为当AppClassLoader(默认的系统类加载器)来加载CLASSA，首先委托其父ExtClassLoader去加载，然后AppClassLoader委托bootstrapClassLoader去加载，bootstrapClassLoader没有父加载器，只能自已完成，在自已加载目录C:\Java\jre6\classes下找到了CLASSA，加载成功。然后CLASSA的加载器bootstrapClassLoader加载CLASSB，同样在C:\Java\jre6\classes找到CLASSB，所以两个类的加载器都是bootstrapClassLoader，因为bootstrapClassLoader实现于C++，所以返回NULL。

2. 删除C:\Java\jre6\classes目录下的CLASSB

F:\javawork\study\bin>java loader.ClassA

ClassA: null

Exception in thread "main" java.lang.NoClassDefFoundError: loader/ClassB

        at loader.ClassA.main(ClassA.java:6)

这是因为同（1）一样，最后由bootstrapClassLoader成功加载CLASSA，然后由CLASSA(这里叫CLASSB的CALLER)的加载器bootstrapClassLoader需要去加载CLASSB，但bootstrapClassLoader尽其力也没能找到（因为被我删了），这位慈爱的父亲到最后一刻都没有交给儿子ExtClassLoader去做，最后上报：我无能为力。

3.把（2）中删除的CLASSB还原，同时删创除该目录下的CLASSA

F:\javawork\study\bin>java loader.ClassA

ClassA: sun.misc.Launcher$ExtClassLoader@126b249

ClassB: null

两个都输出ExtClassLoader，顺着（1）的思路，AppClassLoader委托ExtClassLoader，ExtClassLoader委托bootstrapClassLoader，bootstrapClassLoader找不到CLASSA,只能放手让儿子去做（比如找女朋友这事，小伙子本来想老爸战友的女儿不错，可父亲去提亲，人家不应，“不行，儿子，你自个追其他的吧！”）。ExtClassLoader绝地逢生，在自已的区域内找到了CLASSA。然后CLASSA的加载器ExtClassLoader去加CLASSB,
同样道理这事交给老爸bootstrapClassLoader去做，bootstrapClassLoader责无旁贷，顺利完成，所以ClassB: null。

4.把（3）中剩下的CLASSB也删除。

 F:\javawork\study\bin>java loader.ClassA

ClassA: sun.misc.Launcher$ExtClassLoader@ad3ba4

ClassB: sun.misc.Launcher$ExtClassLoader@ad3ba4

同(1)一样，ExtClassLoader绝地逢生，在自已的区域内找到了CLASSA，然后CLASSA的加载器ExtClassLoader去加CLASSB，不幸的事，这次老爸bootstrapClassLoader却无能为力（被我CUT了）。最后ExtClassLoader自已搞定。

5.继序（4）删除C:\Java\jre6\lib\ext\classes目录下的CLASSB

F:\javawork\study\bin>java loader.ClassA

ClassA: sun.misc.Launcher$ExtClassLoader@126b249

Exception in thread "main" java.lang.NoClassDefFoundError: loader/ClassB

        at loader.ClassA.main(ClassA.java:6)

按上面的思路，你一定知道为什么。

6.还原（5）中删除的CLASSB，同时删除CLASSA.

F:\javawork\study\bin>java loader.ClassA

ClassA: sun.misc.Launcher$AppClassLoader@ad3ba4

ClassB: sun.misc.Launcher$ExtClassLoader@126b249

AppClassLoader(默认的系统类加载器)来加载CLASSA，首先委托其父ExtClassLoader去加载，然后AppClassLoader委托bootstrapClassLoader去加载.可两们前辈都无能为力，最后还是落到了AppClassLoader身上，少年英雄很快实现自已的梦想，成功加载CLASSA，然后其CLASSA的加载器（还是AppClassLoader）再去加载CLASSB，喜出望外的是，老爸ExtClassLoader代其完成，大功告成。

7.继序（6）删除C:\Java\jre6\lib\ext\classes目录下的CLASSB 

F:\javawork\study\bin>java loader.ClassA

ClassA: sun.misc.Launcher$AppClassLoader@ad3ba4

ClassB: sun.misc.Launcher$AppClassLoader@ad3ba4

同样道理，委托，委托。但这次AppClassLoader在我的破坏下（我删，删），只能自力更生。完成加载。

有一点问题，在测试过程中我的本机并没有CLASSPATH变量：

F:\javawork\study\bin>set classpath

环境变量 classpath 没有定义

但System.out.println(System.getProperty("java.class.path")) 输出：. 即当前目录作为了classpath.

本文出自 “天下无贼” 博客，请务必保留此出处http://guojuanjun.blog.51cto.com/277646/464708

====================================================================================
委托模式是软件设计模式中的一项基本技巧。在委托模式中，有两个对象参与处理同一个请求，接受请求的对象将请求委托给另一个对象来处理。委托模式是一项基本技巧，许多其他的模式，如状态模式、策略模式、访问者模式 本质上是在更特殊的场合采用了委托模式。委托模式使得我们可以用聚合来替代继承，它还使我们可以模拟mixin。

  “委托”在C#中是一个语言级特性，而在Java语言中没有直接的对应，但是我们可以通过动态代理来实现委托！代码如下：
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;

public abstract class Delegator implements InvocationHandler {
//--------------------------------------------

protected Object obj_orgin = null; //原始对象
protected Object obj_proxy = null; //代理对象
//--------------------------------------------

public Delegator() {
}

public Delegator(Object orgin) {
this.createProxy(orgin);
}

protected Object createProxy(Object orgin) {
obj_orgin = orgin;
//下面语句中orgin.getClass().getClassLoader()为加载器，orgin.getClass().getInterfaces()为接口集
obj_proxy = Proxy.newProxyInstance(orgin.getClass().getClassLoader(), orgin.getClass().getInterfaces(), this); //委托
return obj_proxy;
}

protected Object invokeSuper(Method method, Object[] args) throws Throwable {
return method.invoke(obj_orgin, args);
}
//--------------实现InvocationHandler接口，要求覆盖------------
//下面实现的方法是当委托的类调用toString()方法时，操作其他方法而不是该类默认的toString()，这个类的其他方法则不会。

public Object invoke(Object obj, Method method, Object[] args) throws Throwable {
// 缺省实现：委托给obj_orgin完成对应的操作
if (method.getName().equals("toString")) { //对其做额外处理
return this.invokeSuper(method, args) + "$Proxy";
} else { //注意，调用原始对象的方法，而不是代理的（obj==obj_proxy）
return this.invokeSuper(method, args);
}
}
}

下面的代码，则是作为一个委托的例子，实现Map的功能。
import java.io.IOException;
import java.lang.reflect.Method;
import java.util.Hashtable;
import java.util.Map;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import com.bs2.core.UtilLog;

public class Delegator4Map extends Delegator {
private static Log _log = LogFactory.getLog(Delegator4Map.class);
private Map orginClass = null; //原始对象
private Map proxyClass = null; //代理对象

public Map getOrgin() {
return orginClass;
}

public Map getProxy() {
return proxyClass;
}

public Delegator4Map(Map orgin) {
super(orgin);
orginClass = orgin;
proxyClass = (Map) super.obj_proxy;
}

public Object invoke(Object obj, Method method, Object[] args) throws Throwable {
if (method.getName().equals("size")) { //修改size处理逻辑
Object res2 = new Integer(-1);
System.out.println("调用委托的方法");
return res2;
} else {
System.out.println("调用原始的方法");
return super.invoke(obj, method, args);
}
}

public static void main(String[] args) throws IOException {
Delegator4Map rtm = new Delegator4Map(new Hashtable());
Map m = rtm.getProxy();
m.size();
}
}