java虚拟机之虚拟机类加载机制

java虚拟机之内存模型篇
java虚拟机之垃圾回收篇
java虚拟机之垃圾收集器篇
java虚拟机之虚拟机类加载机制
java虚拟机之Java内存模型与线程

虚拟机类加载机制

类加载时机

加载，验证，准备，初始化，卸载这个五个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班的开始，而解析阶段不一样：它在某些情况下可以在初始化阶段之后再开始

类加载过程
加载：
加载(Loading)阶段是“类加载”(Class Loading)过程的第一个阶段，在此阶段，虚拟机需要完成以下三件事情：
1、通过一个类的全限定名来获取定义此类的二进制字节流。
2、将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3、在Java堆中生成一个代表这个类的java.lang.Class对象，作为方法区这些数据的访问入口。 加载阶段即可以使用系统提供的类加载器在完成，也可以由用户自定义的类加载器来完成。 加载阶段与连接阶段的部分内容(如一部分字节码文件格式验证动作)是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始。

在第一条中并没有指明是去哪里获取二进制字节流，所以后面就有了各种方式：
Zip中读取，网络中获取，运行时计算生成（动态代理计数），由其他文件生成比如jsp生成class类，数据库中读取

这个阶段是开发人员可空性最强的，可以使用系统提供的引导类加载器来完成，也可以由用户自定义类加载器去完成。
验证：
验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
大致完成以下四个阶段的检验动作：
文件格式验证：验证字节流是否符合class文件格式的规范，并且能被当前版本的虚拟机处理（e.g 指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量）
元数据验证：对字节码描述的信息进行语义分析，以保证其描述信息符合java语言规范的要求（e.g这个类是否有父类，这个类的父类是否继承了不允许被继承的类）
字节码验证：主要工作是进行数据流和控制流分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的行为。 （e.g 保证跳转指令不会跳到方法体以外的字节码指令上）
符号引用验证：发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在“解析阶段”中发生。验证符号引用中通过字符串描述的权限定名是否能找到对应的类；在指定类中是否存在符合方法字段的描述符及简单名称所描述的方法和字段；符号引用中的类、字段和方法的访问性(private、protected、public、default)是否可被当前类访问验证阶段对于虚拟机的类加载机制来说，不一定是必要的阶段。如果所运行的全部代码确认是安全的，可以使用-Xverify：none参数来关闭大部分的类验证措施，以缩短虚拟机类加载时间。

准备

   准备阶段是为类的静态变量（类变量，不是实例变量）分配内存并将其初始化为默认值，这些内存都将在方法区中进行分配。准备阶段不分配类中的实例变量的内存，实例变量将会在对象实例化时随着对象一起分配在Java堆中。
    public static int value=123;//在准备阶段value初始值为0 。在初始化阶段才会变为123 。

解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。
符号引用（Symbolic Reference）：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中。
直接引用（Direct Reference）：直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是与虚拟机实现的内存布局相关的，如果有了直接引用，那么引用的目标必定已经在内存中存在。

初始化
类初始化是类加载过程的最后一步，前面的类加载过程，除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由虚拟机主导和控制。到了初始化阶段，才真正开始执行类中定义的Java程序代码。
初始化阶段是执行类构造器()方法的过程。()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块(static{}块)中的语句合并产生的。
类加载器

类与类加载器

注意：对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在java虚拟机中的唯一性。
启动类加载器：它用来加载 Java 的核心库(jre/lib/rt.jar)，是用原生C++代码来实现的，并不继承自java.lang.ClassLoader。
加载扩展类和应用程序类加载器，并指定他们的父类加载器，在java中获取不到

扩展类加载器（extensions class loader）：它用来加载 Java 的扩展库(jre/ext/*.jar)。Java 虚拟机的实现会提供一个扩展库目录。该类加载器在此目录里面查找并加载 Java 类。
应用程序类加载器：它根据 Java 应用的类路径（CLASSPATH）来加载 Java 类。一般来说，Java 应用的类都是由它来完成加载的。可以通过 ClassLoader.getSystemClassLoader()来获取它。
自定义类加载器（custom class loader）：
除了系统提供的类加载器以外，开发人员可以通过继承 java.lang.ClassLoader类的方式实现自己的类加载器，以满足一些特殊的需求。

类加载器的双亲委派模型

双亲委派模型是一种组织类加载器之间关系的一种规范,他的工作原理是:如果一个类加载器收到了类加载的请求,它不会自己去尝试加载这个类,而是把这个请求委派给父类加载器去完成,这样层层递进,最终所有的加载请求都被传到最顶层的启动类加载器中,只有当父类加载器无法完成这个加载请求(它的搜索范围内没有找到所需的类)时,才会交给子类加载器去尝试加载.
　　这样的好处是:java类随着它的类加载器一起具备了带有优先级的层次关系.这是十分必要的,比如java.langObject,它存放在\jre\lib\rt.jar中,它是所有java类的父类,因此无论哪个类加载都要加载这个类,最终所有的加载请求都汇总到顶层的启动类加载器中,因此Object类会由启动类加载器来加载,所以加载的都是同一个类,如果不使用双亲委派模型,由各个类加载器自行去加载的话,系统中就会出现不止一个Object类,应用程序就会全乱了.
　　
我整理的文档下载