JVM_14_类加载的过程
类加载过程
下面我们看下Java虚拟机中类加载的全过程，也就是加载、验证、准备、解析和初始化这5个阶段所执行的具体动作。
1. 加载
"加载"是"类加载"(Class Loading)过程的一个阶段(简单地说，就是"加载"包含在"类加载"之中..)。
在加载阶段，虚拟机需要完成以下三件事情：
a. 通过一个类的全限定名来获取定义此类的二进制字节流。
(获取类的二进制字节流)
b. 将这个字节流所代表的静态存储结果转化为方法区的运行时数据结构。
(将二进制字节流转换为运行时数据结构)
c. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
(生成类对应的Class对象)
虚拟机规范的这三点要求其实并不算具体，因此虚拟机实现与具体应用的灵活度都是相当大的。
举个栗子：
"通过一个类的全限定名来获取定义此类的二进制字节流"这条；
它没有指明二进制字节流要从一个Class文件中获取，准确的说是根本没有指明从哪里获取、怎么获取。
例如你可以按照下面方式获取：
○ 从ZIP包中读取，这很常见，最终成为日后JAR、EAR、WAR格式的基础
○ 从网络中读取，最典型的应用是Applet
○ 运行时计算生成，最典型的是动态代理技术，在java.lang.reflect.Proxy中，就是使用ProxyGenerator.generateProxyClass来为特定接口生成形式为"*$Proxy"的代理类的二进制字节流。
○ 由其他文件生成，典型的场景是JSP应用，即由JSP文件生成对应的Class文件。
○ 从数据库中读取，这种场景较少
相对于类加载的其他阶段，一个非数组类的加载阶段(加载阶段中获取类的二进制字节流的动作)是开发人员可控性最强的，因为加载阶段既可以使用系统提供的引导类加载器来完成，也可以由用户自定义的类加载器去完成。
开发人员可以通过定义自己的类加载器去控制字节流的获取方式(即重写一个类加载器的loadClass()方法)
对于数组类而言，情况就有所不同，数组类本身不通过类加载器创建，它是由Java虚拟机直接创建的。
但数组类与加载器仍然有很密切的关系，因为数组类的元素类型(指的是数组去掉所有维度的类型)最终是要靠加载器去创建。
加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，方法区中的数据存储格式由虚拟机实现自行定义，虚拟机规范未规定此区域的具体数据结构。
然后在内存中实例化一个java.lang.Class类的对象，这个对象将作为程序访问方法区中 这些类型数据的外部接口。
加载阶段与连接阶段的部分内容是交叉进行对的，加载阶段尚未完成，连接阶段可能已经开始，但这些夹在加载阶段之中进行的动作，
仍然属于连接阶段的内容，这两个阶段的开始时间仍然保持着固定的先后顺序。
2. 验证
验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害到虚拟机自身的安全。
验证阶段是非常重要的，这个阶段是否严谨，直接决定了Java虚拟机是否能接受恶意代码的攻击，从执行性能的角度上讲，验证阶段的工作量在虚拟机的类加载子系统中占了相当大的一部分。
如果验证到输入的字节流不符合Class文件格式的约束，虚拟机就应当抛出一个java.lang.VerifyError异常或其子类异常。
根据《Java Virtual Machine Specification Java SE 7 中文版》中的资料，从整体上看，验证阶段大致上分为以下4检验动作：
a. 文件格式校验
这一阶段要验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。
验证点：
® Class文件是否以魔数0xCAFEBABE开头。
® 主、次版本号是否在当前虚拟机处理范围之内。
® 常量池中的常量是否又不被支持的常量类型。
® Class文件中各个部分及文件本身是否有被删除的或附加的其他信息。
® ............
第一阶段的验证还有好多..上面只是一小部分....
这阶段的验证是基于二进制字节流进行的，只有通过了这个阶段的验证，字节流才会进入内存的方法区中进行存储。
所以 后面三个验证阶段全是基于方法区的存储结构进行的，不会再直接操作字节流。
b. 元数据验证
第二阶段是对字节码描述的信息进行语义分析，保证其描述的信息符合Java语言规范的要求。
验证点：
® 这个类是否有父类(除了java.lang.Object类之外，所有的类都应当有父类)
® 这个类的父类是否继承了不允许被继承的类(被final修饰的类)
® 类中的字段、方法是否与父类产生矛盾(例如：覆盖了父类的final字段，或者出现不符合规则的方法重载...)
® .......
第二阶段主要是对类的元数据信息进行语义校验，保证不存在不符合Java语言规范的元数据信息。
c. 字节码验证
第三阶段是整个验证过程中最复杂的一个阶段，主要目的是通过数据流和控制流分析，确定程序语义是合法、符合逻辑的。
这个阶段会对类的方法体进行校验分析，保证校验类的方法在运行时不会做出危害虚拟机安全的事情，栗如：
® 在操作栈放置一个int类型的数据，使用时却按long类型加载如本地变量表中。
® 保证跳转指令不会跳转到方法体以外的字节码指令上。
® 保证方法体中得到类型转换是有效的。
® ........
如果一个类方法体没有通过字节码验证，那肯定是有问题的；
但如果一个方法体通过了字节码验证，也不能说其一定是安全的。
d. 符号引用验证
最后一个阶段验证发生在虚拟机将符号引用转换为直接引用的时候，这个转化动作将在第三阶段——解析阶段中发生。
符号引用可以看做是对类自身以外(常量池中的各个符号引用)的信息进行匹配性校验。
校验内容：
® 符号引用中通过字符串描述的全限定名是否能找到对应的类。
® 在指定类中是否存在符合方法的字段描述符以及简单名称所描述得到方法和字段。
® 符号引用中的类、字段、方法的访问性(private、protected、public、default)是否可被当前类访问。
® .........
符号引用验证的目的是确保解析动作能正常执行。
对于虚拟机的类加载机制来说，验证阶段是一个非常重要的、但不一定必要(因为对程序运行期没有任何影响)的阶段。
如果所运行的全部代码都已经被反复使用和验证过，那么在实施阶段就可以考虑使用"-Xverify:none"参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。
3. 准备
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区进行分配。
这时候进行内存分配的仅包括类变量(被static修饰的变量)，而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中。
其次，上面所说的初始值，在"通常情况"下，是数据类型的零值。
举个栗子：
private static int value = 123;
这个变量value在准备阶段过后的初始值为0，而不是123，因为这时候尚未开始执行任何Java方法，而把value赋值为123的putstatic指令是程序被编译后，存放在类构造器
下面是基本数据类型的初始值：
| 数据类型 |
零值 |
| int |
0 |
| long |
0L |
| short |
(short)0 |
| char |
'\u0000' |
| byte |
(byte)0 |
| boolean |
false |
| float |
0.0f |
| double |
0.0d |
| reference |
null |
上面提到，在"通常情况"下，初始值是零值，那相对的会有一些"特殊情况"：如果类字段得到字段属性表中存在ConstantValue属性，那在准备阶段变量value就会被初始化微ConstantValue属性所指定的值。
举个栗子：
public static final int value = 123;
上面这个代码，在编译时Javac就会将value生成ConstantValue属性，在准备阶段虚拟机就会根据ConstantValue的设置，将value赋值为123
4. 解析
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。
5. 初始化
类初始化阶段是类加载过程的最后一步，前面的类加载过程中，除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由虚拟机主导和控制。
到了初始化阶段，才真正开始执行类中定义的Java程序代码(或者说是字节码)
在准备阶段，变量已经赋过一次系统要求的初始值，而在初始化阶段，则根据程序员通过程序制定的主观计划去初始化变量和其他资源。