1.1 加载

加载的过程中,jvm要完成以下三件事：

• 通过一个类的全限定名来获取定义此类的二进制字节流。
• 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
• 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。

注意：对于第一条,jvm并没有特殊地去指定这个类应该从哪里获取,基于这一条,现在的java平台发展出了jar,war等;以及动态的运行时计算生成,也就是我们现在著名的动态代理技术;另外也诸如由其他的文件生成,例如jsp。

非数组类的加载阶段：类的加载阶段可以使用系统的类加载器,也可以自定义类加载器(重写一个类加载器的loadClass()方法)。

数组类的加载阶段：数组类本身不通过类加载器创建，它是由Java虚拟机直接创建的。一个数组类创建过程遵循以下规则：

• 如果数组的组件类型是引用类型，就递归采用上面的加载过程去加载这个组件类型，数组将在加载该组件类型的类加载器的类名称空间上被标识。
• 如果数组的组件类型不是引用类型（例如int[]数组），Java虚拟机将会把数组标记为与引导类加载器关联。
• 数组类的可见性与它的组件类型的可见性一致，如果组件类型不是引用类型，那数组类的可见性将默认为public。

加载的阶段完成后，jvm外部的二进制字节流按虚拟机所需要的格式存在方法区里，方法区中的数据存储格式由jvm自行定义。然后在内存中实例化一个java.lang.Class类的对象(没有明确规定是在java堆里,对于Hotspot来说，Class对象比较特殊,虽然是对象，却会放在方法区里)。

1.2 验证

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

验证阶段大致上会完成下面4个阶段的检验动作：

• 文件格式验证：验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。这阶段的验证是基于二进制字节流进行的，只有通过了这个阶段的验证后，字节流才会进入内存的方法区中进行存储，所以后面的3个验证阶段全部是基于方法区的存储结构进行的，不会再直接操作字节流。
• 元数据验证：对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求。（这个类是否有父类，父类是否继承了不允许被继承的final类等）。
• 字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。保证被校验类的方法体在运行时不会做出危害虚拟机安全的事件。
• 符号引用验证：对类自身以外（常量池中的各种符号引用）的信息进行匹配性校验。

1.3 准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。注意：这时候进行内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中。

我们这里举个例子public static int a = 123;,这里的变量a就是类变量。并且这里我们需要注意一个事情，对于准备阶段而已，变量a的值是0，而复制变量a为123的操作是在初始化阶段的clinit方法中执行的。

但是对于上面的情况，如果把变量a用final修饰,public static final int a = 123;，那么在编译时javac会为变量a生成ConstantValue属性，在准备阶段Jvm就会根据ConstantValue的设置为变量a赋值。

1.4 解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。

符号引用：以一组符号来描述所引用的目标，符号可以是类和形式的字面量，只要使用时能无歧义的定位到目标即可，与虚拟机实现的内存布局无关，引用的目标不一定已经加载到内存中。

直接引用：可以是直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局相关的，引用的目标必定已经在内存中存在。

除了invokeDynamic指令以外，虚拟机实现可以对第一次解析的结果进行缓存(在运行时常量池中记录直接引用，并把常量标示为已解状态)从而避免解析动作重复进行。无论是否真正被执行了多少次解析，jvm需要保证的是在同一个实体中，如果一个符号引用之前已经被成功解析过，那后续的引用解析请求就应该一直成功；同理，第一次解析失败了，那么其他指令对这个符号的解析请求也就应该收到相同的异常。
对应上面的规则，invokeDynamic指令是例外的，invokeDynamic指令只有在程序实际运行到这条指令解析动作才开始进行。

而java的解析阶段主要是针对于4块：类或者接口的解析、字段解析、类方法解析，接口方法解析