类加载机制
Last updated
Last updated
什么是类加载 虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。
讲的是Class文件结构，即我们编写的Java代码（.java文件）经过编译后生成Class文件（.class文件）。这一章讲述的是如何将这个Class文件加载到内存并最终形成虚拟机直接使用Java类型的过程。
类的生命周期
其中，加载、验证、准备、初始化和卸载这5个顺序是固定的，即类的加载过程按这个顺序开始（但并不是按照这个顺序进行或完成，而是各个阶段交叉进行）。 解析阶段在某些情况下会在初始化之后再开始：为了支持Java的运行时绑定（动态绑定或晚期绑定）。
概念补充：动态绑定 绑定指的是一个方法的调用与方法所在的类(方法主体)关联起来。对Java来说，绑定分为静态绑定和动态绑定。 静态绑定是指在编译过程中就已经知道这个方法到底是哪个类中的方法，Java当中的方法只有final，static，private和构造方法是静态绑定。动态绑定是指在程序方法运行时根据具体对象的类型进行绑定。Java虚拟机可在运行期间判断对象的类型，并调用适当的方法。
加载时机
虚拟机规范并没有强制约束何时开始第一阶段的加载，但规定了有且仅有5种情况必须立即对类进行初始化（而加载、验证、准备自然需要在此之前完成）。这5种情况如下：
遇到new、getstatic、putstatic、invokestatic这4条字节码指令时，并且该类此前没有进行过初始化。生成这4条指令的常见Java代码场景是：使用new关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候、调用一个类的静态方法的时候。
使用java.lang.reflect包中的方法对类进行反射调用的时候，如果类没有被初始化过，则需要先触发初始化。
当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发父类的初始化。
当虚拟机启动时，用户需要指定一个要执行的主类（包含main方法的那个类），虚拟机会先初始化这个主类。
当使用JDK1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果是REF_getStatic、REF_putStatic、REF_invokeStatic方法句柄，并且这个方法句柄对应的类没有进行过初始化，则需要先触发其初始化。
这5种场景中的行为称为对一个类的主动引用，除此之外都不会触发类的初始化，被称为被动引用。被动引用的情况有以下几种：①通过子类引用父类的静态字段，不会导致子类初始化，只会导致父类的初始化；②通过数组定义来引用类，不会触发类的初始化（但会触发数组初始化）；③常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。
接口初始化的类的初始化的区别：类在初始化时，要求其父类已经初始化，但一个接口在初始化时，并不要求其父接口全部都完成初始化，只有在真正使用的父接口的时候才会初始化。
在加载阶段，虚拟机需要完成3件事情：
获取该类的二进制字节流
根据此类的全限定名获取，二进制流来源主要有Class文件、ZIP包、网络、运行时计算生成、其他文件生成如JSP、数据库）
将二进制字节流存储在方法区（按照一定的格式存储）。
在内存中生成一个java.lang.Class对象
该Class对象将作为方法区这个类的各种数据的访问入口，在hotSpot虚拟机中该对象是存放在方法区的。
验证的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。验证阶段大致会完成下面4个阶段的检验动作：
文件格式校验
该阶段的验证是基于二进制字节流进行的，只有通过了这一阶段，字节流才会进入内存的方法区中进行存储，后面的验证阶段都是基于方法区的存储结构进行的，不会再直接操作二进制流。主要包括：是否以魔数0xCAFEBABE开头、主次版本号是否在当前虚拟机处理范围之内等等。
元数据校验
目的是保证不存在不符合Java语言规范的元数据信息，主要包括：这个类是否有父类、是否继承了不允许被继承的类（final修饰的类）、是否实现了父类或接口中要求实现的所有方法、字段与方法是否与父类矛盾等。
字节码验证 目的是通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的，即对类的方法体进行校验分析。
符号引用验证 对类自身以外的信息进行匹配性校验，发生在虚拟机将符号引用转化为直接引用的时候（解析阶段）。包括：①符号引用中通过字符串描述的全限定名是否能找到对应的类；②在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段；③符号引用中的类、方法、字段的访问性是否可被当前类访问到。
验证阶段是非常重要但不是一定必要的阶段，如果所运行的代码（自己编写的以及第三方包中的代码）已经被反复使用和验证过，可以考虑使用-Xverify:none来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。
准备阶段的工作是：为类变量分配内存并设置类变量初始值。这些变量所使用的内存都将在方法区进行分配。要注意的是：①类变量是指被static修饰的变量，不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中；②初始值在通常情况下是指数据类型的零值，但如果是static final类型变量，则会直接为该变量赋值为代码中指定的值。
解析阶段的工作：虚拟机将常量池内的符号引用替换为直接引用的过程。解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符。 符号引用：以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标接口。 直接引用：直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。
类或接口的解析 假设当前代码所在的类为D，要将符号引用N解析为一个类或接口C的直接引用，整个过程分为三个过程： ①如果C不是一个数组类型，则虚拟机将代表N的全限定名传给D的类加载器去加载这个类。在加载过程中，又可能会去加载这个类的父类等。 ②如果C是数组类型，并且数组的元素类型为对象，则先按照①加载这个数组元素类型，接着虚拟机生成一个代表此数组维度和元素的数组对象。 ③上述步骤均未出现异常，则C在虚拟机中实际上已经成为一个有效的类或接口了。但还要进行访问权限检查。
字段解析 字段符号引用的解析，会先对字段所属的类或接口的符号引用进行解析，假设解析正常，将这个字段所属的类或接口用C表示，之后虚拟机按以下顺序对C进行后续字段的搜索：C本身、C实现的各个接口或父接口（递归）、C继承的父类（递归）。 如果一个同名字段同时出现在C的接口和父类中，或同时在自己和父类的多个接口中，那么编译器将拒绝编译。
类方法解析
接口方法解析
初始化：真正开始执行类中定义的Java代码（或者说字节码）。
在准备阶段，变量已经赋过一次系统要求的初始值，而在初始化阶段，则根据程序员通过程序指定的主观计划去初始化类变量和其他资源：即初始化阶段是执行类构造器<clinit>方法的过程。（<clinit>可以看做class init的简写）
关于<clinit>方法：
①<clinit>方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并而来，收集顺序是由语句在源文件中出现的顺序决定的。注意：静态语句块中只能访问到定义在静态语句块之前的变量，对定义在它之后的变量，可以赋值，但不能访问，如下：
②<clinit>方法与类的构造器（实例构造器<init>）不同，它不需要显式调用父类构造器，虚拟机会保证在子类的<clinit>方法执行之前，父类的<clinit>方法已经执行完毕。因此在虚拟机中第一个被执行的<clinit>方法的类肯定是java.lang.object。
③由于父类的<clinit>方法先执行，所以父类中定义的静态语句块要优先于子类的变量赋值操作而执行。
④<clinit>方法并不是类或接口必须的，如果一个类中没有静态语句块，也没有对类变量的赋值操作，那么编译器可不为这个类生成<clinit>方法。
⑤接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成<clinit>方法。不同的是，执行接口的<clinit>方法不需要执行父类的<clinit>方法，只有当父接口中定义的变量使用时，父接口才会初始化。另外，接口的实现类在初始化时也不会执行接口的<clinit>方法。
⑥虚拟机会保证一个类的<clinit>方法在多线程环境中被正确地加锁、同步。如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>方法完毕（同一个类加载器下，一个类型只会初始化一次）。如果在一个类的<clinit>方法中有很耗时的操作，就可能导致多个进程阻塞。
类加载器的作用：通过一个类的全限定名来获取描述此类的二进制字节流。这个动作是在Java虚拟机外部实现的，以便让应用程序自己决定如何去获取所需要的类。类加载器在类层次划分、OSGi、热部署、代码加密等领域大放异彩。
对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性：比较两个类是否“相等”，只有在这两个类是由同一个类加载器的前提下才有意义，否则即使这两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。
这里所指的相等，包括代表类的Class类的对象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回结果，也包括使用instanceof关键字做对象所属关系判定等情况。
从Java虚拟机的角度来讲，只存在2种不同的类加载器：
①启动类加载器：Bootstrap ClassLoader，虚拟机自身的一部分。
②其他类加载器：独立于虚拟机外部，并且全部继承自抽象类java.lang.ClassLoaer。
从Java开发人员的角度看，类加载器可以划分的更详细，分为4种：
启动类加载器Bootstrap ClassLoader
负责将存放在<JAVA_HOME>\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的类库加载到虚拟机内存中。开发者不能直接引用启动类加载器，如果需要将加载请求委派给启动类加载器，直接使用null代替即可。由于引导类加载器涉及到虚拟机本地实现细节，开发者无法直接获取到启动类加载器的引用，所以不允许直接通过引用进行操作
开发中用到的jdk的类绝大部分包都在rt.jar中，<JAVA_HOME>下的src.zip是rt.jar的源码。
扩展类加载器Extention ClassLoader 负责加载<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量指定的路径中的所有类库，开发者可以直接使用扩展类加载器。由 Sun 的ExtClassLoader（sun.misc.Launcher$ExtClassLoader）实现。
应用程序类加载器AppClassLoader
自定义类加载器
应用程序均是由这4种类加载器互相配合进行加载的，他们之间的关系如下图：
类加载器这种层次关系称为类加载器的双亲委派模型：除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里的类加载器之间的父子关系一般不会以继承的关系实现，而是都使用组合关系来复用父加载器的代码。
双亲委派模型的工作过程：如果一个类收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求交给父类加载器去完成，每一层次的类加载器都是如此。因此所有的加载请求都是从顶层的启动类加载器开始，只有当父加载器反馈自己无法完成这个加载请求，子类才会尝试自己去加载。
使用双亲委派模型的好处：Java类随着它的类加载器一起具备了一种带有优先级的层次关系，比如保证不会出现两个java.lang.Obejct类，从而保证Java类型体系中最基础的行为，保证了Java程序的稳定运作。
双亲委派模型的实现代码（java.lang.ClassLoader的loadClass()方法）：
第一次
发生在双亲委派模型出现之前，即JDK1.2发布之前。用户在自定义类加载器时，重写loadClass()方法来实现自己的类加载逻辑。现在，JDK1.2之后已不再提倡用户重写该方法，因为此方法是双亲委派模型实现的关键，而是让用户重写findClass()方法。
第二次
模型自身的缺陷导致，比如无法解决基础类中调用用户的代码的问题，如JNDI服务（Java Naming and Directory Interface）。
第三次
代码热替换、模块热部署等。
内容来自《深入理解Java虚拟机》：虚拟机类加载机制
扩展阅读：
