类加载

验证 字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理 。这一阶段可能包括下面这些验证点:

• 是否以魔数 0xCAFEBABE 开头
• 主、次版本号 是否在当前虚拟机处理范围之内
• 常量池的常量中是否有不被支持的常量类型(检查常量tag标志)
• 指向 常量的各种索引值 中是否有指向不存在的常量或不符合类型的常量
• CONSTANT_Utf8_info型的常量中是否有不符合UTF8编码的数据
• Class文件中各个部分及文件本身是否有被删除的或附加的其他信息
• ……

实际上，第一阶段的验证点还远不止这些，上面这些只是从HotSpot虚拟机源码中摘抄的一小部分内容，该验证阶段的主要目的是保证输入的字节流能正确地解析并存储于方法区之内，格式上符合描述一个Java类型信息的要求。这阶段的验证是 基于二进制字节流 进行的，只有通过了这个阶段的验证后，字节流才会进入内存的方法区中进行存储，所以后面的3个验证阶段全部是 基于方法区的存储结构 进行的，不会再直接操作字节流

对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求 ，这个阶段可能包括的验证点如下:

• 这个类 是否有父类 (除了java.lang.Object之外，所有的类都应当有父类)
• 这个类的父类是否 继承了不允许被继承的类 (被final修饰的类)
• 如果这个类不是抽象类，是否 实现了其父类或接口之中要求实现的所有方法
• 类中的字段、方法是否与父类产生矛盾 (例如覆盖了父类的final字段，或者出现不符合规则的方法重载，例如方法参数都一致，但返回值类型却不同等)
• ……

第二阶段的主要目的是对类的元数据信息进行语义校验，保证不存在不符合Java语言规范的元数据信息

第三阶段是整个验证过程中最复杂的一个阶段，主要目的是 通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的 。在第二阶段对元数据信息中的数据类型做完校验后，这个阶段将对 类的方法体进行校验分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的事件 ，例如:

• 保证任意时刻 操作数栈的数据类型与指令代码序列都能配合工作 ，例如不会出现类似这样的情况:
  • 在操作栈放置了一个int类型的数据，使用时却按long类型来加载入本地变量表中
• 保证 跳转指令不会跳转到方法体以外的字节码指令上
• 保证方法体中的 类型转换是有效的
  • 可以把一个子类对象赋值给父类数据类型，这是安全的，但是把父类对象赋值给子类数据类型，甚至把对象赋值给与它毫无继承关系、完全不相干的一个数据类型，则是危险和不合法的
• ……

  如果一个类方法体的字节码没有通过字节码验证，那肯定是有问题的

  但如果一个方法体通过了字节码验证，也不能说明其一定就是安全的

  即使字节码验证之中进行了大量的检查，也不能保证这一点

  这里涉及了离散数学中一个很著名的问题“Halting Problem”

  通过程序去校验程序逻辑是无法做到绝对准确的，不能通过程序准确地检查出程序是否能在有限的时间之内结束运行

由于数据校验的高复杂性，虚拟机设计团队为了避免过多的时间消耗在字节码验证阶段，在JDK1.6之后的Javac编译器和Java虚拟机中进行了一项优化，给方法体的Code属性的属性表中增加了一项名为 StackMapTable 的属性，这项属性描述了方法体中所有的基本块(Basic Block，按照控制流拆分的代码块)开始时本地变量表和操作栈应有的状态，在字节码验证期间，就不需要根据程序推导这些状态的合法性，只需要检查StackMapTable属性中的记录是否合法即可。这样将字节码验证的类型推导转变为类型检查从而节省一些时间

  理论上StackMapTable属性也存在错误或被篡改的可能

  所以是否有可能在恶意篡改了Code属性的同时，也生成相应的StackMapTable属性来骗过虚拟机的类型校验则是虚拟机设计者值得思考的问题

在JDK1.6的HotSpot虚拟机中提供了 -XX:-UseSplitVerifier 选项来关闭这项优化，或者使用参数 -XX:+FailOverTo0ldVerifier 要求在类型校验失败的时候退回到旧的类型推导方式进行校验。而在JDK1.7之后，对于主版本号大于50的Class文件，使用类型检查来完成数据流分析校验则是唯一的选择，不允许再退回到类型推导的校验方式

