第七章虚拟机类加载机制

一、概述

虚拟机把字节码文件加载到内存，并对数据进行校验，解析和初始化，最终形成可以被虚拟机直接使用的Java类型。这些动作都是在运行期间完成了，这也是java动态绑定的功能

二、类加载总流程

加载、验证、准备、初始化、卸载这5个阶段顺序是确定的。解析阶段不一定，它在某些情况下可以在初始化阶段后再开始。

2.1 加载

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

第一步获取二进制流，有各种方式：

zip包中读取（jar war等）
运行时动态计算生成，比如动态代理技术
由其他文件生成，比如JSP最后都会翻译成Class。

第三步中生成的Class对象，不一定存在堆内存中，比如HotSpot虚拟机就把它放大了方法去中。

2.2 验证

在进行编译的时候其实已经验证，为什么还需要验证呢？因为比如动态加载，是动态的创建class字节码，所以这个时候不是静态的进行编译，所以对于这些动态生成的class，必须进行验证

2.3 准备

对静态的字段进行默认初始化，比如对static int a；这准备阶段将a=0；
注意这个静态变量使用的内存都将在方法区中进行分配

2.4 解析

这个就是解析出方法或者字段的真正的地址。
解析阶段是虚拟机将常量池中的符号引用转变成直接引用的过程。

2.4 初始化

引入方法
方法：编译器自动收集类中所有的静态赋值动作或者静态代码块中的语句合并产生的。收集的顺序根据静态变量的赋值动作和静态代码块出现的顺序决定的。

三、类的加载器

实现将class文件加载到内存的二进制流的模块叫做类的加载器。
类的加载器可以说是java语言的一项创新，也是Java语言流行的重要原因之一。他最初是为了Java Applet设计的，不过事与愿违，Applet基本已经死掉。但是在类的层次划分、OSGi、热部署、代码加密等领域大放异彩

3.1 类与类的加载器

每一个类加载器都拥有一个独立的类名称空间。一个类是由这类本身和他的类加载器一起确定的

下面这个例子就是证实：

class MyClassLoader extends ClassLoader{@Overridepublic Class<?> loadClass(String name) throws ClassNotFoundException {String fileName = name.substring(name.lastIndexOf(".")+1)+".class";InputStream is = getClass().getResourceAsStream(fileName);if(is == null){return super.loadClass(name);}byte[] b = null;try {b = new byte[is.available()];is.read(b);} catch (IOException e) {throw new ClassNotFoundException(name);}return defineClass(name,b,0,b.length);}
}public class ClassLoaderTest {public static void main(String[] args) throws Exception {ClassLoader myClassLoader = new MyClassLoader();Object obj = myClassLoader.loadClass("com.cisco.learn.jvm.ClassLoaderTest").newInstance();System.out.println(obj.getClass());System.out.println(obj instanceof ClassLoaderTest);//结果为false。 因为类的加载器不一样}
}

3.2 双亲委派模型

类的加载器介绍：

Bootstrap Classloader:加载JAVA_HOME/lib下面被java虚拟机识别的类库（按照名称识别）。
Extension Classloader:加载JAVA_HOME/lib/ext目录中的类库
Application Classloader:负责加载Classpath上面指定的类库，也是我们最经常使用的一个。

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

3.3 破坏双亲委派模型

典型例子1：JDBC的加载
比如需要加载一个类（Connection），首先会寻找父亲取加载，一般会寻找到bootstrap上去加载，但是这个bootstrap加载器上只有该类的接口，真正的实现类是在用户提供的jar包中（比如mysql的jar包）。但是bootstrap类中怎么可能只能去寻找子类的classloader去加载，而且他也找不到也违反了双亲委派。
最后引入了Thread context Classloader机制才解决的，这里就不细说了。

典型例子2：模块热部署技术
OSGI目前我也不太熟悉