jvm虚拟机笔记<三> 类文件结构与类加载机制

java虚拟机具有语言无关系，它只和“class文件“这种特定的二进制文件格式绑定。

不同语言的编译器将对应的程序编译成字节码文件（*.class），送给jvm执行。

class文件本质上就是一张表，由各类数据项构成。

2.1、魔数（是否可以被虚拟机执行）和class文件版本
2.2、常量池(两大类常量：字面量与符号引用)
2.3、访问标志（识别访问信息）
2.4、类索引、父类索引和接口索引集合
2.5、字段表集合
2.6、方法表集合

————————————————————————————————————————————————

一.类加载时机：

共5种情形为主动引用，有且仅有此5种会触发初始化，其他方式全部为被动引用，不会触发类的初始化

5种情形：

遇到new (实例化对象),getstatic(读取一个类的静态字段) ,putstatic(设置一个类的静态字段), invokestatic(调用一个类的静态方法)这4条指令，若类之前没有初始化，需要先对其进行初始化。
使用 java.lang.reflect包的方法对类进行反射调用时，若类之前没有初始化，需要先对其进行初始化。
当初始化一个类，其父类之前没有初始化，需要先对其父类进行初始化。
当虚拟机启动时，主类会先被初始化（包含main方法的类）。
使用jdk7的动态语言支持时，如果一个解析结果与静态字段或静态方法有关，所对应的类之前没有初始化，需要先对其进行初始化。

二.类加载过程

其中类加载的过程包括了加载、验证、准备、解析、初始化五个阶段。

在这五个阶段中，加载、验证、准备和初始化这四个阶段发生的顺序是确定的，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后开始，这是为了支持Java语言的运行时绑定（动态绑定）。

另外注意这里的几个阶段是按顺序开始，而不是按顺序进行或完成，因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。

1.加载

　　加载过程完成一下3件事：

获取一个类全限定名的二进制字节流。
将静态存储结构转换为方法区的运行时数据结构
内存中生产class对象，作为方法区中该类的数据访问入口

　　加载与连接阶段交叉进行（但是开始时间顺序固定）。

2.验证

　　四个阶段：文件格式验证（验证规范），元数据验证（语义校验），字节码验证（数据流与控制流分析），符号引用认证（符号引用的匹配校验）。

3.准备：正式分配内存并设置变量初始值，内存在方法区内分配。

4.解析：将常量池内的符号引用替换为直接引用

　　符号引用：一组可以无歧义定位到目标的符号

　　直接引用：直接指向目标的指针，相对偏移量或者能间接定位到目标的句柄

5.初始化：根据程序制定的主管计划去初始化变量与资源。

三.类加载器

1.类与类加载器。每一个类加载器都有其独立的类名称空间，两个类由同一个类加载器加载才可能相同，否则必然不同（equals，isAssignableFrom，isInstance）

2.双亲委派机制。

类加载器负责加载所有的类，其为所有被载入内存中的类生成一个java.lang.Class实例对象。一旦一个类被加载如JVM中，同一个类就不会被再次载入了。正如一个对象有一个唯一的标识一样，一个载入JVM的类也有一个唯一的标识。在Java中，一个类用其全限定类名（包括包名和类名）作为标识；但在JVM中，一个类用其全限定类名和其类加载器作为其唯一标识。例如，如果在pg的包中有一个名为Person的类，被类加载器ClassLoader的实例kl负责加载，则该Person类对应的Class对象在JVM中表示为(Person.pg.kl)。这意味着两个类加载器加载的同名类：（Person.pg.kl）和（Person.pg.kl2）是不同的、它们所加载的类也是完全不同、互不兼容的。

JVM预定义有三种类加载器，当一个 JVM启动的时候，Java开始使用如下三种类加载器：

1)根类加载器（bootstrap class loader）:它用来加载 Java 的核心类，是用原生代码来实现的，并不继承自 java.lang.ClassLoader（负责加载$JAVA_HOME中jre/lib/rt.jar里所有的class，由C++实现，不是ClassLoader子类）。由于引导类加载器涉及到虚拟机本地实现细节，开发者无法直接获取到启动类加载器的引用，所以不允许直接通过引用进行操作。

2)扩展类加载器（extensions class loader）：它负责加载JRE的扩展目录，lib/ext或者由java.ext.dirs系统属性指定的目录中的JAR包的类。由Java语言实现，父类加载器为null。

3)系统类加载器（system class loader）：被称为系统（也称为应用）类加载器，它负责在JVM启动时加载来自Java命令的-classpath选项、java.class.path系统属性，或者CLASSPATH换将变量所指定的JAR包和类路径。程序可以通过ClassLoader的静态方法getSystemClassLoader()来获取系统类加载器。如果没有特别指定，则用户自定义的类加载器都以此类加载器作为父加载器。由Java语言实现，父类加载器为ExtClassLoader。

类加载器加载Class大致要经过如下8个步骤：

检测此Class是否载入过，即在缓冲区中是否有此Class，如果有直接进入第8步，否则进入第2步。
如果没有父类加载器，则要么Parent是根类加载器，要么本身就是根类加载器，则跳到第4步，如果父类加载器存在，则进入第3步。
请求使用父类加载器去载入目标类，如果载入成功则跳至第8步，否则接着执行第5步。
请求使用根类加载器去载入目标类，如果载入成功则跳至第8步，否则跳至第7步。
当前类加载器尝试寻找Class文件，如果找到则执行第6步，如果找不到则执行第7步。
从文件中载入Class，成功后跳至第8步。
抛出ClassNotFountException异常。
返回对应的java.lang.Class对象。

四、类加载机制：

1.JVM的类加载机制主要有如下3种。

全盘负责：所谓全盘负责，就是当一个类加载器负责加载某个Class时，该Class所依赖和引用其他Class也将由该类加载器负责载入，除非显示使用另外一个类加载器来载入。
双亲委派：所谓的双亲委派，则是先让父类加载器试图加载该Class，只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类。通俗的讲，就是某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父加载器，依次递归，如果父加载器可以完成类加载任务，就成功返回；只有父加载器无法完成此加载任务时，才自己去加载。
缓存机制。缓存机制将会保证所有加载过的Class都会被缓存，当程序中需要使用某个Class时，类加载器先从缓存区中搜寻该Class，只有当缓存区中不存在该Class对象时，系统才会读取该类对应的二进制数据，并将其转换成Class对象，存入缓冲区中。这就是为很么修改了Class后，必须重新启动JVM，程序所做的修改才会生效的原因。

2双亲委派机制：

双亲委派机制，其工作原理的是，如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行，如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器，如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式，即每个儿子都很懒，每次有活就丢给父亲去干，直到父亲说这件事我也干不了时，儿子自己才想办法去完成。

双亲委派机制的优势：采用双亲委派模式的是好处是

Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关可以避免类的重复加载，当父亲已经加载了该类时，就没有必要ClassLoader再加载一次。
其次是考虑到安全因素，java核心api中定义类型不会被随意替换，假设通过网络传递一个名为java.lang.Integer的类，通过双亲委托模式传递到启动类加载器，而启动类加载器在核心Java API发现这个名字的类，发现该类已被加载，并不会重新加载网络传递的过来的java.lang.Integer，而直接返回已加载过的Integer.class，这样便可以防止核心API库被随意篡改。