虚拟机类加载机制

前言：

​ 虚拟机并没有约束一定是本地文件才能进行加载，网络文件也是可以的，也没有约束必须是Java文件，一切遵守虚拟机解析规则的文件都能被加载，Java对应的就是Class字节码文件了。

​ 不同于其他语言，在编译时就需要进行连接，Java语言中，类型的加载，连接和初始化都是在程序运行期间完成的，这会带来一定的开销，但是会为Java提供高度的灵活性。比如编写一个面向接口的程序，可以在运行时再指定其实际的实现类。

虚拟机类加载机制

​ 类从被加载到虚拟机内存开始，到卸载处内存，它的整个生命周期包括：卸载、验证、准备、解析、初始化、使用、卸载7个阶段，其中验证、准备、解析称为连接。

​ 加载、验证、准备、初始化、卸载这5个步骤的顺序是确定的，解析阶段则不一定，某些时候可以在初始化之后，这是为了支持Java的运行时绑定（动态绑定）。

​ 什么时候进行加载，虚拟机规范中没有强制要求，但是初始化操作有严格的规定，5种情况下必须立刻执行（而加载、验证、准备自然要在此之前开始）：

• 遇到new、getstatic、putstatic、invokestatic这4个字节码指令时，没有初始化，必须初始化。这四条的场景分别是：new实例化一个对象、读取或者设置一个类的静态字段（被final修饰、在编译器把结果放入常量池的静态字段除外）、以及调用一个类的静态方法。
• 对类进行反射调用的时候
• 初始化子类的时候，如果其父类还没有初始化、则需要先初始化父类。
• 虚拟机启动时，要指定一个执行的主类（main方法的类），需要先初始化
• JDK7的动态语言支持时，java.lang.invoke.MethodHandle实例最后的解析结果是REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄时，对应的类没有初始化，需要初始化

​ 只有上述5种情况才会初始化，这些情况称为对一个类进行主动引用。除此外，所有引用类的方式都不会触发初始化，称为被动引用。

​ public static final String，执行这种类型的字段时，也不会触发初始化，虽然其看起来是getstatic，但是实际上在编译环节被优化了，通过常量传播(常量在编译阶段就会存入调用类的常量池中)，引用这个字段的类转化成了对常量池的引用，与这个字段的类没有任何关系了。

