第七章 虚拟机类加载机制
与那些编译时需要进行连接的语言不通，java中类型的加载，连接和初始化过程都是在运行期间完成的，这种策略虽然会增加一些性能开销，但是会为java应用程序提供高度的灵活性，java里天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的。
一 类加载的时机
类的生命周期包括：加载，验证，准备，解析，初始化，使用和卸载7个阶段。其中，验证，准备，解析三个部分统称为连接
加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的 ，解析阶段在某些情况下可以再初始化之后在再开始，这是为了支持java 的运行时绑定。
二 类加载的过程
1. 加载
在加载阶段，虚拟机需要完成三件事：
1.通过一个类的全限定名来获取定义此类的二进制字节流
where&how获取二进制流？
从JAR、EAR、WAR格式的包中(Tomcat就是通过部署在上边的WAR包来运行整个web项目的)
从网络中获取(Applet应用)
动态代理技术(java.lang.reflect.Proxy)
JSP文件
从数据库中读取(中间件服务器SAP Netweaver)
2.将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
3.在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
2. 验证
为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。(因为Class文件不仅仅可以由java源文件编译形成，也可以人为构造Class文件。如果输入的字节流不符合Class文件的存储格式，抛错:java.lang.VerifyError)。
文件格式验证：第一阶段要验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。可能包含：
是否以魔数0xCAFEBABE开头
主、次版本号是否在当前虚拟机处理范围之内
常量池的常量中是否有不被支持的常量类型
指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量
CONSTANT_Utf8_info型的常量中是否有不符合UTF8编码的数据
Class文件中各个部分以及文件本身是否有被删除的或附加的其他信息
元数据验证：第二阶段是对字节码描述的信息进行语义分析，以保证其描述的信息符合java语言规范的要求。
这个类是否有父亲(除了java.lang.Obejct之外，所有的类都应当有父类)
这个类的父亲是否继承了不允许被继承的类(被final修饰的类)
如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法
类中的字段、方法是否与父类产生了矛盾
字节码验证：主要目的是通过数据流和控制流分析，确定程序语义是合法的，符合逻辑的。
保证任意时刻操作数栈的数据类型与指令代码都能配合工作，例如不会出现类似这样的情况：在操作栈中放置了一个int类型的数据，使用的时候却按long类型来加载到本地变量表中
保证跳转指令不会跳转到方法体以外的字节码指令上
保证方法体中的类型转换是有效的，例如可以把一个子类对象赋值给父类数据类型，这是安全的，反之则是危险的。
符号引用验证：符号引用验证可以看做是对类自身以外（常量池中的各种符号）的信息进行匹配性校验。
符号引用中通过字符串描述的全限定名是否能找到对应的类
在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段
符号引用中的类、字段和方法的访问行(private,protected,public,default)是否可被当前类访问
3. 准备
准备阶段是正式为类变量分配内存并设置变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。这时候进行内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量会在对象实例化时随着随想一起分配在java堆中。并且，初始值通常情况是数据类型的零值，而不是代码中所赋予的值。
4. 解析
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。
符号引用(Symbolic References):符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中。
直接引用(Direct References):直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是虚拟机实现的内存布局相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经在内存中存在。
虚拟机规范并未规定解析阶段发生的具体时间，只要求了在执行anewarray、checkcast、getfield、getstatic、instanceof、invokeinterface、invokespecial、invokestatic、invokevirtual、multianewarray、new、putfield、putstatic这13个用于操作符号引用的字节码指令之前。
解析动作主要针对类或接口、字段、类方法、接口方法四类符号引用进行，分别对应于常量池的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info四种常量类型。
5. 初始化
该过程是类加载过程的最后一步。在该过程中，才开始真正执行类中定义的Java代码。（注意该过程并不是对象的实例化）
虚拟机会执行类构造器<clinit>()方法来初始化该类。简单归纳一下就是：
类的初始化：（最后一步）执行面向类的构造器（<clinit>()）
对象的初始化：执行面向对象的构造器(Constructor)
类构造器<clinit>()方法是指：该方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的。编译器收集的顺序是由语句在源文件中出现的顺序决定的。
注意：静态语句块只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块中可以赋值，但是不能访问。
public class B
{
static{
i=0;//编译正常
System.out.println(i);//Cannot reference a field before it is defined(非法向前引用)
}
static int i=1;
}
另外，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其它线程都需要阻塞等待。
三 类加载器
类加载阶段中“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作在java虚拟机外部实现，以便让应用程序自己决定如何获取所需要的类。实现这个动作的代码模块叫做“类加载器”。
比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义。
1. 双亲委派模型
类加载器分类：启动类加载器，扩展类加载器，应用程序类加载器（也叫系统类加载器）。
如图所示的类加载器之间的层次关系，成为类加载器的双亲委派模型。要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。父子关系一般不会以继承的关系来实现，而是都是用组合关系来服用父加载器的代码。
双亲委派模型的工作过程：如果一个类加载器收到了类加载的请求，它首先不会去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父类加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。
这样有一个显而易见的好处就是java类随着它的类加载器一起具备了一种带有优先级的层次关系。
2. 破坏双亲委派模型
父加载器的类对子加载器是可见的，但是子加载器的类对父加载器默认是不可见的。那么我们如何实现父加载器中的类访问子加载器中的类呢？
答案是用线程上下文类加载器，通过线程上下文类加载器可以实现父加载器对子加载器的逆向访问。例如JDBC，JNDI等都采用了这种方式。
另外在OSGI环境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为更加复杂的网状结构。