0%

JVM——类加载器子系统

Snipaste_2020-11-06_23-02-22

  • 类加载器子系统负责从文件系统或者网络中加载Class文件,class文件在文件开头有特定的文件标识。
  • ClassLoader只负责class文件的加载,至于它是否可以运行,则由执行引擎决定。
  • 加载的类信息存放于一块称为方法去的内存空间,除了类的信息外,方法区中还会存放运行时常量池的信息、字符串字面量和数字常量。
  • sun.misc.Launcher是一个Java虚拟机的应用入口

加载阶段

  • 加载阶段分为3部分:
    1. 通过一个类的全限定名获取定义此类的二进制字节流。
    2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
    3. 在内存中生成一个代表这个类的java.lang.Class对象,作为方法区这个类的各种数据访问入口。

链接阶段

  • 链接阶段分为3部分:
    1. 验证:在于确保Class文件的字节流中包含信息符合当前虚拟机的要求,保证被加载类的正确性,不会危害到虚拟机。主要包括四种验证:文件格式验证、元数据验证、字节码验证、符号引用验证。
    2. 准备:为变量分配内存并且设置该类变量的默认初始值,即0。这里的初始化不包含final修饰的static,因为final在编译的时候就已经分配了。不会为实例变量分配初始化。
    3. 解析:将常量池中的符号引用转换为直接引用的过程

初始化阶段

  • 初始化阶段就是执行类构造方法<clinit>()的过程,此方法不需要定义,是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。
  • JVM会保证在子类的<clinit>()方法执行前,父类的<clinit>()方法已经执行完毕。
  • JVM必须保证一个类的<clinit>()方法在多线程下被同步加锁。

加载器的类型

  • JVM支持两种类型的类加载器,分别是引导类加载器(BootstrapClassLoader)和自定义加载器
  • 从概念上讲,自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器,但Java虚拟机规范却没有这么定义,而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义加载器。所以ExtensionClassLoader和SystemClassLoader也是自定义加载器,
  • 而最常见的类加载器就只有三个:BootstrapClassLoader(引导加载器)、ExtensionClassLoader(扩展加载器)、SystemClassLoader(系统加载器)
  • 加载器的继承关系如下:其中引导类加载器采用C++语言编写,其他用的是Java

Snipaste_2020-11-07_20-50-56

  • 对于用户自定义类来说,默认使用系统类加载器进行加载;对于Java的核心类库,都是使用引导类来加载的。

引导类加载器(BootstrapClassLoader)

  • 引导类加载器使用C/C++语言实现的,嵌套在JVM内部
  • 它用来加载Java的核心库(rt.jar、resources.jar或sun.boot.class.path路径下的内容),用于提供JVM自身需要的类。
  • 并不继承自java.lang.ClassLoader,没有父类加载器,用于加载扩展类和系统类加载器,并指定为它们的父类加载器
  • 出于安全考虑,引导类加载器只加载包名为java、javax、sun等开头的类。执行getURLs()就可以获取类加载器加载的类库路径。

扩展类加载器(ExtClassLoader)

  • 派生于ClassLoader类,父类为引导类加载器,从java.ext.dirs系统属性所指定的目录中加载类库,或从JDK的安装目录的jre.lib/ext子目录下加载类库。
  • 通过System.getProperty("java.ext.dirs");可以获取扩展类加载器加载的类库路径

系统类加载器(AppClassLoader)

  • 派生于ClassLoader类,父类为扩展类加载器,它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库,一般来说,Java应用的类都是由它来完成加载。
  • 可以通过个getSystemClassLoader()来获取该加载器

用户自定义加载器

  • 在平时项目开发中,类的加载几乎是由上述3中类加载器相互配合执行的,那什么时候需要使用自定义类加载类:
    1. 隔离加载器,当需要多个jar一起整合时,类路径和类名一样,发生冲突的时候就需要隔离
    2. 修改类加载的方式,除了引导类加载器是必须的外,其他都可以自定义
    3. 扩展加载源
    4. 防止源码泄露,自定义加密解密
  • 用户自定义类加载器实现步骤:
    1. 继承ClassLoader类
    2. 把自定义类加载逻辑写在findClass()方法中
    3. 也可以继承URLClassLoader类,这样可以避免自己编写findClass()方法以及获取字节码流。

类加载器中的方法

方法名称 描述
getParent() 返回该类加载器的父类加载器
loadClass(String name) 加载名称为name的类,返回该类的Class对象
findClass(String name) 查找名称为name的类,返回该类的Class对象
findLoadedClass(String name) 查找名称为name的已经被加载过的类,返回该类的Class对象
defineClass(String name, byte[] b, int off, int len) 把字节数组b中的内容转换称一个Java类,返回该类的Class对象
resolveClass(Class<?> c) 连接指定的一个Java类

获取加载器的方法

  1. clazz.getClassLoader()
  2. Thread.currentThread()/getContextClassLoader()
  3. ClassLoader.getSystemClassLoader()

双亲委派机制

  1. 如果一个类加载器收到了一个加载请求,它并不会自己先去加载,而是把这个请求委托给父类的加载器去执行。
  2. 如果父类加载器还存在其父类加载器,则进一步向上委托,直至到达顶层的启动类加载器。
  3. 如果父类加载器可以完成类加载任务,就成功返回,倘若父类加载器无法完成此加载任务,就会返回该子类加载器加载,判断是否能加载就是看该类的路径是否可以被加载器识别。
  • 双亲委派机制的优点:
    1. 避免类的重复加载
    2. 保护程序的安全,防止核心API被随意篡改

注意的点

  • 在JVM中表示两个class对象是否为同一个类存在两个必要条件:
    1. 类的完整类名必须一致,包括包名。
    2. 加载这个类的ClassLoader必须相同。
  • 如果一个类是由用户类加载器加载的,那么JVM会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中;当解析一个类型到另一个类型的引用的时候,JVM需要保证这两个类型的类加载器是相同的。

类的主动使用和被动使用

  • 主动使用:
    1. 创建类的实例(new)
    2. 访问某个类或接口的静态变量,或者堆该静态变量进行赋值
    3. 调用类的静态方法
    4. 反射
    5. 初始化一个类的子类
    6. Java虚拟机启动时被标明为启动类的类
    7. 动态语言支持
  • 被动使用:除了上面七种情况,其他的都是被动使用。
-------------本文结束感谢您的阅读-------------