​ new 数组的时候也不会触发，即便数组的元素是要触发初始化的类。例如new MyClass[]；不会出发MyClass类的初始化，而触发了[L…MyClass类的初始化，[L…MyClass是一个由虚拟机自动生成、直接继承object的子类，创建动作由字节码指令newarray触发。这个类代表着一个元素为Myclass的一位数组，数组中的方法都定义在此类中。

类加载过程

​ 类加载的方式

​ 1.隐式加载， 程序在运行过程中当碰到通过new 等方式生成对象时，隐式调用类装载器加载对应的类到jvm中。

​ 2.显式加载， 通过class.forname()等方法，显式加载需要的类

1、加载：查找和导入Class文件

2、链接：其中解析步骤是可以选择的

​ （a）检查：检查载入的class文件数据的正确性

​ （b）准备：给类的静态变量分配存储空间

​ （c）解析：将符号引用转成直接引用

3、初始化：对静态变量，静态代码块执行初始化工作

加载

​ 加载阶段，虚拟机需要完成以下3件事情：

• 通过一个类的全限定名（类名）来获取定义此类的二进制字节流

• 将这个字节流代表的静态存储结构转化成方法区的运行时数据结构

• 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口

​ 相对于其他过程，一个非数组类的加载（准确说是获取类的二进制字节流的动作）是开发人员可控性最强的，因为加载阶段可以使用系统提供的引导类加载器来完成，也可以由用户自定义的类加载器来完成。

对数组类而言，情况就不一样了，数组类本身不通过类加载器创建，由虚拟机直接创建，但是又和类加载器有很大的关系。因为数据的元素类型最终要类加载器去创建。一个数组类的创建过程要遵循下面规则：

1.如果数组的类型是引用类型，就递归采用上面的加载过程加载这个组件类型，数组将在加载该组件类型的类加载器的类名称空间上被标识。（类必须和类加载器一同确定唯一性）

2.如果不是引用类型（int[]），会标记数组为引导类加载器关联

3.数组类的可见性与组件类型可见性一致，如果不是引用类型，就是public

加载完成之后，类就按照虚拟机的格式存储在方法区之中，在内存中实例化一个java.lang.Class类的对象。对于HotSpot而言，这个对象放在方法区中，而不是堆中。

加载过程和连接过程是交叉的，比如验证，连接阶段可能已经开始。

验证

​ 验证阶段的目的是为了确保class文件字节流中包含的信息是否符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

虚拟机规范对这个阶段的限制比较笼统，列举了一些Class文件格式中的静态和结构化约束，如果验证到输入的字节流不符合格式的约束，会抛出一个java.lang.VerifyError异常或其子类异常。到了Java虚拟机规范 SE 7版，才做了大量的验证阶段要求。总体分为四个阶段的验证：

1.文件格式验证：验证魔方数、版本号、常量池类型、指向常量的索引、utf8编码。主要目的就是保证输入的字节流能正确地解析并存储于方法区之内，格式上符合描述一个Java类型信息的要求。只有通过这个验证，才会到内存中的方法区进行存储，后续验证阶段就是基于方法区的内容，而不是二进制字节流了。

2.元数据验证：对字节码的信息进行语义分析，是否有父类，是否满足继承体系（单继承，不能继承final类），字段方法等是否与父类冲突。这个阶段目的就是对类的元数据进行语义校验，保证不存在不符合Java语言规范的元数据信息。

3.字节码验证：这个是最复杂的一个环节。主要目的是通过数据流和控制流分析，确定程序语义的合法性，保证类的方法在运行期间不会做出危害虚拟机的行为。例如：保证任何时候操作数栈的数据类型和指令代码序列配合工作，用long指令加载一个int类型之类的事情。保证跳转指令不会跳到方法体以外的字节码指令上。保证类型转换是有效的，子类赋给父类变量是安全的，不相干的就是危险的等等操作。这个阶段不能保证完全正确，可能会有问题。

4.符号引用验证：这个阶段的校验发生在虚拟机将符号引用转化为直接引用的时候，这个转化将在第三阶段解析中发生。符号引用验证是对类自身以外的信息进行匹配校验，主要校验：能否找到对应的引用类，是否存在相关方法属性字段，是否有权限访问（private)。如果无法通过验证，会抛出java.lang.IncompatibleClassChangeError异常的子类，如IllegalAccessError、NoSuchFieldError和NoSuchMethodError等。

验证阶段很重要，但是如果保证代码是正常的，可以关闭这个阶段缩短类加载时间，通过参数-Xverify:none来关闭。

准备

​ 准备阶段是为类的变量分配内存，并设置类变量初始值的阶段，这些变量使用的内存，都在方法区中进行分配。注意，只包含static类变量，实例变量是在堆中的，初始值一般是数据类型的零值，比如public static int value = 123。初始值是0，而不是123，这个时候没有执行任何Java方法，而把value赋值为123的putstatic指令是程序被编译后，存放在类构造器()方法中，所以在初始化阶段才会赋值成123。又要注意，一般是数据类型的零值，但是还有特殊情况，比如被final修饰，存在ConstantValue属性，会在准备阶段就会赋值，常量。

解析

​ 解析阶段就是将常量池中的符号引用替换成直接引用了。这里需要延伸一下知识，Java为了实现其动态性，在编译的时候都是通过符号引用来占位子，在这个阶段就要对应具体的引用对象了。

先来理解两个概念

• 符号引用：一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用的时候能无歧义的定位目标即可。与虚拟机实现的内存布局无关，引用的目标不一定已经加载到内存中（这个特性很有用），但是能接受的符号引用必须是一致的，因为这个字面量形式明确定义在Java虚拟机规范的Class文件格式中。

• 直接引用：直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用与内存布局相关，在不同虚拟机中符号引用会被翻译出不同的直接引用，如果有了直接引用，那么引用目标一定在内存中。

​ 虚拟机规范中没有规定解析的发生具体时间，所以是否是在加载时就完成符号引用的解析，还是到符号引用被使用时再进行解析

​ 这个根据实际需要决定。但是规范规定了16个操作符号引用的字节码之前，要完成解析动作，为：anewarray、checkcast、getfield、getstatic、instanceof、invokedynamic、invokeinterface、invokespecial、invokestatic、invokevirtual、ldc、ldc_w、multianewarray、new、putfield、putstatic。

对一个符号引用进行多次解析请求是很常见的，为了避免这个问题，虚拟机实现可以在第一个解析成功后，缓存结果，后续使用这个结果即可。但是如果第一次失败，后面都会失败。

类或接口的解析

​ 如果当前代码是在Test类中，将一个未解析过的符号引用N解析成一个类或接口C的直接引用，那么需要完成下面步骤：

1.如果C不是数组类型，虚拟机会将N的全限定名传递给Test的类加载器，去加载类C，可能触发其他的加载器，一旦出现任何异常则解析失败。

2.如果C是数组，N的描述符会是类似[Ljava/lang/Integer]形式，会按第一点的规则加载数组的元素类型，接着由虚拟机生成一个代表此数组维度和元素的数组对象。这里就是加载Integer类了。

3.上述步骤成功，在虚拟机中已经有一个有效的C类或接口了，但是还需要对符号引用进行验证，确定Test是否能够访问C，不能访问抛出IllegalAccessError

通俗的说就是Test类有个X tmp对象。类型X没有被解析，是一个符号引用，如果不是一个数组，就要用Test的类加载器加载这个类，如果是数组，也要加载，不过要额外开辟数组对象。

字段解析

​ 要解析一个未被解析过的字段符号引用，首先会对符号引用进行解析，也就是字段所属的类或接口的符号引用。如果在解析这个类或接口符号引用过程中出任何异常，都会导致字段符号引用解析失败。解析成功，需要进行下面操作，假设字段所属类或接口是C：

1.如果C本身包含了简单名称和字段描述符都与目标相匹配的字段，则直接返回这个字段的直接引用，查找结束。

2.如果不包含，C中实现了接口，从下往上递归搜索接口，如果包含简单名称和字段描述符与目标匹配，返回直接引用，查找结束

3.如果还没找到，会从下到上搜索继承体系，如果匹配返回直接引用，查找结束

4.否则，失败，抛出NoSuchFieldError异常。

成功后也会进行验证，判断有没有访问权限。

通俗的说就是：类Test打印了C.value这个字段，C中没有，先从下往上的接口中查找，仍没有，从下往上的继承找，还是没找到就抛出异常。

实际上编译器会更严格一些，如果一个字段同时出现在C的接口和父类中，或者同时在自己或父类的多个接口中出现，编译器可能拒绝编译。

类方法解析

​ 方法解析和字段解析第一步都一样，先对所属的类或接口的符号引用进行解析，成功后会对后续的类方法进行搜索：

1.类方法和接口方法的符号引用的常量类型定义是分开的，所以发现是个接口，直接抛出IncompatibleClassChangeError异常

2.查找是否有简单名称和描述符都匹配的方法，找到就结束

3.没找到，去父类查找，直到找到

4.没找到，去接口列表查找，找到了说明C是一个抽象类，抛出AbstractMethodError异常

5.否则抛出NoSuchMethodError

简单说就是Test中调用一个C.doSomething()方法，先找这个引用是不是一个接口，不是就要找这个方法是哪个父类的，没找到那就是接口的了，没有具体实现，要抛出异常，都没找到更错的离谱了。

接口方法解析

​ 接口方法也需要先解析出接口方法表的方法所属的类或接口的符号引用，解析成功，用C表示这个接口，进行下面的步骤：

1.如果C是个类，不是接口，抛出IncompatibleClassChangeError异常

2.是接口，查找C中是否有匹配的，有就查找结束

3.没找到，就在C的父接口递归查找，直到Object类，匹配就结束

4.找不到，抛出NoSuchMethodError异常

接口的方法默认是public，所以没有访问权限的问题。

简单说就是Test调用C.doSomething()，这是一个接口方法，如果C是类那么抛出异常，如果C中没有这个方法，找父接口，没找到也要抛出异常。

初始化

​ 初始化是类加载的最后一步，会真正执行类中定义的Java代码。准备阶段，变量赋予了零值，初始化阶段要赋予真正的值了。

初始化是执行类构造器()方法的过程，这个方法是由类变量的赋值动作，和静态语句块static{}语句合并产生的。由顺序决定，静态块只能访问到定义在静态块之前的变量，之后的变量可以赋值，不能访问。这个方法与构造函数()方法不同，不需要显示的调用父类构造器，虚拟机会保证执行子类的()方法之前，父类的已经执行完毕了。由于父类的先执行，所以父类的static会先执行。

此外方法不是必须的，如果没有赋值操作且没有静态代码块，就不会生成这个方法。接口虽然没有static块，但是会由赋值操作，与类不同的地方在于接口不需要先执行父类的()方法。只有在父接口的变量使用时，才会初始化父接口。另外接口的实现类在初始化的时候也不会执行接口的()方法。虚拟机会保证一个类的()方法在多线程环境被正确地加锁、同步，如果有多个线程同时初始化，只会执行一次。其他线程会阻塞，所以执行时间很久会导致多个线程阻塞。

类加载器

​ 之前说了虚拟机将加载二进制字节流的动作放在虚拟机外实现，让程序自己决定如何获取所需要的实现类。实现这个动作的代码模块称为”类加载器“。

​ 对于任何一个类都需要类本身和其加载器来确定唯一性，每个类加载器都有一个独立的类名称空间，比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则即使是同一个Class，被不同的类加载器加载，也是不同的类。这里的相等包括Class的equals方法、isAssignableFrom方法和isInstance方法。

双亲委派模型

​ java提供了三种系统类加载器：

1.启动类加载器（Bootstrap ClassLoader）：负责加载java_home\lib目录中，或者-Xbootclasspath参数所指定的路径，被虚拟机识别（固定名称）的类库加载到虚拟内存中。这个加载器无法被程序直接引用，用户在编写自定义加载器时，如果需要将加载请求委派给引导类加载器，直接使用null代替即可。getClassLoader方法返回null。

2.扩展类加载器（Extension ClassLoader)：这个加载器由sun.misc.Launcher$ExtClassLoader实现，负责加载java_home\lib\ext目录中的，或者被java.ext.dirs系统变量指定的路径所在类库，开发者可以直接使用扩展类加载器。