最后一个阶段的校验发生在虚拟机将 符号引用转化为直接引用的时候 ，这个转化动作将在连接的第三阶段 解析 阶段中发生。符号引用验证可以看做是对 类自身以外(常量池中的各种符号引用)的信息进行匹配性校验 ，通常需要校验下列内容:

• 符号引用中通过 字符串描述的全限定名是否能找到对应的类
• 在指定类中是否 存在符合方法的字段描述符以及简单名称所描述的方法和字段
• 符号引用中的 类、字段、方法的访问性 (private、protected、public、default)是否可被当前类访问
• ……

符号引用验证的目的是确保解析动作能正常执行，如果无法通过符号引用验证，那么将会拋出一个 java.lang.IncompatibleClassChangeError 异常的子类

• java.lang.IllegalAccessError
• java.lang.NoSuchFieldError
• java.lang.NoSuchMethodError

对于虚拟机的类加载机制来说，验证阶段是一个非常重要的、但不是一定必要(因为对程序运行期没有影响)的阶段。如果所运行的全部代码(包括自己编写的及第三方包中的代码)都已经被反复使用和验证过，那么在实施阶段就可以考虑使用 -Xverify:none 参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间

假设当前代码所处的类为 D ，如果要把一个从未解析过的符号引用 N 解析为一个类或接口 C 的直接引用，那虚拟机完成整个解析的过程需要以下3个步骤:

1. 如果 C 不是一个数组 类型，那虚拟机将会把代表N的 全限定名 传递给 D的类加载器 去加载这个类C
   • 在加载过程中，由于 元数据验证 、 字节码验证 的需要，又可能触发其他相关类的加载动作，例如加载这个类的父类或实现的接口
   • 一旦这个加载过程出现了任何异常，解析过程就宣告失败
