【JVM】类加载过程与类加载器的双亲委派模型

最新推荐文章于 2024-08-21 23:35:17 发布

sun_tantan

最新推荐文章于 2024-08-21 23:35:17 发布

阅读量282

点赞数

分类专栏： Java 文章标签： java jvm

本文链接：https://blog.csdn.net/sun_tantan/article/details/118500335

版权

Java 专栏收录该内容

9 篇文章 1 订阅

订阅专栏

概述——类加载机制

Class文件中描述的各种信息，最终都需要加载到虚拟机中才能运用和使用，而虚拟机如何加载这些文件？Class文件中的信息进入到虚拟机后会发生什么变化？

虚拟机的类加载机制：虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型。
这些过程都是在程序运行期间完成的，即运行期类加载。

类加载的过程

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用、卸载。
在这里插入图片描述
其中解析阶段，某些情况下是可以在初始化阶段之后再开始。

1. 加载

JVM加载阶段过程

通过一个类的全限定名来获取定义此类的二进制字节流
获取二进制字节流，并不一定要从一个Class文件获取，例如：
- 从zip包中读取
- 从网络中获取
- 运行时计算生成，这种场景使用最多的就是动态代理技术，在java.lang.reflect.Proxy中就是用了ProxyGenerator.generateProxyClass来为特定接口生成形式为"*Proxy"的代理类的二进制字节流
将这个字节流锁代表的静态存储结构转化为方法区的运行时数据结构
在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
HotSpot而言Class对象比较特殊，虽然是一个对象，但是并没有存放在堆中，而是存放在方法区

数组类型

加载阶段可以由系统提供的引导类加载器完成，也可以由用户的自定义类加载器完成。但是对于数组而言，其本身不通过类加载器创建，它是由JVM直接创建的。

一个数组类创建的过程所遵循的规则：

如果数组的组件类型是引用类型，那就递归采用以上加载过程去加载这个组件类型，数组将在加载该组件类型的类加载器的类名称空间上被标志。（一个类必须与类加载器一起确定唯一性）
如果数组的组件类型不是引用类型，JVM会把数组标记为与引导类加载器关联
数组类的可见性与它的组件类型的可见性一致

2. 验证

目的

验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合虚拟机的要求，并且不会危害虚拟机自身的安全。

检验动作

文件格式验证（Class文件格式规范）
只有经过了这个阶段的建议，字节流才会进入内存的方法区中存储，所以后面三个步骤都是基于方法区的存储结构进行，不会再直接操作字节流
元数据验证（对字节码描述的信息进行语义分析，是Java语言规范）
如类是否有父类、是否寄出了final类、如果不是抽象类，是否实现了所有方法等
字节码验证（确定行为语义合法，对类中方法体语义进行分析）
如保证方法体中的类型转换是有效的
符号引用验证（对常量池中各种符号引用进行匹配性校验）
这一阶段的校验发生在虚拟机将符号引用转化为直接引用（见下节解析阶段）的时候，这个转换动作将在连接的第3阶段——解析阶段发生。通常需要校验下列内容：
- 符号引用中全限定名是否能找到对应的类
- 指定类中是否存在符合方法的字段描述符以及简单名称锁描述的方法和字段
- 符号引用中的类、字段、方法的可见性是否可被当前类访问

3. 准备

目的

准备阶段是正式为类变量分配内存并设置类变量初始值的节点，这些变量所使用的内存都在方法区中进行分配。

仅包括类变量：被static修饰的变量，而不包括实例变量
初始值：基本数据类型的零值，如int类型初始值将为0

4. 解析

目的

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

虚拟机规范中并未规定解析阶段发生的具体时间，只要求了再执行用于操作符号引用的字节码指令之前，先对它们所使用的符号引用进行解析。所以虚拟机可以根据需要判断是在类加载器加载时就对常量池中的符号引用进行解析，还是等到一个符号引用将要被使用前才去解析它。
对于同一个符号引用进行多次解析请求是常见的（除了invokedynamic指令外）虚拟机实现对第一次解析的结果进行缓存。
对于invokedynamic指令，所对应的引用称为动态调用点限定符，用于动态语言支持，动态的含义指必须等到程序实际运行到这条指令的时候，解析动作才能执行。相对的，其余指令都是可以再刚刚完成加载阶段，还没开始执行代码时就进行解析。

