java 中类加载过程

一， 虚拟机的类加载过程

    类加载：虚拟机把描述类的数据从 .class文件加载到内存，并对数据进行校验，转换解析和初始化，最终造成能够被直接使用的java类型，这就是虚拟机的类加载机制。

    类的生命周期包括： 

        加载（Loading）、

        验证（Verification）、准备（Preparation）、解析（Resolution）、

        初始化（Initialization）、使用（Using）、卸载（Unloading）等七个阶段，

    其中验证、准备和解析三个部分统称为连接（Linking）。而类的加载指的就是从 加载 到 初始化 这五个阶段。

    这七个阶段的顺序除了解析阶段和使用阶段外，其它几个阶段的开始顺序是肯定的，必须按这种顺序循序渐进的开始，但不要求按这种顺序循序渐进的完成，这些阶段一般是互相交叉地混合式进行的，一般会在一个阶段执行的过程当中调用或激活另一个阶段。解析阶段在某些状况下能够在初始化阶段以后再开始，以支持java的运行时绑定（RTTI），而使用阶段则是按类文件内容的定义的不一样而在不一样的阶段进行。

    虚拟机规范对于什么时候进行加载这一阶段并无强制约束，但对于初始化阶段，虚拟机规范是严格规定了有且只有四种状况必须当即对类进行初始化：

    a、遇到new,getstatic,putstatic或invokestatic这4条字节码指令时，若是类没有进行过初始化，则须要先触发其初始化。生成这4条指定的场景是：使用new关键字实例化对象，读取或设置一个类的静态字段以及调用一个类的静态方法的时候。固然，被final修饰并在编译期就把结果放入常量池的静态字段不属于这些场景，这类静态字段的值在编译期时就会被编译器优化而直接放入常量池，其引用直接指向其在常量池的入口。

    b、使用java.lang.reflect包的方法对类进行反射调用时，若是类没有进行过初始化，则须要先触发其初始化。

    c、当初始化一个类的时候，若是发现其父类尚未进行过初始化，则须要先触发其父类的初始化。

    d、当虚拟机启动时，用户须要指定一个要执行的主类（包含main（）方法的类），虚拟机会先初始化这个主类。

    以上四种场景中的行为称为对一个类进行主动引用，除此以外全部引用类的方式都不会触发初始化，称为被动引用。

    接口的加载过程与类加载过程最主要的区别在于第三点，即当初始化一个接口时，并不须要先初始化其父接口，而是只有真正使用到父接口中的字段的时候才会初始化。

        如下对类加载的各个阶段进行简单的说明。

            加载阶段，虚拟机须要完成三件事：经过一个类的全限定名来获取定义此类的二进制字节流，将这个字节流所表明的静态存储结构转化为方法区的运行时数据结构，在java堆中生成一个表明这个类的java.lang.Class对象，做为方法区这些数据的访问入口。

            验证阶段，不一样虚拟机会进行不一样类验证的实现，但大体都会完成如下四个阶段的检验过程：文件格式验证（验证字节流是否符合Class文件格式的规范，并能被当前版本的虚拟机处理），元数据验证（对字节码描述信息进行语义分析，保证其描述信息符合java语言规范），字节码验证（对类方法体进行数据流和控制流分析，保证类的方法在运行时不会作出危害虚拟机的行为）和符号引用验证（发生在将符号引用转化为直接引用的时候，在解析阶段中发生）。

            准备阶段，正式为类成员变量（注意，不是实例成员变量，实例变量会在对象实例化时随着对象一块儿分配在java堆上）分配内存并设置类变量初始值（一般状况下是数据类型的零值，不进行赋值操做）的阶段，这些内存都将在方法区中进行分配。

            例：public static int value=123;则在准备阶段事后，value的初始值为0而不是123，赋值指令是在初始化阶段经过构造方法来执行的。

            解析阶段，虚拟机将常量池内的符号引用替换为直接引用的过程。符号引用与内存布局无关，而直接引用的目标一定已经在内存中存在。解析动做主要针对类或接口、字段、类方法、接口方法四类符号引用进行。

            初始化阶段，真正开始执行类中定义的java程序代码（字节码），是执行类构造器<clinit>()方法的过程。

            <clinit>()方法的一些特色：

            <clinit>()方法是由编译器自动收集类中的全部类变量的赋值动做和静态语句块（static｛｝）中的语句合并产生的，编译器收集顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块以前的变量。

            <clinit>()方法与类的构造函数（或者说实例构造器<init>()方法）不一样，它不须要显式地调用父类构造器，虚拟机会在子类的<clinit>()方法执行以前完成父类<clinit>()方法的执行。

            因为父类的<clinit>() 方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操做

            <clinit>()方法对于类或接口来讲并非必须的，若是一个类中没有静态语句块，也没有对变量的赋值操做，则编译器能够不为这个类生成<clinit>()方法。

            接口中不能使用静态语句块，但仍然有变量初始化的赋值操做，所以接口与类同样都会生成<clinit>()方法，不一样于类的地方是执行接口的<clinit>()方法时不坱要先执行父类的<clinit>()方法。

            虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁和同步，若是多个线程同时去初始化一个类，则只有一个线程去执行这个类的<clinit>()方法，其它线程阻塞等待，直到活动线程执行<clinit>()方法完毕。

         