2. 如果C是一个 数组 类型，并且数组的 元素类型为对象 ，也就是N的描述符会是类似 [Ljava/lang/Integer 的形式
   • 按照第1点的规则加载数组元素类型。如果N的描述符如前面所假设的形式，需要加载的元素类型就是 java.lang.Integer
   • 虚拟机生成一个代表此数组维度和元素的数组对象
3. 如果上面的步骤没有出现任何异常，那么C在虚拟机中实际上已经成为一个有效的类或接口了，但在解析完成之前还要进行符号引用验证，确认 D是否具备对C的访问权限
   • 如果发现不具备访问权限，将拋出 java.lang.IllegalAccessError 异常

要解析一个未被解析过的字段符号引用，首先将会对 字段表内class_index 项中索引的 CONSTANT_Class_info 符号引用进行解析，也就是 字段所属的类或接口的符号引用

• 如果在解析这个类或接口符号引用的过程中出现了任何异常，都会导致字段符号引用解析的失败
• 如果解析成功完成，那将这个字段所属的类或接口用C表示，虚拟机规范要求按照如下步骤对C进行后续字段的搜索:
  1. 如果 C本身就包含了简单名称和字段描述符都与目标相匹配的字段 ，则返回这个字段的直接引用，查找结束
  2. 如果在C中实现了接口，将会按照 继承关系从下往上递归搜索各个接口和它的父接口 ，如果 接口中包含了简单名称和字段描述符都与目标相匹配的字段 ，则返回这个字段的直接引用，查找结束
  3. 如果C不是 java.lang.Object 的话，将会按照 继承关系从下往上递归搜索其父类 ，如果在 父类中包含了简单名称和字段描述符都与目标相匹配的字段 ，则返回这个字段的直接引用，查找结束
  4. 查找失败，拋出 java.lang.NoSuchFieldError 异常。
• 如果查找过程成功返回了引用，将会对这个 字段进行权限验证 ，如果发现不具备对字段的访问权限，将拋出 java.lang.IllegalAccessError 异常。

在实际应用中，虚拟机的编译器实现可能会比上述规范要求得更加严格一些，如果有一个同名字段同时出现在C的接口和父类中，或者同时在自己或父类的多个接口中出现，那编译器将可能拒绝编译

package org.fenixsoft.classloading;

public class FieldResolution {
        interface Interface0 {
                int A = 0;
        }

        interface Interface1 extends Interface0 {
                int A = 1;
        }

        interface Interface2 {
                int A = 2;
        }

        static class Parent implements Interface1 {
                public static int A = 3;
        }

        static class Sub extends Parent implements Interface2 {
                //public static int A = 4;
        }

        public static void main(String[] args) {
                System.out.println(Sub.A);
        }
}

FieldResolution.java:23: error: reference to A is ambiguous
              System.out.println(Sub.A);		                      ^
both variable A in Parent and variable A in Interface2 match
1 error

注释了Sub类中的 public static int A =4; ，接口与父类同时存在字段A，那编译器将提示 The field Sub.A is ambiguous ，并且拒绝编译这段代码

类方法解析的第一个步骤与字段解析一样

• 先解析出 类方法表的class_index 项中索引的方法 所属的类或接口的符号引用 。如果解析成功，依然用C表示这个类，接下来虚拟机将会按照如下步骤进行后续的类方法搜索
  1. 类方法和接口方法符号引用的常量类型定义是分开的，如果在 类方法表中发现class_index中索引的C是个接口 ，那就直接拋出 java.lang.IncompatibleClassChangeError 异常
  2. 如果通过了第1步，在类C中查找是否 有简单名称和描述符都与目标相匹配的方法 ，如果有则返回这个方法的直接引用，查找结束
  3. 在类C的 父类中递归查找是否有简单名称和描述符都与目标相匹配的方法 ，如果有则返回这个方法的直接引用，查找结束
  4. 在类C实现的 接口列表及它们的父接口之中递归查找是否有简单名称和描述符都与目标相匹配的方法 ，如果存在匹配的方法，说明类C是一个 抽象类 ，这时查找结束，拋出 Java.lang.AbstractMethodError 异常
  5. 宣告方法查找失败，拋出 java.lang.NoSuchMethodError
• 如果查找过程成功返回了直接引用，将会对这个方法进行 权限验证 ，如果发现不具备对此方法的访问权限，将拋出 java.lang.IllegalAccessError 异常

接口方法也需要

• 先解析出 接口方法表的class_index 项中索引的方法所属的 类或接口的符号引用 ，如果解析成功，依然用C表示这个接口，接下来虚拟机将会按照如下步骤进行后续的接口方法搜索
  1. 与类方法解析不同，如果在接口方法表中发现class_index中的索引 C是个类而不是接口 ，那就直接拋出 java.lang.IncompatibleClassChangeError 异常
  2. 在接口 C中查找是否有简单名称和描述符都与目标相匹配的方法 ，如果有则返回这个方法的直接引用，查找结束
  3. 在接口C的 父接口中递归查找 ，直到 java.lang.Object 类(查找范围会包括Object类)为止，看是否有 简单名称和描述符都与目标相匹配的方法 ，如果有则返回这个方法的直接引用，查找结束
  4. 宣告方法查找失败，拋出 java.lang.NoSuchMethodError 异常

由于接口中的所有方法默认都是public的，所以 不存在访问权限 的问题，因此接口方法的符号解析应当不会拋出java.langIllegalAccessError异常

Bootstrap ClassLoader 这个类将器负责将存放在 <JAVA_HOME>\lib 目录中的，或者被 -Xbootclasspath 参数所指定的路径中的，并且是虚拟机识别的(仅按照文件名识别，如rt.jar，名字不符合的类库即使放在lib目录中也不会被加载)类库加载到虚拟机内存中

启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要 把加载请求委派给引导类加载器，那直接使用 null 代替 即可

/**
   Returns the class loader for the class. Some implementations will use null
   to represent the bootstrap class loader. The method will return null in such
   implemenatation if this class was loaded by the bootstrap class loader. 
**/
public classLoader getClassLoader(){
    ClassLoader cl = getClassLoader0();
    if(cl==null)
        return null;
    SecurityManager sm = System.GetSecurityManager();
    if(sm != null){
        ClassLoader ccl = ClassLoader.getCallerClassLoader();
        if(ccl != null && ccl != cl && cl.isAncestor(ccl)){
            sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION);
        }
    }
    return cl;
}

Extension ClassLoader 这个加载器由 sun.misc.Launcher$ExtClassLoader 实现，它负责加载 <JAVE_HOME>\lib\ext 对目录中的，或者被 java.ext.dirs 系统变量所指定的路径中的所有类库,开发者可以直接使用扩展类加载器