符号引用

符号引用以一组符号来描述所引用的目标，引用的目标不一定已加载到内存中，包括下面三类常量：

类和接口的全限定名（如：org/class/Testclass）
字段的名称和描述符（描述字段数据类型）
方法的名称和描述符（方法参数列表和返回值）

直接引用
直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。有了直接引用，那么引用的目标必然已经存在在内存中。

5. 初始化

目的

类的初始化时类加载过程的最后一步，到了初始化阶段，才真正开始执行类中定义的Java程序代码。初始化阶段是执行类构造器< clinit >()方法的过程：

< clinit >()是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的。
< clinit >()方法与实例构造器< init >()不同，它不需要显式地调用父类构造器，虚拟机会保证子类的< clinit >()执行之前，父类的 < clinit >()已经执行完毕，所以虚拟机中第一个被执行的 < clinit >()的类肯定是java.lang.Object。由于父类 < clinit >()先执行，那么父类的静态语句块要优先于子类的变量赋值。
< clinit >()不是必须的，如果一个类或接口没有静态语句块，也没有对类变量赋值操作，编译器可以不为这个类生成此方法。
虚拟机会保证一个类的 < clinit >()方法在多线程环境下正确地加锁、同步。如果多个线程同时去初始化一个类，只有一个线程去执行其 < clinit >()方法，其他线程需要阻塞等待，而且被唤醒后不会再次进入 < clinit >()，因为同一个类加载器下，一个类只会初始化一次。

类的主动引用（触发初始化）

对类进行引用时，如果类没有进行过初始化，则先触发其初始化。

1. 使用new实例化对象

//   new一个对象
public class NewClass { 
	static { 
		System.out.println("NewClass init!");
 	}
 } 
public class Initialization1 { 
	public static void main(String[] args) { 
		new NewClass();
	 }
 }

 // 输出结果  
 NewClass init!

解析：new NewClass() 触发了NewClass类的初始化，初始化的步骤在上一节中定义为：执行类构造器的过程，也就是包括了类变量赋值、静态语句块。所以System.out这句话属于初始化的步骤

2. 调用类的静态成员（除final修饰）和静态方法

public class StaticAttributeClass {

	public static int value = 10;

	public static void staticMethod() {

	}

	static {
		System.out.println("StaticAttributeClass init ...");
	}
}

class Initialization2{
	public static void main(String[] args) {
		int value = StaticAttributeClass.value;
	}
}

class Initialization3{
	public static void main(String[] args) {
		StaticAttributeClass.staticMethod();
	}
}

// 上述两个Main都输出
StaticAttributeClass init ...

3. 使用java.lang.reflect包的方法对类进行反射调用

public class ReflectClass {
	static { 
		System.out.println("ReflectClass init!"); 
	}
} 
public class Initialization4 { 
	public static void main(String[] args) throws Exception { 
		Class classB = Class.forName("jvm.init.ReflectClass"); 
		} 
}

4. 当一个类初始化的时候，如果其父类还没有初始化，则需要先对其父类进行初始化

public class SuperClass {
	static {
		System.out.println("SuperClass init ...");
	}
	public static int value = 10;
}

class SubClass extends SuperClass {
	static {
		System.out.println("SubClass init ...");
	}
}

class Initialization5 {
	public static void main(String[] args) {
		new SubClass();
	}
}

// 输出：
SuperClass init ...
SubClass init ...

5. JVM启动时，用户指定的执行主类（即含有Main的类）

public class MainClass {

	static {
		System.out.println("MainClass init ...");
	}

	public static void main(String[] args) {
		System.out.println("main begin ...");
	}
}

// 输出：
MainClass init ...
main begin ...

类的被动引用（不会触发初始化）

1. 通过子类引用父类的静态字段，不会导致子类初始化

