虚拟机类加载机制详解
1.在Class文件中描述的各种信息，最终都要加载到虚拟机中之后才能被运行和使用。虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的java类型，这就是虚拟机的类加载机制。
2.与在编译时进行连接工作的语言不同，在java中类型的加载和连接过程都是在程序运行期间完成的，这样会在类加载时稍微增加一些性能开销，但是却能为java应用程序提供高度的灵活性，java中天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接特点实现的。
3.类从被加载到虚拟机内存中开始，到卸载出内存为止，整个生命周期包括了：加载、验证、准备、解析、初始化、使用和卸载七个阶段，其中的验证、准备、解析三个部分统称为连接，顺序如图。
4.加载、验证、准备、初始化和卸载五个阶段的顺序时确定的，类的加载过程必须按照这种顺序按部就班的开始，而解析阶段不一定：它在某些情况下可以在初始化阶段之后再开始，这是为了支持java语言的运行时绑定（动态绑定）。这些阶段通常都是互相交叉混合开始进行的，通常会在一个阶段执行的过程中调用或者激活另外一个阶段。
5.虚拟机规范中并没有进行强制约束加载阶段的执行时机，可以交给虚拟机的具体实现来自由把握。但是对于初始化阶段，虚拟机规范时严格规定了有且只有四种情况必须立即对类进行初始化（加载、验证、准备自然需要在此之前开始），如图，这四种场景中的行为称为对一个类进行主动引用，其他引用类的方式都不会出发初始化，是被动引用。
6.下面三种情况都是被动引用：
第一种，常量在编译阶段会存入调用类的常量池中，本质上没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。
第二种，通过new 数组定义来引用类，不会触发此类的初始化。
第三种，通过子类引用父类的静态字段，不会导致子类初始化。
7.接口的加载过程与类加载过程稍微有一些不同，针对接口需要做一些特殊说明：接口也有初始化过程，这点与类是一致的，上面的代码都是用静态语句块“static{}”来输出初始化信息的，而接口中不能使用“static{}”语句块，但是编译器仍然会为接口生成“
8.加载阶段是类加载过程的一个阶段，在加载阶段虚拟机需要完成三件事情：
1）通过一个类的全限定名来获取定义此类的二进制字节流；
2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3）在java堆中生成一个代表这个类的java.lang.Class对象，作为方法区这些数据的访问入口。
虚拟机规范的这三点要求实际上并不具体，因此虚拟机实现与具体应用的灵活度相当大。如并没有指出二进制字节流要从哪里获取、怎么获取。
加载阶段（准确说是加载阶段总获取类的二进制字节流的动作）是开发期可控性最强的阶段，因为加载阶段既可以使用系统提供的类加载器，也可以由用户自定义的类加载器去完成。开发人员们可以通过定义自己的类加载器去控制字节流的获取方式。
加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，方法区中的数据存储格式由虚拟机实现自行定义，虚拟机规范未规定此区域的具体数据结构，然后在java堆中实例化一个java.lang.Class类的对象，这个对象将作为程序访问方法区中的这些类型数据的外部接口。加载阶段与连接阶段的部分（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但这些夹在加载阶段之中进行的动作，仍然属于连接阶段的内容，这两个阶段的开始时间仍然保持着固定的先后顺序。
9.验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，是虚拟机堆自身保护的一项重要工作，并且不会危害虚拟机自身的安全。
验证阶段非常重要，并且验证阶段的工作量在虚拟机的类加载子系统中占了很大一部分，但是虚拟机规范对这个阶段的限制和指导显得很笼统，仅仅是说如果验证到输入的字节流不符合Class文件的存储格式，就抛出一个java.lang.VerifyError异常或子类异常，具体检查细节根据不同的虚拟机有所不同。
验证阶段大致分为四个过程：文件格式验证、元数据验证、字节码验证和符号引用验证。
验证阶段对于虚拟机的类加载机制来说，是一个非常重要的、但是不一定必要的阶段，如果所运行的全部代码都已经被反复使用和验证过，在实施阶段就可以考虑使用-Xverify：none参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。
10.文件格式验证要验证是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理，主要目的是保证输入的字节流能正确地解析并存储于方法区之内，格式上符合描述一个java类型信息的要求，这阶段的验证是基于字节流进行的，经过了这个阶段的验证之后，字节流才会进入内存的方法区中进行存储，所以后面的三个验证阶段全部是基于方法区的存储结构进行的。
11.元数据验证是对字节码描述的信息进行语义分析，以保证其描述的信息符合java语言规范的要求，这个阶段的主要目的是对类元数据信息进行语义校验，保证不存在不符合java语言规范的元数据信息。
12.字节码验证是整个验证过程中最复杂的一个阶段，主要工作是进行数据流和控制流分析。上一阶段对元数据信息的数据类型做完校验后，这个阶段将对类的方法体进行校验分析。这阶段的任务是保证被校验类的方法在运行时不会作出危害虚拟机安全的行为。
如果一个类方法体的字节码没有通过字节码验证，那肯定是有问题的，但是如果一个方法体通过字节码验证，也不能书评其一定就是安全的。
13.符号引用验证发生在虚拟机奖符号引用转化为直接引用的时候，这个转化动作将在连接的第三个阶段——解析阶段中发生。符号引用验证可以看作是对类自身以外（常量池中的各种符号引用）的信息进行匹配性的校验。符号引用验证的目的是确保解析动作能正常执行的，如果无法通过符号引用验证，将会抛出一个java.lang.IncompatibleClassChangeError异常的子类。
14.准备阶段时正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中进行分配。这句话中进行内存分配的仅仅包括类变量而不是实例变量，实例变量将会在对象实例化时随着对象一起分配在java堆中。其次这里所说的初始值“通常情况”下是数据类型的零值。下表中是java中所有基本数据类型的零值。
通常情况下假如一个类变量定义为：publicstatic int value = 123;那么变量value在准备阶段过后的初始值为0而不是123，因为这时候尚未开始执行任何方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器
特殊情况下，publicstatic final int value = 123如果类字段的字段属性表存在ConstantValue属性，那在准备阶段变量value就会被初始化为ConstantValue属性所指定的值。
15.解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，下图是符号引用和直接引用。
16.虚拟机规范中并未规定解析阶段发生的具体时间，只要求了在执行anewarray、checkcast、getfield、getstatic、instanceof、invokeinterface、invokespecial、invokestatic、invokevirtual、multianewarray、new、putfield和putstatic这13个用于操作符号引用的字节码指令之前，先对他们所使用的符号引用进行解析。所以虚拟机实现回根据需要判断到底是在类被加载器加载时就对常量池中的符号引用进行解析，还是等到一个符号引用将要被使用前才去解析它。
对一个符号引用进行多次解析请求是很常见的事情，虚拟机实现可能会对对此解析的结果进行缓存（在运行时常量池中记录直接引用，并把常量标识为已解析状态）从而避免解析动作重复进行。无论是否真正执行了多次解析动作，虚拟机需要保证的都是同一个实体中，如果一个符号引用之前已经被成功解析过，拿么后续的引用解析请求就应当一直成功；同样地，如果第一次解析失败了，其他指令对这个符号的解析请求也应该收到相同的异常。
解析动作主要针对类或接口、字段、类方法、接口方法四类符号引用进行，分别对应常量池的CONSTANT_Class_info、CONSTANT_Fieldred_info、CONSTANT_Methodref_info和CONSTANT_InterfaceMethodref_info四种常量类型。
17.类初始化阶段是类加载过程的最后一步，前面的类加载过程中，除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作都是由虚拟机主导和控制的，到了初始化阶段才真正开始执行类中定义的Java程序字节码。
在准备阶段，变量已经赋过一次系统要求的初始值，而在初始化阶段，则是根据程序员通过程序制定的主管计划去初始化类变量和其他资源，或者说初始化阶段是执行类构造器
18.下面是
19.虚拟机设计中把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类。实现这个动作的代码模块被称为“类加载器”。
当初是为了满足Java Applet的需求而被开发出来的，如今基本死掉，但是却在类层次划分、OSGi、热部署、代码加密等领域有广阔应用。
20.类加载器虽然只用于实现类的加载动作，但是它在Java程序中起到的作用却不限于类加载阶段。比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提之下才有意义，否则即使这两个类是来源于同一个Class文件，主要加载它们的类加载器不同，这两个类就一定不同。
这里的“相等”包括类的Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回结果，也包括了实用instanceof关键字做对象所属关系判定等情况。如果没有注意到类加载器的影响，可能会出现迷惑的结果。
21.java 虚拟机中只存在两种不同的类加载器：一种是启动类加载器，这个类加载器使用C++实现，是虚拟机自身的一部分；另外一种是所有其他的类加载器，这些类加载器都由java语言实现，独立于虚拟机外部，并且全部集成抽象类java.lang.ClassLoader。
其实细分的话，大部分java程序都会使用三种系统提供的类加载器。如下。
我们应用程序中都是由这三种类加载器互相配合进行加载的，如果有必要，可以加入自己定义的类加载器，如图所展示的类加载器之间的这种层次关系就称为类加载器的双亲委派模型。
它要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不会以继承关系实现，而是使用组合关系复用父加载器的代码。它从jdk1.2推广，但不是强制性模型，只是推荐给开发者的一种类加载器实现方式，大部分java类都遵循这个模型。
22.双亲委派模型的工作流程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此。因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父类加载器反馈自己无法完成这个加载请求时，子加载器才会尝试自己去加载，这样组织类加载器之间的关系的好处是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。
23.双亲委派模型对于保证java程序的稳定运行很重要，但是它的实现却非常简单，实现双亲委派的代码都集中在了java.lang.ClassLoader的loadClass（）方法之中。先检查请求的类是否已经被加载过，若没有加载调用父加载器的loadClass（）方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载器加载失败，则抛出ClassNotFoundException异常后，再调用自己的findClass()方法进行加载。
24.双亲委派模型主要出现过三次较大规模的“被破坏”情况。这里的“被破坏”不带有贬义色彩。
第一次是为了向前兼容jdk1.0就出现的类加载器和抽象类java.lang.ClassLoader，java设计者在jdk1.2中引入双亲委派模型时作出了妥协，在java.lang.ClassLoader添加了一个新的protected方法findClass()。Jdk1.2之后不提倡覆盖loadClass（）方法，而应该把自己的类加载逻辑写到findClass（）方法来完成加载，这样可以保证新写出来的类加载器是符合双亲委派规则的。
第二次是由于这个模型自身的缺陷导致的。双亲委派很好的解决了各个类加载器的基础类的统一问题，基础类之所以“基础”是因为它们总是作为被用户代码所调用API，但是也可能出现基础类调用回用户的代码，java设计者引入了一个不太优雅的设计：线程上下文加载器，这个类加载器可以通过java.lang.Thread类的setContextClassLoader（）方法设置，如果创建线程时还未设置，它将从父线程中继承一个；如果在应用程序的全局范围内都没有设置过，那么这个类加载器默认就是应用程序类加载器。这实际上打通了双亲委派模型的层次结构来逆向使用类加载器，已经违背了双亲委派模型的一般性原则，但也是无可奈何的事情。
第三次是由于用户对程序动态性的追求而导致的，这里的动态性指的是代码热替换、模块热部署等。代码热替换像外设一样，不关机即可更换或升级外设。OSGi是当前业界Java模块化标准，OSGi实现模块热部署的关键是它自定义的类加载器机制的实现。每一个程序模块（Bundle）都有一个自己的类加载器，当需要更换模块时，就把模块连同类加载器一起换掉以实现代码热替换。
25.OSGi环境下，类加载器不再是双亲委派模型中的树状结构，而是网状结构，当收到类加载请求时，OSGi将按照下面的顺序进行类搜索：