Java类加载机制

类加载机制

在Java面试中类加载机制是十分常见的考察点，时常和JVM内存模型，JVM内存管理，反射等知识点穿插考察

ClassLoader

ClassLoader故名思意是用来加载类的，在Java语言中有几种类加载器

BootStrapClassLoader

启动类加载器，用来加载核心类库如JAVA_HOME/jre/lib下的核心类库（rt.jar等），这个类加载器是JVM的一部分，使用C++语言实现，用户的Java程序无法直接引用到

ExtClassLoader

用来加载JAVA_HOME/jre/lib/ext目录中的类或者由系统变量java.ext.dir指定位置中的类，是Launcher中的一个内部类sun.misc.Launcher$ExtClassLoader

AppClassLoader

Java中最常用到的一个类加载器，是Launcher中的内部类sun.misc.Launcher$AppClassLoader从环境变量classPath或者系统属性java.class.path所指定的目录中加载类，如果用户没有自定义类加载器的话，一般会使用该类来加载用户编写的Java类，同时也是自定义类加载器的父类加载器，该类加载器可以通过ClassLoader.getSystemClassLoader()方法直接获取到

自定义的ClassLoader

用户自定义的类加载器，一般继承自ClassLoader重写findClass方法

除了BootStrapClassLoader外，其他的类加载器都有其父类加载器

Java类加载的流程

Java程序进行编译后产生了.class结尾的字节码文件，而Java类加载就是要完成字节码（二进制）文件加载到内存实例化生成相应的Class对象的过程，类加载的流程可以分为

加载类文件到内存中首先需要定位到字节码文件的位置，反映在代码中就是classLoader这个抽象类中的findClass方法，然后就是defineClass方法实例化该类对应的Class对象
链接(Linking) 通过resolveClass方法进行链接操作，整个Linking过程可以分为几个步骤，（1）验证（2）准备（3）解析，其中准备阶段包括了类中静态成员变量的内存分配和默认值赋值，解析是将符号引用替换为直接引用的过程
类初始化阶段这个阶段完成静态成员的初始化和静态代码块的执行，初始化的执行顺序和代码中的顺序是相同的

经过上面的几个步骤，在JVM中就存在了该类所对应的Class对象，类的加载过程就完成了

双亲委派模型

双亲委派模型图示

双亲委派流程

某一个类加载器在收到加载类的请求时，首先查看这个类是不是已经被加载了，如果已经被加载了就直接返回，否则交由其父类加载器进行加载(parent.loadClass)，依次递归，如果父类加载器可以完成加载任务就成功返回Class对象，否则抛出ClassNotFoundException后，下一级类加载器调用findClass方法进行加载,也就是说原则上父类加载器优先于子类加载器

双亲委派流程

图片来自http://blog.csdn.net/irelandken/article/details/7048817

双亲委派优点

双亲委派的优点就是更加安全，保证了类的唯一性，比如说，自己编写了一个java.lang.Object类让多个类加载器去加载这个类，这样在内存中就出现了多个Object类，会给虚拟机带来安全隐患，如果是使用双亲委派进行加载，那么就保证了Object类的唯一性

源码角度看类加载

ClassLoader.java

public static ClassLoader getSystemClassLoader() {
    initSystemClassLoader(); //初始化系统类加载器
    if (scl == null) {
        return null; 
    } 
    SecurityManager sm = System.getSecurityManager();
    if (sm != null) { 
        ClassLoader ccl = getCallerClassLoader();
        if (ccl != null && ccl != scl && !scl.isAncestor(ccl)){
            sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION);
        }
    } 
    return scl;
}

private static synchronized void initSystemClassLoader(){ 
    if (!sclSet) { 
        if (scl != null) 
            throw new IllegalStateException("recursive invocation"); 
        sun.misc.Launcher l = sun.misc.Launcher.getLauncher(); 
        if (l != null) { 
            Throwable oops = null;
            scl = l.getClassLoader(); 
            try { 
                scl = AccessController.doPrivileged( 
                    new SystemClassLoaderAction(scl)); 
            } catch (PrivilegedActionException pae) { 
                oops = pae.getCause(); 
                if (oops instanceof InvocationTargetException) { 
                    oops = oops.getCause(); 
                }
            } if (oops != null) {
                if (oops instanceof Error) { 
                    throw (Error) oops; 
                } else { 
                    throw new Error(oops); 
                } 
            }
        } 
        sclSet = true; 
    }


protected Class loadClass(String name, boolean resolve) throws ClassNotFoundException 
{ 
    synchronized (getClassLoadingLock(name)) { 
        //检查该类是否已经加载过 
        Class c = findLoadedClass(name); 
        if (c == null) { 
            //如果该类没有加载
            long t0 = System.nanoTime(); 
            try { 
                if (parent != null) { 
                    //当父类的加载器不为空，则通过父类加载器的loadClass来加载该类
                    c = parent.loadClass(name, false);
                } else { 
                    //当父类加载器为空，则调用启动类加载器来加载该类 
                    c = findBootstrapClassOrNull(name);
                } 
                } catch (ClassNotFoundException e) { 
                  //类没有找到抛出异常
                } 
                if (c == null) {
                    long t1 = System.nanoTime();
                    //当父类加载器无法加载时，则调用findClass方法来加载该类
                    //用户可通过覆写该方法，来自定义类加载器
                    c = findClass(name);  
                    //用于统计类加载器相关的信息
                    sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0); 
                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1); 
                    sun.misc.PerfCounter.getFindClasses().increment();
                } 
        } 
        if (resolve) { 
            //对类进行连接操作 
            resolveClass(c); 
        }
        return c;
    }
}

ClassLoader的双亲委派机制是这样的（这里先忽略掉自定义类加载器CustomClassLoader）：

当AppClassLoader加载一个class时，它首先不会自己去尝试加载这个类，而是把类加载请求委派给父类加载器ExtClassLoader去完成
当ExtClassLoader加载一个class时，它首先也不会自己去尝试加载这个类，而是把类加载请求委派给BootStrapClassLoader去完成
如果BootStrapClassLoader加载失败（例如在$JAVA_HOME/jre/lib里未查找到该class），会使用ExtClassLoader来尝试加载
若ExtClassLoader也加载失败，则会使用AppClassLoader来加载，如果AppClassLoader也加载失败，则会报出异常ClassNotFoundException

另外，虽然ClassLoader加载类是使用loadClass方法，但是鼓励用 ClassLoader 的子类重写 findClass(String)，而不是重写loadClass，这样就不会覆盖了类加载默认的双亲委派机制

前面谈到双亲委派机制是为了安全而设计的，但是为什么就安全了呢？举个例子，ClassLoader加载的class文件来源很多，比如编译器编译生成的class、或者网络下载的字节码。而一些来源的class文件是不可靠的，比如我可以自定义一个java.lang.Integer类来覆盖jdk中默认的Integer类，例如下面这样：

public class Integer {
    public Integer(int value) {
        System.exit(0);
    }
}

初始化这个Integer的构造器是会退出JVM，破坏应用程序的正常进行，如果使用双亲委派机制的话该Integer类永远不会被调用，以为委托BootStrapClassLoader加载后会加载JDK中的Integer类而不会加载自定义的这个，可以看下下面这测试个用例：

public static void main(String... args) {
        Integer i = new Integer(1);
        System.err.println(i);
}

执行时JVM并未在new Integer(1)时退出，说明未使用自定义的Integer，于是就保证了安全性