public class SuperClass {
	static {
		System.out.println("SuperClass init ...");
	}
	public static int value = 10;
}

class SubClass extends SuperClass {
	static {
		System.out.println("SubClass init ...");
	}

}

class Initialization1 {
	public static void main(String[] args) {
		int value = SubClass.value;
	}
}

//输出结果
SuperClass init ...

2. 通过数组定义来引用，不会触发此类的初始化

public class ArrayClass {

	static {
		System.out.println("ArrayClass init ...");
	}
}
class Initialization2{
	public static void main(String[] args) {
		ArrayClass[] arrays = new  ArrayClass[10];
	}
}

输出：空

3. final常量的引用

public class ConstClass {
	static {
		System.out.println("ConstClass init ...");
	}

	public static final int value = 10;
}
class Initialization3{
	public static void main(String[] args) {
		int value = ConstClass.value;
	}
}

输出：空

解析：value常量在编译时就被存入了Initialization3类中的常量池中，所以Initialization3的Class文件中实际并没有ConstClass的符号引用。

类加载器的双亲委派模型

类加载器定义

虚拟机设计团队把类加载阶段中的" 通过一个类的全限定名来获取描述此类的二进制字节流 “这个动作放在JVM外部去实现，以便让程序自己决定如何去获取所需要的类，实现这个动作的代码模块成为” 类加载器 "。

类加载器与类的唯一性
对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在JVM中的唯一性，每一个类加载器，都拥有一个独立的类命名空间。
即两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义。

类加载器分类

从JVM角度来讲，只存在两种类加载器：

启动类加载器（由C++实现，是JVM自身的一部分）
所有其他类加载器（由Java实现，独立于虚拟机外部，并都继承自抽象类java.lang.ClassLoader）

从开发人员角度来看，加载器可以划分更细致一些：

启动类加载器 Bootstrap
负责将存放在< JAVA_HOME >\lib目录中的，或者被-Xbootclasspath参数所指定的路径中，虚拟机识别的类库加载到虚拟机中。
由于启动类加载器无法被Java程序直接引用，在需要将加载请求委派给它时，直接使用null替代即可。
扩展类加载器 Extension
负责加载< JAVA_HOME >\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。
应用程序类加载器 Application（系统类加载器）
负责加载用户路径（ClassPath）上所指定的类库，如果应用程序中没有自定义过自己的类加载器，一般情况这个就是程序中默认的类加载器。
自定义类加载器

双亲委派模型

在这里插入图片描述
工作过程

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

好处

Java类随着它的类加载器一起具备了一种带有优先级的层次关系。
如java.lang.Object，存放在rt.jar中由启动类加载器加载，因此Object类在程序的各种类加载器环境中都是同一个类。

实现

protected synchronized Class<?> loadClass(String name,boolean resolve)throws ClassNotFoundException{
    //check the class has been loaded or not
    Class c = findLoadedClass(name);
    if(c == null){
        try{
            if(parent != null){
                c = parent.loadClass(name,false);
            }else{
                c = findBootstrapClassOrNull(name);
            }
        }catch(ClassNotFoundException e){
            //if throws the exception ,the father can not complete the load
        }
        if(c == null){
            c = findClass(name);
        }
    }
    if(resolve){
        resolveClass(c);
    }
    return c;
}

所有的代码都在java.lang.ClassLoader中的loadClass方法中

先检查是否已经被加载过，若没有加载则调用父加载器的loadClass方法。
如父加载器为空则默认使用启动类加载器作为父加载器。
如果父类加载失败，抛出ClassNotFoundException 异常后，再调用自己的findClass方法进行加载

双亲委派模型的打破

双亲委任模型不是一个强制性的约束模型，而是一个建议型的类加载器实现方式。
到目前为止，双亲委派模型有三次大规模被破坏的情况：

