6.虚拟机类加载机制

Posted 2020-10-02

1.什么是类加载

把描述类的数据从class（这里的class不仅仅只class文件，任何方式都可以，比如说jar包，反射等）文件加载到内存，并对数据进行校验，转换解析和初始换，最终形成可以被虚拟机直接说使用的java类型。

2.java虚拟机中类加载的全过程

加载（这个加载指的是类加载的一个阶段，不是类加载），验证，准备，初始化和卸载这5个阶段的顺序是确定的，但是解析阶段则不一定，这是为了支持java语言的运行时绑定。

什么情况下需要开始类加载过程的第一个阶段：加载？

1. 创建类的实例，访问类的静态变量，访问类的静态方法，如果之前没有进行过初始化，则要先触发初始化。

2. 反射 如(java.lang.reflect报的方法： Class.forName("my.xyz.Test") )

3. 当初始化一个类时，发现其父类还未初始化，则先出发父类的初始化

4. 虚拟机启动时，定义了main()方法的那个类先初始化

 2.1加载：

 1、 通过一个类的全限定名来获取定义此类的二进制字节流。（可以从任何地方获取，并不一定要是class文件）

       2、 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。

       3、 在Java堆中生成一个代表这个类的java.lang.Class对象，作为方法区这些数据的访问入口。

2.2.验证：

验证输入的字节流是否合法

2.3.准备阶段：

正式为类变量分配内存并设置类变量初始值的阶段（如int型的变量初始值为0等，final特殊），所使用的内存在方法区中分配。

2.4.解析：

将虚拟机常量池内的符号引用替换为直接引用（大概意思就是将“描述地址的唯一标识”转化为真正的指针）

2.5.初始化：

类加载的最后一步，也就是执行类构造器方法的过程

3.类加载器

类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到java虚拟机外部实现，一边应用程序自己决定如何去获取所需要的类。实现这个动作的代码模块称为“类加载器”。

3.1.类与类加载器

对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在java虚拟机中的唯一性，也就是比较两个类“相等”，只有在这两个类是由同一个类加载器加载的前提才有意义

3.2.双亲委派模型

类加载器类型：

从虚拟机角度来讲：启动类加载器（bootstrap classloader）和其他实现了java.lang.classloader的类加载器。

从程序员角度看：

1. 启动类加载器（Bootstrap ClassLoader）：用于加载Java API，加载<JAVA_HOME>\lib目录下的类库。

2. 扩展类加载类（Extension ClassLoader）：由sun.misc.Launcher$ExtClassLoader实现，用于加载<JAVA_HOME>\lib\ext目录下或者被java.ext.dirs系统变量指定路径下的类库。

3. 应用程序类加载器（Application ClassLoader）：也成为系统类加载器，由sun.misc.Launcher$AppClassLoader实现，用于加载用户类路径（ClassPath）上所指定的类库。

4. 自定义类加载器：实现用户自定义加载逻辑。

下图这种关系被称为：双亲委派模型

双亲委派模型要求除了顶层的启动类加载器之外，其余的类加载器都应该有自己的父类加载器。

各个类加载器之间是组合关系，并非继承关系。

双亲委派模型的工作过程：

当一个类加载器收到类加载的请求，它将这个加载请求委派给父类加载器进行加载，每一层加载器都是如此，最终，所有的请求都会传送到启动类加载器中。只有当父类加载器自己无法完成加载请求时，子类加载器才会尝试自己加载。

优点：

双亲委派模型可以确保安全性，可以保证所有的Java类库都是由启动类加载器加载。如用户编写的java.lang.Object，加载请求传递到启动类加载器，启动类加载的是系统中的Object对象，而用户编写的java.lang.Object不会被加载。如用户编写的java.lang.virus类，加载请求传递到启动类加载器，启动类加载器发现virus类并不是核心Java类，无法进行加载，将会由具体的子类加载器进行加载，而经过不同加载器进行加载的类是无法访问彼此的。由不同加载器加载的类处于不同的运行时包。所有的访问权限都是基于同一个运行时包而言的。　

3.3.破坏双亲委派模型

第一次“被破坏”发生在双亲委派模型出现之前。亲委派模型在JDK 1.2 之后才被引入，类加载器和抽象类Java. lang. ClassLoader 则在JDK 1 .0 时代就已经存在，对已经存在的用户自定义类加载器的实现代码， Java 设计者们引入双亲委派模型时做出了一些妥协。 

第二次“被破坏”是由这个模型自身的缺陷所导致的，双亲委派很好地解决了各个类加载器的基础类的统一问题（越基础的类由越上层的类加载器进行加载），基础类之所以被称为“基础”，是因为它们总是作为被用户代码词用的API。但是基础类有时又要调用用户代码，如JNDI。此时就引入了线程上下文类加器。 

第三次“被破坏”是由于用户对程序动态性的追求而导致的。代码热替换（HotSwap）、模块热部署（Hot Deployment）等 

本文出自 “13165699” 博客，请务必保留此出处http://13175699.blog.51cto.com/13165699/1955128