深刻理解java虚拟机【类加载机制】

Java虚拟机类加载过程是把Class类文件加载到内存，并对Class文件中的数据进行校验、转换解析和初始化，最终造成能够被虚拟机直接使用的java类型的过程。

在加载阶段，java虚拟机须要完成如下3件事：

a.经过一个类的全限定名来获取定义此类的二进制字节流。

b.将定义类的二进制字节流所表明的静态存储结构转换为方法区的运行时数据结构。

c.在java堆中生成一个表明该类的java.lang.Class对象，做为方法区数据的访问入口。

Java虚拟机的类加载是经过类加载器实现的， Java中的类加载器体系结构以下：

(1).BootStrap ClassLoader：启动类加载器，负责加载存放在%JAVA_HOME%\lib目录中的，或者通被-Xbootclasspath参数所指定的路径中的，而且被java虚拟机识别的(仅按照文件名识别，如rt.jar，名字不符合的类库，即便放在指定路径中也不会被加载)类库到虚拟机的内存中，启动类加载器没法被java程序直接引用。

(2).Extension ClassLoader：扩展类加载器，由sun.misc.Launcher$ExtClassLoader实现，负责加载%JAVA_HOME%\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的全部类库，开发者能够直接使用扩展类加载器。

(3).Application ClassLoader：应用程序类加载器，由sun.misc.Launcher$AppClassLoader实现，负责加载用户类路径classpath上所指定的类库，是类加载器ClassLoader中的getSystemClassLoader()方法的返回值，开发者能够直接使用应用程序类加载器，若是程序中没有自定义过类加载器，该加载器就是程序中默认的类加载器。

注意：上述三个JDK提供的类加载器虽然是父子类加载器关系，可是没有使用继承，而是使用了组合关系。

从JDK1.2开始，java虚拟机规范推荐开发者使用双亲委派模式(ParentsDelegation Model)进行类加载，其加载过程以下：

(1).若是一个类加载器收到了类加载请求，它首先不会本身去尝试加载这个类，而是把类加载请求委派给父类加载器去完成。

(2).每一层的类加载器都把类加载请求委派给父类加载器，直到全部的类加载请求都应该传递给顶层的启动类加载器。

(3).若是顶层的启动类加载器没法完成加载请求，子类加载器尝试去加载，若是连最初发起类加载请求的类加载器也没法完成加载请求时，将会抛出ClassNotFoundException，而再也不调用其子类加载器去进行类加载。

双亲委派 模式的类加载机制的优势是java类它的类加载器一块儿具有了一种带优先级的层次关系，越是基础的类，越是被上层的类加载器进行加载，保证了java程序的稳定运行。双亲委派模式的实现：

protected synchronized Class<?> loadClass(String name, Boolean resolve) throws ClassNotFoundException{
    //首先检查请求的类是否已经被加载过
    Class c = findLoadedClass(name);
    if(c == null){
    try{
        if(parent != null){//委派父类加载器加载
    c = parent.loadClass(name, false);
}
else{//委派启动类加载器加载
    c = findBootstrapClassOrNull(name);
}
}catch(ClassNotFoundException e){
    //父类加载器没法完成类加载请求
}
if(c == null){//自己类加载器进行类加载
    c = findClass(name);
}
}
if(resolve){
    resolveClass(c);
}
return c;
}

若要实现自定义类加载器，只须要继承java.lang.ClassLoader 类，而且重写其findClass()方法便可。java.lang.ClassLoader 类的基本职责就是根据一个指定的类的名称，找到或者生成其对应的字节代码，而后从这些字节代码中定义出一个 Java 类，即 java.lang.Class 类的一个实例。除此以外，ClassLoader 还负责加载 Java 应用所需的资源，如图像文件和配置文件等，ClassLoader 中与加载类相关的方法以下：

