JVM类加载入门

淡淡的烟草味﹌ 2022-03-01 10:38 145阅读 0赞

### JVM类加载入门 ###

*   *  一、类加载的过程：
     *   *  加载 ---> 连接 ---> 初始化
     *  二、类加载器ClassLoader
     *   *  ①什么是类加载器？
         *  ②类加载器种类：
         *  ③双亲委派模型
         *   *  介绍：
             *  优点：
             *  弊端：
             *  突破双亲委派模式：

类加载机制

## 一、类加载的过程： ##

### 加载 —> 连接 —> 初始化 ###

**优点**：不同层次的类可以由不同的ClassCloader加载，从而进行划分，有助于系统模块化的设计

**加载**：通过类的全名(com.edu.demp.class)来获取类的二进制数据流。解析类的二进制流为方法区内的数据结构。创建java.lang.class实例表示该对象。

**连接**：①验证：格式验证(魔数检查、版本检查、长度检查)，语义检查(是否有父类、抽象方法是否有实现等)，字节码验证(跳转指令是否指向正确位置、操作数类型是否合理)和符号引用验证(符号引用的直接引用是否存在)  
②准备：准备阶段JVM会 为这个类分配相应的内存空间，并为常量(int,byte,long,short,float,double,boolean,char)设置初始值。  
③解析：将类、接口、字段和方法的符号引用转为直接引用。

**初始化**：在准备阶段变量已经被赋过一次系统要求的初始值，在初始化阶段则是根据代码中的逻辑去初始化类变量和其他资源。  
初始化的条件：①创建一个类的实例时，例如new，反射，克隆，反序列化。②调用类的静态方法时。③使用类或接口的静态字段时(final常量除外)。③初始化子类时，要求先初始化父类。④JVM启动包含Main方法的启动类时

## 二、类加载器ClassLoader ##

### ①什么是类加载器？ ###

类加载器是在类加载机制的加载阶段，主要作用是从系统外部获得class二进制数据流。

能否在加载类的时候，对类的字节码进行修改答案：可以，使用Java探针技术

### ②类加载器种类： ###

A. 启动类加载器，BootStrap ClassLoader，负责加载系统核心类，是虚拟机自身的一部分，加载JAVA\_HOME\\lib路径下的核心类或-XBootClasspath参数指定路径下的jar包。启动类加载器无法被java程序直接引用，需要指定它加载的话则直接用Null代替即可。

B. 扩展类加载器，Extension ClassLoader，加载JAVA\_HOME\\lib\\ext目录中的或者java.ext.dirs系统变量指定 的路径中的所有类库，开发者可以直接使用扩展类加载器。

C. 应用程序类加载器（系统类加载器）：负责加载用户类路径classpath上所指定的类库，如果程序中没有自定义过自己的类加载器，一般情况下这个就是程序中的默认类加载器。

### ③双亲委派模型 ###

#### 介绍： ####

在类加载时系统会先判断当前类是否已经加载，如果已经被加载则直接返回可用类，如果还没被加载则会先请求双亲加载（一层一层往上）如果父类加载器都无法完成这个加载（搜索范围内没有找到所需的类对应） ，那么子类尝试自己加载。

#### 优点： ####

①避免重复加载，加载类请求到来时会先从缓存中查找该类对象，如果存在则直接返回。②提高安全性和稳定性  
例1.如自己编写了一个java.lang.Object类，进行类加载时最后都会到达启动类加载器加载，启动类加载器在搜索范围内找到了java.lang.Object类并且已经在系统启动时已经被加载，那么就会直接返回加载完毕的正确java.lang.Object类，这样可以避免核心API被随意篡改。  
例2.如果我们自己在classpath下定义了一个java.lang.demo类，显然这个类不存在系统类库的java.lang路径中，经过双亲委托模式到达顶层启动类加载器，扫描范围内没有该类，那么将反向委托给子类的加载器，最后回到应用类加载器中加载，但是因为java.lang是核心API包访问需要权限，强制加载会报出异常。  
注意：判断类是否加载时路线是单向的，顶层的加载器不会去询问底层。  
补充：判断两个类是否相同？ 在JVM中两个class对象是否为同一个类对象的两个必要条件：①类的完整名必须一致（包括包名） ②加载这个类的ClassLoader对象必须相同

#### 弊端： ####

上层的ClassLoader的代码无法访问到底层的ClassLoader。例如SPI（service provider interface）机制，将服务接口和服务实现分离以达到解耦，提升程序可扩展性的机制。典型的JDBC，各大厂商会根据jdk核心包java.sql.Driver提供的接口规范开发各自的驱动实现逻辑。但是在双亲委派模型中顶层的抽象类需要加载子类的实现是无法完成的。那么如何解决呢？

#### 突破双亲委派模式： ####

①为了解决弊端中描述的问题，Java中加入了线程上下文类加载器，它通过java.lang.Thread类中的setContextClassLoader()设置加载器，如果创建线程时没有设置则从父线程中继承一个，如果全局都没设置则默认为应用程序类加载器。这样通过Thread.getContextClassLoader()就可以获得所需的类加载器，再又该加载器去加载。

②重写loadClass()方法也会破坏双亲委派模型。在双亲委派模型出现之前就存在用户自定义类的加载器，在双亲委派模型出现后其核心代码在于loadClass()中，为了防止被破坏，添加了新的findClass()方法便于重写。

③OSGI实现热部署也是它自定义了类的加载器机制。  
补充：OSGI。它是一种模块化标准，在不同的功能模块中做到分离解耦，也就是说在服务器运行时将某一部分功能取下来其他功能也不会收到影响，并且不需要重新启动服务器，在遇到问题时可以在不关闭整个系统的情况下拆卸某一项功能进行改进。（结合JAVA11）