在双亲委派模型出现之前—–即JDK1.2发布之前。
我们说，双亲委派模型很好的解决了各个类加载器的基础类的统一问题（越基础的类由越上层的加载器进行加载），基础类之所以称为“基础”，是因为它们总是作为被用户代码调用的API，但没有绝对，如果基础类调用会用户的代码怎么办呢？
这不是没有可能的。一个典型的例子就是JNDI服务，JNDI现在已经是Java的标准服务，它的代码由启动类加载器去加载（在JDK1.3时就放进去的rt.jar）,但它需要调用由独立厂商实现并部署在应用程序的ClassPath下的JNDI接口提供者（SPI， Service Provider Interface）的代码，但启动类加载器不可能“认识“这些代码啊。因为这些类不在rt.jar中，但是启动类加载器又需要加载。怎么办呢？
为了解决这个问题，Java设计团队只好引入了一个不太优雅的设计：
线程上下文类加载器（Thread Context ClassLoader）。
这个类加载器可以通过java.lang.Thread类的setContextClassLoader方法进行设置。如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过多的话，那这个类加载器默认即使应用程序类加载器。
Java中所有涉及SPI的加载动作基本胜都采用这种方式。例如JNDI，JDBC，JCE，JAXB，JBI等。
为了实现热插拔，热部署，模块化，意思是添加一个功能或减去一个功能不用重启，只需要把这模块连同类加载器一起换掉就实现了代码的热替换。

Tomcat的加载模式

Tomcat的类加载机制是违反了双亲委托原则的，对于一些未加载的非基础类(Object,String等)，各个web应用自己的类加载器(WebAppClassLoader)会优先加载，加载不到时再交给commonClassLoader走双亲委托。

以下内容转自：图解Tomcat类加载机制(阿里面试题)
Tomcat为什么要破坏双亲委派模式？
1. 一个web容器可能需要部署两个应用程序，不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求同一个类库在同一个服务器只有一份，因此要保证每个应用程序的类库都是独立的，保证相互隔离。
2. 部署在同一个web容器中相同的类库相同的版本可以共享。否则，如果服务器有10个应用程序，那么要有10份相同的类库加载进虚拟机，这是扯淡的。
3. web容器也有自己依赖的类库，不能于应用程序的类库混淆。基于安全考虑，应该让容器的类库和程序的类库隔离开来。
4. web容器要支持jsp的修改，我们知道，jsp 文件最终也是要编译成class文件才能在虚拟机中运行，但程序运行后修改jsp已经是司空见惯的事情，否则要你何用？所以，web容器需要支持 jsp 修改后不用重启。
Tomcat独有的类加载方式：
1. commonLoader：加载路径：/common/*
  Tomcat最基本的类加载器，加载路径中的class可以被Tomcat容器本身以及各个Webapp访问；
2. catalinaLoader：加载路径：/server/*
  Tomcat容器私有的类加载器，加载路径中的class对于Webapp不可见；
3. sharedLoader：加载路径：/shared/*
  各个Webapp共享的类加载器，加载路径中的class对于所有Webapp可见，但是对于Tomcat容器不可见；
4. WebappClassLoader：加载路径：/WebApp/WEB-INF/*
  各个Webapp私有的类加载器，加载路径中的class只对当前Webapp可见；
5. JspLoader：加载范围仅仅是这个JSP文件所编译出来的那一个.Class文件
  它出现的目的就是为了被丢弃：当Web容器检测到JSP文件被修改时，会替换掉目前的JspLoader的实例，并通过再建立一个新的Jsp类加载器来实现JSP文件的HotSwap功能。
  其中WebApp类加载器和Jsp类加载器通常会存在多个实例，每一个Web应用程序对应一个WebApp类加载器，每一个JSP文件对应一个Jsp类加载器。
Tomcat如何违反了双亲委派？
双亲委派模型要求除了顶层的启动类加载器之外，其余的类加载器都应当由自己的父类加载器加载。很显然，tomcat不是这样实现，tomcat为了实现 隔离性 没有遵守这个约定，每个webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器。
我们扩展出一个问题：如果tomcat 的 Common ClassLoader 想加载 WebApp ClassLoader 中的类，该怎么办？
看了前面的关于破坏双亲委派模型的内容，我们心里有数了，我们可以使用线程上下文类加载器实现，使用线程上下文加载器，可以让父类加载器请求子类加载器去完成类加载的动作。