Application ClassLoader 类加载器由 sun.misc.Launcher$AppClassLoader 实现。由于这个类加载器是 ClassLoader 中的 getSystemClassLoader() 方法的返回值，所以一般也称它为 系统类加载器 。它负责加载用户类路径 ClassPath 上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器

应用程序都是由以上这3种类加载器互相配合进行加载的，如果有必要，还可以加入自己定义的类加载器。这些类加载器之间的关系一般如图所示：

类加载器之间的这种层次关系，称为类加载器的 双亲委派模型 ( Parents Delegation Model )。双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不会以 继承 的关系来实现，而是都使用 组合 关系来复用父加载器的代码

    类加载器的双亲委派模型在JDK1.2期间被引入并被广泛应用于之后几乎所有的Java程序中
    
    但它并不是一个强制性的约束模型，而是Java设计者推荐给开发者的一种类加载器实现方式

双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求

• 不会自己去尝试加载这个类，而是把这个请求委派给父加载器去完成
  • 每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中
• 只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载

好处就是 Java类随着它的类加载器一起具备了一种带有优先级的层次关系 。例如类 java.lang.Object ，它存放在 rt.jar 之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为java.lang.Object的类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object类，Java类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱

  如果有兴趣的话，可以尝试去编写一个与rt.jar类库中已有类重名的Java类，将会发现可以正常编译，但永远无法被加载运行

双亲委派模型对于保证Java程序的稳定运作很重要，但它的实现却非常简单，实现双亲委派的代码都集中在 java.lang.ClassLoader 的 loadClass() 方法之中，如下面代码所示:

protected synchronized Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException {
    // First, check if the class has already been loaded
    Class<?> c = findLoadedClass(name);

    if (c == null) {
        try {
            if (parent != null) {
                c = parent.loadClass(name, false);
            } else {
                c = findBootstrapClassOrNull(name);
            }
        } catch (ClassNotFoundException e) {
            // ClassNotFoundException thrown if class not found
            // from the non-null parent class loader
        }

        if (c == null) {
            // If still not found, then invoke findClass in order
            // to find the class.
            c = findClass(name);
        }


    }

    if (resolve) {
        resolveClass(c);
    }

    return c;

                }

1. 先检查是否已经被加载过
2. 若没有加载则调用父加载器的 loadClass() 方法
3. 若父加载器为空则默认使用启动类加载器作为父加载器
4. 如果父类加载失败，拋出 ClassNotFoundException 异常后
5. 调用自己的 findClass() 方法进行加载

  这里只限于Hot Spot，像MRP、Maxife等虚拟机，整个虚拟机本身都是由Java编写的，自然BootstrapClassLoader也是由Java语言而不是C++实现的

  除了Hot Spot以外的其他两个高能虚拟机JRockit和J9都有一个代表Bootstrap ClassLoader的Java类存在

  但是关键方法的实现仍然是使用JNI回调到C(注意不是C++)的实现上，这个Bootstrap ClassLoader的实例也无法被用户获取到

即使自定义了自己的类加载器，强行用 defineClass() 方法去加载以 java.lang 开头的类也不会成功。如果尝试这样做的话，将会收到一个由虚拟机自己拋出的 java.lang.SecurityException: Prohibited package name: java.lang 异常

双亲委派模型并不是一个 强制性的约束模型 ，而是Java设计者推荐给开发者的类加载器实现方式。在Java的世界中大部分的类加载器都遵循这个模型，但也有例外，到目前为止，双亲委派模型主要出现过3较大规模的 被破坏 情况：

第一次发生在双亲委派模型出现之前，即JDK1.2发布之前。由于双亲委派模型在JDK1.2之后才被引入，而类加载器和抽象类 java.lang.ClassLoader 则在JDK1.0时代就已经存在，面对已经存在的用户自定义类加载器的实现代码，Java设计者引入双亲委派模型时不得不做出一些妥协。为了向前兼容，JDK1.2之后的 java.lang.ClassLoader 添加了一个新的 protected 方法 findClass() （用户自定义加载类逻辑），在此之前，用户去继承java.lang.ClassLoader的唯一目的就是为了重写loadClass()方法（实现双亲委派模型），因为虚拟机在进行类加载的时候会调用加载器的私有方法 loadClassInternal() 这个方法的唯一逻辑就是去调用自己的 loadClass()