方法	说明
getParent()	返回该类加载器的父类加载器。
loadClass(String name)	加载名称为 二进制名称为name 的类，返回的结果是 java.lang.Class 类的实例。
findClass(String name)	查找名称为 name 的类，返回的结果是 java.lang.Class 类的实例。
findLoadedClass(String name)	查找名称为 name 的已经被加载过的类，返回的结果是 java.lang.Class 类的实例。
resolveClass(Class<?> c)	连接指定的 Java 类。

注意：在JDK1.2以前，类加载还没有引入双亲委派模式，所以实现自定义类加载器时经常重写loadClass方法，提供双亲委派逻辑，从JDK1.2以后，双亲委派模式已经被引入到类加载体系中，自定义类加载器时不须要在本身写双亲委派的逻辑，所以不鼓励重写loadClass方法，而推荐重写findClass方法。

在Java中，任意一个类都须要由加载它的类加载器和这个类自己一同肯定其在java虚拟机中的惟一性，即比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提之下才有意义，不然，即便这两个类来源于同一个Class类文件，只要加载它的类加载器不相同，那么这两个类一定不相等(这里的相等包括表明类的Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法和instanceof关键字的结果)。例子代码以下：

package com.test;

public class ClassLoaderTest {
    public static void main(String[] args)throws Exception{
        //匿名内部类实现自定义类加载器
    ClassLoader myClassLoader = new ClassLoader(){
    protected Class<?> findClass(String name)throws ClassNotFoundException{
        //获取类文件名
    String filename = name.substring(name.lastIndexOf(“.”) + 1) + “.class”;
    InputStream in = getClass().getResourceAsStream(filename);
    if(in == null){
    throw RuntimeException(“Could not found class file:” + filename);
}
byte[] b = new byte[in.available()];
return defineClass(name, b, 0, b.length);
}catch(IOException e){
    throw new ClassNotFoundException(name);
}
};
Object obj = myClassLoader.loadClass(“com.test.ClassLoaderTest”).newInstance();
System.out.println(obj.getClass());
System.out.println(obj instanceof com.test. ClassLoaderTest);
}
}

输出结果以下：

com.test.ClassLoaderTest

false

之因此instanceof会返回false，是由于com.test.ClassLoaderTest类默认使用Application ClassLoader加载，而obj是经过自定义类加载器加载的，类加载不相同，所以不相等。

类加载器双亲委派模型是从JDK1.2之后引入的，而且只是一种推荐的模型，不是强制要求的，所以有一些没有遵循双亲委派模型的特例：

(1).在JDK1.2以前，自定义类加载器都要覆盖loadClass方法去实现加载类的功能，JDK1.2引入双亲委派模型以后，loadClass方法用于委派父类加载器进行类加载，只有父类加载器没法完成类加载请求时才调用本身的findClass方法进行类加载，所以在JDK1.2以前的类加载的loadClass方法没有遵循双亲委派模型，所以在JDK1.2以后，自定义类加载器不推荐覆盖loadClass方法，而只须要覆盖findClass方法便可。

(2).双亲委派模式很好地解决了各个类加载器的基础类统一问题，越基础的类由越上层的类加载器进行加载，可是这个基础类统一有一个不足，当基础类想要调用回下层的用户代码时没法委派子类加载器进行类加载。为了解决这个问题JDK引入了ThreadContext线程上下文，经过线程上下文的setContextClassLoader方法能够设置线程上下文类加载器。

JavaEE只是一个规范，sun公司只给出了接口规范，具体的实现由各个厂商进行实现，所以JNDI，JDBC,JAXB等这些第三方的实现库就能够被JDK的类库所调用。线程上下文类加载器也没有遵循双亲委派模型。

(3).近年来的热码替换，模块热部署等应用要求不用重启java虚拟机就能够实现代码模块的即插即用，催生了OSGi技术，在OSGi中类加载器体系被发展为网状结构。OSGi也没有彻底遵循双亲委派模型。