3.应用程序类加载器（Application ClassLoader）：这个类加载器由sun.misc.Launcher$AppClassLoader实现。这个类加载器是ClassLoader中的getSystemClassLoader方法的返回值，所以也称为系统类加载器。负责加载用户ClassPath上所指定的类库，可以直接使用，如果代码里面没有定义自己的加载器，就会默认使用这个。

上图所展现的这种层级关系被称为双亲委托模型，双亲委派模型中加载器除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这个关系不是通过继承来实现的，而是组合关系来复用父加载器的代码。

工作过程是：当收到类加载请求，首先不会自己加载这个类，而是把请求给父类加载，最终传递到最上层的启动类加载器中，只有当父加载器反馈自己无法加载时（没有在lib下找到这个类），子类加载器才会尝试加载。

这个模型的好处在于Java类有了一种优先级的层次关系。比如Object类，用双亲委派的一个好处是比如加载位于rt.jar包中的类java.lang.Object，不管是哪个加载器加载这个类，最终都是委托给顶层的启动类加载器进行加载，这样就保证了使用不同的类加载器最终得到的都是同样一个Object对象

​ 如果不使用这种委托模式，那我们就可以随时使用自定义的String来动态替代java核心api中定义类型，这样会存在非常大的安全隐患，而双亲委托的方式，就可以避免这种情况，因为String已经在启动时被加载，所以用户自定义类是无法加载一个自定义的ClassLoader。

思考：假如我们自己写了一个java.lang.String的类，我们是否可以替换调JDK本身的类？

答案是否定的。我们不能实现。为什么呢？我看很多网上解释是说双亲委托机制解决这个问题，其实不是非常的准确。因为双亲委托机制是可以打破的，你完全可以自己写一个classLoader来加载自己写的java.lang.String类，但是你会发现也不会加载成功，具体就是因为针对java.*开头的类，jvm的实现中已经保证了必须由bootstrp来加载。

实现很简单，都在ClassLoader的loadClass方法之中，先检查是否被加载过，若没有加载就调用父类加载器的loadClass方法，若父类加载器为空，默认使用启动类加载器，如果加载失败，抛出异常后调用自己的findClass()方法进行加载。

​ 1.可以避免重复加载，父类已经加载了，子类就不需要再次加载

​ 2.更加安全，很好的解决了各个类加载器的基础类的统一问题，如果不使用该种方式，那么用户可以随意定义类加载器来加载核心api，会带来相关隐患。

然后到了双亲委托模型的破坏案例，某些地方破坏了双亲委派模型，这部分下篇博客再细说吧。