虚拟机类加载机制

五步：加载，验证，准备，解析，初始化

（其中只有解析的顺序不一定，它可以在初始化之后，这是为了支持Java的动态绑定）

 

动态绑定？

 

类何时"初始化"？

有且只有四种情况必须立即对类"初始化"：
a：遇到new，getstatic，putstatic，invokestatic四条字节码指令时
b：使用java.lang.reflect包的方法对类进行反射调用的时候
c：初始化一个类的时候，如果其父类还没初始化，则先触发父类的初始化
d：虚拟机启动时，用户需要指定一个主类（包含mian()方法的类），虚拟机初始化主类

 

加载

在加载阶段，虚拟机需要完成三件事：
a：通过一个类的全限定名来获取定义此类的二进制字节流
b：将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
c：在java heap中生产一个代表这个类的java.lang.Class对象，作为方法区这些数据的访问入口
（虚拟机规范的这三点并不具体，例如a，并没有指出二进制流一定要从一个Class文件中获取。从zip包中读取，如现在的jar、war；从网络中获取；运行时生成，如动态代理；数据库中读取等。）

 

验证

验证阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
检验过程：
a：文件格式验证（如是否以魔数0xCAFEBABE开头）
b：元数据验证（对字节码描述的信息进行语义分析）
c：字节码验证（这一过程比较复杂，主要是保证虚拟机的安全）
d：符号引用验证（确保解析动作能正常执行）

 

准备

准备阶段是正式为类变量（被static修饰）分配内存并设置类变量初始值（数据类型的零值）的阶段，这些内存都将在方法区中进行分配（实例变量在对象实例化时随着对象一起分配在heap中）。

 

解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。
符号引用？
直接引用？

 

初始化

真正开始执行类中定义的java程序代码（字节码）。

 

类加载器

虚拟机设计团队把加载阶段中的"通过一个类的全限定名来获取定义此类的二进制字节流"这个动作放到java虚拟机外部去实现，实现这个动作的代码模块称为"类加载器"。

 

类与类加载器

对于任意一个类，都需要由加载它的类加载器和这个类本身一同确定其在java虚拟机中的唯一性。
（如果两个类来源于同一个Class文件，只要加载他们的类加载器不同，那么这两个类就必定不相等）

 

双亲委派模型

对于虚拟机：只存在两种不同的类加载器，一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机自身的一部分；另一种就是所有其他的类加载器，这些类加载器由java语言实现，独立于虚拟机外部，并且全部继承自抽象类java.lang.ClassLoader。

对于开发者：类加载器可以划分更细致一些
a：Bootstrap ClassLoader，加载<JAVA_HOME>/lib目录中被虚拟机识别的（仅按文件名识别如rt.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库到虚拟机内存中。Bootstrap ClassLoader无法被java程序直接引用。
b：Extension ClassLoader，这个加载器由sun.misc.Launcher$ExtClassLoader实现。它负责加载<JAVA_HOME>/lib/ext目录中的所有类库，开发者可以直接使用扩展类加载器。
c：Application ClassLoader（默认类加载器），这个加载器由sun.misc.Launcher$AppClassLoader实现。它负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用应用程序类加载器。

双亲委派模型要求除了顶层的Bootstrap ClassLoader，其余的类加载器都应当有自己的父类加载器。
注意，这里类加载器之间的父子关系不是用继承来实现的，而都是使用组合关系来复用父类加载器的代码。

工作过程：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都会传到顶层的启动类加载器中，只有当父类加载器无法加载（它搜索的范围中没有找到所需要的类）这个请求时，子类加载器才尝试自己去加载。

转载于:https://www.cnblogs.com/wting1123/p/11460364.html