二，默认的类加载机制

    类的加载是经过ClassLoader实现的， jvm提供了三种ClassLoader的实现， 分别是：

        1，BootStrap ClassLoader：称为启动类加载器，它集成在jvm中，是Java类加载层次中最顶层的类加载器，负责加载JDK中的核心类库（JAVA_HOME/jre/lib下的jar 以及 lib/classes下的类或jar等），如：rt.jar、resources.jar、charsets.jar等，能够经过 系统属性 sun.boot.class.path 获得核心类库的所有类路径 : System.out.println(System.getProperty("sun.boot.class.path")); 

    另外，Bootstrap ClassLoader还负责构造Extension ClassLoader和App ClassLoader类加载器。

        2，Extension ClassLoader：称为扩展类加载器，负责加载Java的扩展类库，默认加载JAVA_HOME/jre/lib/ext/目下的全部jar。

        3，App ClassLoader：称为系统类加载器，负责加载应用程序classpath目录下的全部jar和class文件。

    加载机制： 双亲委托模型（此处省略若干字..）, 注意，判断两个类是否相同，不单要看类名，还要看是不是由同一个类加载其加载的

三， 定制的ClassLoader

    Java环境已经提供了三种默认的ClassLoader，可是它们只能加载指定目录下的jar和class，若是由于某些缘由咱们想把一些类动态资源根据须要来决策什么时候加载的话，咱们就必须定制本身的类加载器，实现一些定制的加载策略。

定制一个ClassLoader须要两步：

一、继承java.lang.ClassLoader

二、重写父类的findClass方法

      JDK已经在loadClass方法中帮咱们实现了ClassLoader搜索类的算法，当在loadClass方法中搜索不到类时，loadClass方法就会调用findClass方法来搜索类，因此咱们只需重写该方法便可。如没有特殊的要求，通常不建议重写loadClass搜索类的算法。从loadClass的实现能够看到双亲委托模型的过程，首先在已经加载的类中查找（查看是否已加载），若不然交给parent 进行加载，若是parent不能加载，才调用本身的findClass进行加载， 因此为了遵照双亲委托模型，定制的classloader只须要重写findClass 方法便可。 （android中的字节码是通过格式优化的，不须要连接）

ClassLoader.java:
/**
     * Loads the class with the specified name, optionally linking it after
     * loading. The following steps are performed:
     * <ol>
     * <li> Call {@link #findLoadedClass(String)} to determine if the requested
     * class has already been loaded.</li>
     * <li>If the class has not yet been loaded: Invoke this method on the
     * parent class loader.</li>
     * <li>If the class has still not been loaded: Call
     * {@link #findClass(String)} to find the class.</li>
     * </ol>
     * <p>
     * <strong>Note:</strong> In the Android reference implementation, the
     * {@code resolve} parameter is ignored; classes are never linked.
     * </p>
     *
     * @return the {@code Class} object.
     * @param className
     *            the name of the class to look for.
     * @param resolve
     *            Indicates if the class should be resolved after loading. This
     *            parameter is ignored on the Android reference implementation;
     *            classes are not resolved.
     * @throws ClassNotFoundException
     *             if the class can not be found.
     */
    protected Class<?> loadClass(String className, boolean resolve) throws ClassNotFoundException {
        Class<?> clazz = findLoadedClass(className);

        if (clazz == null) {
            try {
                clazz = parent.loadClass(className, false);
            } catch (ClassNotFoundException e) {
                // Don't want to see this.
            }

            if (clazz == null) {
                clazz = findClass(className);
            }
        }

        return clazz;
    }

参考：

http://my.oschina.net/u/1269532/blog/166888

http://blog.csdn.net/xyang81/article/details/7292380