java ClassLoad详解

ClassLoader基本概念

JVM在运行时会产生三个ClassLoader，Bootstrap ClassLoader、Extension ClassLoader和AppClassLoader.AppClassLoader的Parent是ExtClassLoader，而ExtClassLoader的Parent为Bootstrap ClassLoader。

Bootstrap是用C++编写的，我们在Java中看不到它，是null。它用来加载核心类库，在JVM源代码中这样写道：
static const char classpathFormat[] =
"%/lib/rt.jar:"
"%/lib/i18n.jar:"
"%/lib/sunrsasign.jar:"
"%/lib/jsse.jar:"
"%/lib/jce.jar:"
"%/lib/charsets.jar:"
"%/classes";

Extension ClassLoader用来加载扩展类，即%/lib/ext中的类。

最后AppClassLoader才是加载Classpath的。

Java提供了抽象类ClassLoader，所有用户自定义类装载器都实例化自ClassLoader的子类。 System Class Loader是一个特殊的用户自定义类装载器，由JVM的实现者提供，在编程者不特别指定装载器的情况下默认装载用户类。系统类装载器可以通过ClassLoader.getSystemClassLoader() 方法得到.

Parent Delegation模型

在此模型下，当一个装载器被请求装载某个类时，它首先委托自己的parent去装载，若parent能装载，则返回这个类所对应的Class对象，若parent不能装载，则由parent的请求者去装载

为什么要Parent Delegation？安全。因为在此模型下用户自定义的类装载器不可能装载应该由父亲装载器装载的可靠类，从而防止不可靠甚至恶意的代码代替由父亲装载器装载的可靠代码。实际上，类装载器的编写者可以自由选择不用把请求委托给parent，但正如上所说，会带来安全的问题。

比如在Applet中，如果编写了一个java.lang.String类并具有破坏性。假如不采用这种委托机制，就会将这个具有破坏性的String加载到了用户机器上，导致破坏用户安全。但采用这种委托机制则不会出现这种情况。因为要加载java.lang.String类时，系统最终会由 Bootstrap进行加载，这个具有破坏性的String永远没有机会加载。

扩展ClassLoader

我们目的是从本地文件系统使用我们实现的类装载器装载一个类。为了创建自己的类装载器我们应该扩展ClassLoader类，这是一个抽象类。我们创建一个FileClassLoader extends ClassLoader。我们需要覆盖ClassLoader中的findClass(String name)方法，这个方法通过类的名字而得到一个Class对象。

	public Class findClass(String name) {
		byte[] data = loadClassData(name);
		return defineClass(name, data, 0, data.length);
	}

    我们还应该提供一个方法loadClassData(String name)，通过类的名称返回class文件的字节数组。然后使用ClassLoader提供的defineClass()方法我们就可以返回Class对象了。

	public byte[] loadClassData(String name) {
		FileInputStream fis = null;
		byte[] data = null;
		try {
			fis = new FileInputStream(new File(drive + name + fileType));
			ByteArrayOutputStream baos = new ByteArrayOutputStream();
			int ch = 0;
			while ((ch = fis.read()) != -1) {
				baos.write(ch);
			}
			data = baos.toByteArray();
		} catch (IOException e) {
			e.printStackTrace();
		}
		return data;
	}

forName与ClassLoader

Class clazz = Class.forName("XXX.XXX");

与
ClassLoader cl = Thread.currentThread().getContextClassLoader();
Class clazz = cl.loadClass("XXX.XXX");
都可以装载一个类那么他们的区别是什么呢?

进一步研究Class.forName()是调用Class.forName(name, initialize, loader);
也就是Class.forName("XXX.XXX"); 等同与 Class.forName("XXX.XXX", true, CALLCLASS.class.getClassLoader());
第二个参数表示装载类的时候是否初始化该类， 即调用类的静态块的语句及初始化静态成员变量

Class clazz = cl.loadClass("XXX.XXX");没有指定是否初始化的选项。只有执行clazz.newInstance()；时才能够初始化类。可以说 Class.forName("XXX.XXX", false, cl)执行过程是一致的。只是ClassLoader.loadClass()是更底层的操作。

Context ClassLoader

Context ClassLoader提供一个突破委托代理机制的后门。虚拟机通过父子层次关系组织管理ClassLoader，每个ClassLoader都有一个 Parent ClassLoader（BootStartp不在此范围之内），当要求一个ClassLoader装载一个类是，他首先请求Parent ClassLoader去装载，只有parent ClassLoader装载失败，才会尝试自己装载。

但是，某些时候这种顺序机制会造成困扰，特别是jvm需要动态载入有开发者提供的资源时。就以JNDI为例，JNDI的类是由bootstarp ClassLoader从rt.jar中间载入的，但是JNDI具体的核心驱动是由正式的实现提供的，并且通常会处于-cp参数之下（注：也就是默认的 System ClassLoader管理），这就要求bootstartp ClassLoader去载入只有SystemClassLoader可见的类，正常的逻辑就没办法处理。怎么办呢？parent可以通过获得当前调用 Thread的方法获得调用线程的Context ClassLoder 来载入类。

Classloader存在下面问题：

在一个JVM中可能存在多个ClassLoader，每个ClassLoader拥有自己的 NameSpace。一个ClassLoader只能拥有一个class对象类型的实例，但是不同的ClassLoader可能拥有相同的class对象实例，这时可能产生致命的问题。如ClassLoaderA，装载了类A的类型实例A1，而ClassLoaderB，也装载了类A的对象实例A2。逻辑上讲A1=A2，但是由于A1和A2来自于不同的ClassLoader，它们实际上是完全不同的，如果A中定义了一个静态变量c，则c在不同的 ClassLoader中的值是不同的。

因此，研究JBoss的ClassLoader策略，对于更好地实现EJB组件拼装是用好处的，因为，一个项目中可能要用其他项目的EJB组件，如何实现运行时EJB组件共享，如何实现EJB组件打包是很重要的。