JDK1.2之后已不提倡用户再去覆盖loadClass()方法，而应当把自己的类加载逻辑写到findClass()方法中

在loadClass()方法的逻辑里如果父类加载失败，则会调用自己的findClass()方法来完成加载，这样就可以保证新写出来的类加载器是符合双亲委派规则的

第二次是由这个模型自身的缺陷所导致的，双亲委派很好地解决了各个类加载器的基础类的统一问题(越基础的类由越上层的加载器进行加载)，基础类之所以称为 基础 ，是因为它们总是作为被用户代码调用的API，但世事往往没有绝对的完美，如果基础类又要调用回用户的代码，那该怎么办?

这并非是不可能的事情，一个典型的例子便是 JNDI 服务，JNDI现在已经是Java的标准服务，它的代码由启动类加载器去加载(在JDK1.3时放进去的rt.jar)，但JNDI的目的就是对资源进行集中管理和查找，它需要调用由独立厂商实现并部署在应用程序的ClassPath下的JNDI接口提供者( SH，ServiceProviderInterface )的代码，但启动类加载器不可能 认识 这些代码

为了解决这个问题，Java设计团队只好引入了一个不太优雅的设计: 线程上下文类加载器 ( ThreadContext ClassLoader )。这个类加载器可以通过 java.lang.Thread 类的 setContextClassLoaser() 方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器

JNDI服务使用这个线程上下文类加载器去加载所需要的SPI代码，也就是父类加载器请求子类加载器去完成类加载的动作

这种行为实际上就是打通了双亲委派模型的层次结构来逆向使用类加载器，实际上已经违背了双亲委派模型的一般性原则，但这也是无可奈何的事情

Java中所有涉及SPI的加载动作基本上都采用这种方式，例如 JNDI 、 JDBC 、 JCE 、 JAXB 和 JBI 等

第三次是由于用户对程序 动态性 的追求而导致的: 代码热替换 (Hot Swap)、 模块热部署 (Hot Deployment)等。对于一些生产系统来说，关机重启一次可能就要被列为生产事故，这种情况下热部署就对软件开发者，尤其是企业级软件开发者具有很大的吸引力

Sun公司所提出的JSR-294、JSR-277规范在与JCP组织的模块化规范之争中落败给JSR-291(即OSGi R4.2)

虽然Sun不甘失去Java模块化的主导权,独立在发展Jigsaw项目,但目前OSGi已经成为了业界“事实上”的Java模块化标准

而OSGi实现模块化热部署的关键则是它自定义的类加载器机制的实现

每一个程序模块(OSGi中称为Bundle)都有一个自己的类加载器,当需要更换一个Bundle时,就把Bundle连同类加载器一起换掉以实现代码的热替换

在OSGi环境下，类加载器不再是双亲委派模型中的 树状 结构，而是进一步发展为更加复杂的 网状 结构，当收到类加载请求时，OSGi将按照下面的顺序进行类搜索:

1. 将以java.*开头的类委派给父类加载器加载
2. 将委派列表名单内的类委派给父类加载器加载
3. 将Import列表中的类委派给Export这个类的Bundle的类加载器加载
4. 查找当前Bundle的ClassPath，使用自己的类加载器加载
5. 查找类是否在自己的FragmentBundle中，如果在，则委派给FragmentBundle的类加载器加载
6. 查找DynamicImport列表的Bundle，委派给对应Bundle的类加载器加载
7. 类查找失败

查找顺序中只有开头两点仍然符合双亲委派规则，其余的类查找都是在平级的类加载器中进行的

  “被破坏”这个词来形容上述不符合双亲委派模型原则的行为，但这里“被破坏”并不带有贬义的感情色彩

  只要有足够意义和理由，突破已有的原则就可认为是一种创新

  正如OSGi中的类加载器并不符合传统的双亲委派的类加载器，并且业界对其为了实现热部署而带来的额外的高复杂度还存在不少争议

  但在Java程序员中基本有一个共识:OSGi中对类加载器的使用是很值得学习的，弄懂了OSGi的实现，就可以算是掌握了类加载器的精髓

Next：执行引擎

Previous：类文件结构

Home：目录