1.前言
本章记录一下Class文件是怎么被加载到内存中进行执行的。
虚拟机并没有约束一定是本地文件才能进行加载，网络文件也是可以的，也没有约束必须是Java文件，一切遵守虚拟机解析规则的文件都能被加载，Java对应的就是Class字节码文件了。
不同于其他语言，在编译时就需要进行连接，Java语言中，类型的加载，连接和初始化都是在程序运行期间完成的，这会带来一定的开销，但是会为Java提供高度的灵活性。比如编写一个面向接口的程序，可以在运行时再指定其实际的实现类。
下面将讨论虚拟机的类加载机制，更好的理解类是如何执行的。
2. 加载过程
可以看见上图，主要是这么一个过程，连接也是在运行过程中完成的。加载、验证、准备、初始化、卸载这5个步骤的顺序是确定的，解析阶段则不一定，某些时候可以在初始化之后，这是为了支持Java的运行时绑定（动态绑定）。
什么时候进行加载，虚拟机规范中没有强制要求，但是初始化操作有严格的规定，5种情况下必须立刻执行（很好理解，我需要这个类的相关信息了，必须准备好）：
1.new、getstatic、putstatic、invokestatic这4个字节码指令时，没有初始化，必须初始化。
2.反射调用的时候，没初始化，必须初始化
3.初始化子类的时候，要先加载其父类。
4.虚拟机启动时，要指定一个执行的主类（main方法的类），需要先初始化
5.JDK7的动态语言支持时，java.lang.invoke.MethodHandle实例最后的解析结果是REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄时，对应的类没有初始化，需要初始化。
只有上述5种情况才会初始化，这些情况称为对一个类进行主动引用。除此外，所有引用类的方式都不会触发初始化，称为被动引用。
注意：public static final String，执行这种类型的字段时，也不会触发初始化，虽然其看起来是getstatic，但是实际上在编译环节被优化了，通过常量传播，引用这个字段的类转化成了对常量池的引用，与这个字段的类没有任何关系了。new 数组的时候也不会触发，即便数组的元素是要触发初始化的类。
接口的初始化只有第3种情况不同，并不要求其父接口全部完成了初始化，只有在真正使用了父接口的时候才会初始化。
3.步骤详解
3.1 加载
加载阶段，虚拟机需要完成以下3件事情：
1.通过一个类的全限定名来获取定义此类的二进制字节流
2.将这个字节流代表的静态存储结构转化成方法区的运行时数据结构
3.在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口
虚拟机规范没有严格限制上述内容，可以自由发挥，也因此出现了很多有意思的技术：
1.从ZIP包中读取，最终出现了JAR、EAR、WAR格式
2.从网络中获取，典型的就是Applet
3.运行时生成，就是动态代理技术
4.由其他文件生成，JSP应用，JSP生成对应的Class类
5.从数据库中读取。
相对于其他过程，一个非数组类的加载（准确说是获取类的二进制字节流的动作）是开发人员可控性最强的，因为加载阶段可以使用系统提供的引导类加载器来完成，也可以由用户自定义的类加载器来完成。
对数组类而言，情况就不一样了，数组类本身不通过类加载器创建，由虚拟机直接创建，但是又和类加载器有很大的关系。因为数据的元素类型最终要类加载器去创建。一个数组类的创建过程要遵循下面规则：
1.如果数组的类型是引用类型，就递归采用上面的加载过程加载这个组件类型，数组将在加载该组件类型的类加载器的类名称空间上被标识。（类必须和类加载器一同确定唯一性）
2.如果不是引用类型（int[]），会标记数组为引导类加载器关联
3.数组类的可见性与组件类型可见性一致，如果不是引用类型，就是public
加载完成之后，类就按照虚拟机的格式存储在方法区之中，在内存中实例化一个java.lang.Class类的对象。对于HotSpot而言，这个对象放在方法区中，而不是堆中。
加载过程和连接过程是交叉的，比如验证，连接阶段可能已经开始。
3.2 验证
验证阶段其实很好理解，就是确保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来关闭。
3.3 准备
准备阶段是为类的变量分配内存，并设置类变量初始值的阶段，这些变量使用的内存，都在方法区中进行分配。注意，只包含static类变量，实例变量是在堆中的，初始值一般是数据类型的零值，比如public static int value = 123。初始值是0，而不是123，这个时候没有执行任何Java方法，而把value赋值为123的putstatic指令是程序被编译后，存放在类构造器<clinit>()方法中，所以在初始化阶段才会赋值成123。又要注意，一般是数据类型的零值，但是还有特殊情况，比如被final修饰，存在ConstantValue属性，会在准备阶段就会赋值。
3.4 解析
解析阶段就是将常量池中的符号引用替换成直接引用了。这里需要延伸一下知识，Java为了实现其动态性，在编译的时候都是通过符号引用来占位子，在这个阶段就要对应具体的引用对象了。
符号引用：一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用的时候能无歧义的定位目标即可。与虚拟机实现的内存布局无关，引用的目标不一定已经加载到内存中（这个特性很有用），但是能接受的符号引用必须是一致的，因为这个字面量形式明确定义在Java虚拟机规范的Class文件格式中。
直接引用：直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用与内存布局相关，在不同虚拟机中符号引用会被翻译出不同的直接引用，如果有了直接引用，那么引用目标一定在内存中。
虚拟机规范中没有规定解析的发生具体时间，所以是否是在加载时就完成符号引用的解析，还是到符号引用被使用时再进行解析，这个根据实际需要决定。但是规范规定了16个操作符号引用的字节码之前，要完成解析动作，为：anewarray、checkcast、getfield、getstatic、instanceof、invokedynamic、invokeinterface、invokespecial、invokestatic、invokevirtual、ldc、ldc_w、multianewarray、new、putfield、putstatic。
对一个符号引用进行多次解析请求是很常见的，为了避免这个问题，虚拟机实现可以在第一个解析成功后，缓存结果，后续使用这个结果即可。但是如果第一次失败，后面都会失败。
上述避免重复解析的规则，对于指令invokedynamic指令不成立。因为这个本来就是用来支持动态语言的，其对应的引用称为“动态调用点限定符"。动态的含义就是必须等到程序实际运行到这条指令的时候，解析动作才能进行。
解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。Java是静态类型语言，后面3种与JDK7种新增的动态语言支持相关，本章不进行介绍，留到动态语言调用，即虚拟机执行引擎的时候描述。
3.4.1 类或接口的解析
如果当前代码是在Test类中，将一个未解析过的符号引用N解析成一个类或接口C的直接引用，那么需要完成下面步骤：
1.如果C不是数组类型，虚拟机会将N的全限定名传递给Test的类加载器，去加载类C，可能触发其他的加载，一旦失败解析失败。
2.如果C是数组，N的描述符会是类似[Ljava/lang/Integer]形式，会按1的规则加载数组的元素类型，接着由虚拟机生成一个代表此数组维度和元素的数组对象。这里就是加载Integer类了。
3.上述步骤成功，在虚拟机中已经有一个有效的C类或接口了，但是还需要对符号引用进行验证，确定Test是否能够访问C，不能访问抛出IllegalAccessError
通俗的说就是Test类有个X tmp对象。类型X没有被解析，是一个符号引用，如果不是一个数组，就要用Test的类加载器加载这个类，如果是数组，也要加载，不过要额外开辟数组对象。
3.4.2 字段解析
要解析一个未被解析过的字段符号引用，首先会对符号引用进行解析，也就是字段所属的类或接口的符号引用。如果在解析这个类或接口符号引用过程中出任何异常，都会导致字段符号引用解析失败。解析成功，需要进行下面操作，假设字段所属类或接口是C：
1.如果C本身包含了简单名称和字段描述符都与目标相匹配的字段，则直接返回这个字段的直接引用，查找结束。
2.如果不包含，C中实现了接口，从下往上递归搜索接口，如果包含简单名称和字段描述符与目标匹配，返回直接引用，查找结束
3.如果还没找到，会从下到上搜索继承体系，如果匹配返回直接引用，查找结束
4.否则，失败，抛出NoSuchFieldError异常。
成功后也会进行验证，判断有没有访问权限。
通俗的说就是：类Test打印了C.value这个字段，C中没有，先从下往上的接口中查找，仍没有，从下往上的继承找，还是没找到就抛出异常。
实际上编译器会更严格一些，如果一个字段同时出现在C的接口和父类中，或者同时在自己或父类的多个接口中出现，编译器可能拒绝编译。
3.4.3 类方法解析
方法解析和字段解析第一步都一样，先对所属的类或接口的符号引用进行解析，成功后会对后续的类方法进行搜索：
1.类方法和接口方法的符号引用的常量类型定义是分开的，所以发现是个接口，直接抛出IncompatibleClassChangeError异常
2.查找是否有简单名称和描述符都匹配的方法，找到就结束
3.没找到，去父类查找，直到找到
4.没找到，去接口列表查找，找到了说明C是一个抽象类，抛出AbstractMethodError异常
5.否则抛出NoSuchMethodError
简单说就是Test中调用一个C.doSomething()方法，先找这个引用是不是一个接口，不是就要找这个方法是哪个父类的，没找到那就是接口的了，没有具体实现，要抛出异常，都没找到更错的离谱了。
3.4.4 接口方法解析
接口方法也需要先解析出接口方法表的方法所属的类或接口的符号引用，解析成功，用C表示这个接口，进行下面的步骤：
1.如果C是个类，不是接口，抛出IncompatibleClassChangeError异常
2.是接口，查找C中是否有匹配的，有就查找结束
3.没找到，就在C的父接口递归查找，直到Object类，匹配就结束
4.找不到，抛出NoSuchMethodError异常
接口的方法默认是public，所以没有访问权限的问题。
简单说就是Test调用C.doSomething()，这是一个接口方法，如果C是类那么抛出异常，如果C中没有这个方法，找父接口，没找到也要抛出异常。
3.5 初始化
初始化是类加载的最后一步，会真正执行类中定义的Java代码。准备阶段，变量赋予了零值，初始化阶段要赋予真正的值了。
初始化是执行类构造器<clinit>()方法的过程，这个方法是由类变量的赋值动作，和静态语句块static{}语句合并产生的。由顺序决定，静态块只能访问到定义在静态块之前的变量，之后的变量可以赋值，不能访问。这个方法与构造函数<init>()方法不同，不需要显示的调用父类构造器，虚拟机会保证执行子类的<clinit>()方法之前，父类的已经执行完毕了。由于父类的先执行，所以父类的static会先执行。
此外<clinit>方法不是必须的，如果没有赋值操作且没有静态代码块，就不会生成这个方法。接口虽然没有static块，但是会由赋值操作，与类不同的地方在于接口不需要先执行父类的<clinit>()方法。只有在父接口的变量使用时，才会初始化父接口。另外接口的实现类在初始化的时候也不会执行接口的<clinit>()方法。虚拟机会保证一个类的<clinit>()方法在多线程环境被正确地加锁、同步，如果有多个线程同时初始化，只会执行一次。其他线程会阻塞，所以执行时间很久会导致多个线程阻塞。
4 类加载器
之前说了虚拟机将加载二进制字节流的动作放在虚拟机外实现，让程序自己决定如何获取所需要的实现类。实现这个动作的代码模块称为”类加载器“。
类加载器是一个创新，最初是满足Java Applet的需求而开发的。但是在类层次划分、OSGi、热部署、代码加密等领域大放异彩，成为了Java技术的一块重要基石。
对于任何一个类都需要类本身和其加载器来确定唯一性，每个类加载器都有一个独立的类名称空间，比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则即使是同一个Class，被不同的类加载器加载，也是不同的类。这里的相等包括Class的equals方法、isAssignableFrom方法和isInstance方法。
4.1 双亲委派模型
这个机制十分出名。Java提供了三种系统类加载器：
1.启动类加载器（Bootstrap ClassLoader）：这个放在java_homelib目录中，或者-Xbootclasspath参数所指定的路径，被虚拟机识别（固定名称）。这个加载器无法被程序直接引用，用户在编写自定义加载器时，如果需要将加载请求委派给引导类加载器，直接使用null代替即可。getClassLoader方法返回null。
2.扩展类加载器（Extension ClassLoader)：这个加载器由sun.misc.Launcher$ExtClassLoader实现，负责加载java_homelibext目录中的，或者被java.ext.dirs系统变量指定的路径所在类库，开发者可以直接使用扩展类加载器。
3.应用程序类加载器（Application ClassLoader）：这个类加载器由sun.misc.Launcher$AppClassLoader实现。这个类加载器是ClassLoader中的getSystemClassLoader方法的返回值，所以也称为系统类加载器。负责加载用户ClassPath上所指定的类库，可以直接使用，如果代码里面没有定义自己的加载器，就会默认使用这个。 
双亲委派模型中加载器除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这个关系不是通过继承来实现的，而是组合关系来复用父加载器的代码。
工作过程是：当收到类加载请求，首先不会自己加载这个类，而是把请求给父类加载，最终传递到最上层的启动类加载器中，只有当父加载器反馈自己无法加载时（没有在lib下找到这个类），子类加载器才会尝试加载。
这个模型的好处在于Java类有了一种优先级的层次关系。比如Object类，这个毫无疑问应该交给最上层的加载器进行加载，所以在各个类加载器环境中这个类都是同一个类。如果没有双亲委派模型，自己写一个java.lang.Object类，会出现很多个不通的Object类，应用程序会一片混乱。
实现很简单，都在ClassLoader的loadClass方法之中，先检查是否被加载过，若没有加载就调用父类加载器的loadClass方法，若父类加载器为空，默认使用启动类加载器，如果加载失败，抛出异常后调用自己的findClass()方法进行加载。
4.2 破坏双亲委派模型
双亲委派模型不是一个强制性的约束模型，有被破坏的情况。
第一次是因为兼容老版本的JDK，这个模型在1.2版本才出现，但是ClassLoader在1.0就存在了。添加了一个protected方法findClass()，之前版本继承ClassLoader唯一目的就是重写loadClass方法，因为虚拟机会去调用loadClassInternal方法，这个方法就是执行loadClass()。1.2之后就不提倡重写loadClass了，而是写findClass方法，因为loadClass的基本逻辑已经写好，父类加载失败，就会调用自己的findClass进行加载，这样保证新写出来的类加载器是符合双亲委派模型的。
第二次破坏是因为双亲委派模型自身的缺陷，作为顶层的类通常是被底层类调用的，但是如果顶层的基本类调用了底层的用户类就麻烦大了。顶层的类加载器并不认识用户的类，这样如何去加载这个类呢？典型的例子就是JNDI服务，其目的是对资源进行集中管理和查找，需要调用应用程序的classpath的代码。比如SPI服务发现：这里。可以看到系统类需要加载自己写的类，这个就麻烦了。为了解决这个问题，设计了一个线程上下文加载器Thread Context ClassLoader。这个类加载器可以通过Thread类的setContextClassLoader方法进行设置，如果创建线程的时候没有设置，将会从父线程中继承一个，全局范围都没有设置，默认就是应用程序类加载器。设置了这个，就可以在父加载器中获取子加载器，让其进行加载类了。这是无奈之举，很多SPI加载动作都采用了这种方式，比如：JNDI、JDBC、JCE、JAXB、JBI等。
第三次被破坏是由于追求动态性导致的。比如：代码热替换，模块热部署等。比较出名的就是OSGi这个事实上的Java模块化标准，其模块热部署的关键就是它自定义的类加载器实现机制。每个模块（Bundler）都有一个自己的类加载器，当需要更换一个Bundle时，把Bundle连同类加载器一起换掉以实现代码热替换。
OSGi按照下面的顺序进行类搜索：
1.java.*开头的类委派给父类加载器加载
2.将委派列表中的类交给父类加载器加载
3.将import列表中的类委派给Export这个类的Bundle的类加载器加载
4.查找当前Bundle的Classpath，使用自己的类加载器加载
5.查找类是否在自己的Fragment Bundle中，如果在，委派给Fragment Bundle进行加载
6.查找Dynamic Import列表的Bundle，委派给对应Bundle加载
7.类查找失败