jvm-类加载器子系统

jvm-类加载器子系统

起男 283 2022-11-25

jvm-类加载器子系统

  • 类加载器子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识
  • ClassLoader只负责class文件的加载，至于它是否可以运行，则由ExecutionEngine（执行引擎）决定
  • 加载的类型存放于一块称为方法区的内存空间。除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是Class文件中常量池部分的内存映射）

类加载的过程

加载

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

连接

验证（verify）

  • 目的确保Class文件的字节流中包含信息符合当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全
  • 主要包括四种验证：文件格式验证、元数据验证、字节码验证、符号引用验证

准备（prepare）

  • 为类变量分配内存并且设置该类变量的默认初始值
  • 这里不包含final修饰的static，因为final在编译的时候就会分配了，准备阶段会显示初始化
  • 这里不会为实例变量分配初始值，类变量会分配在方法区中，而实例变量是会随着对象一起分配到java堆中

解析（resolve）

  • 将常量池内的符号引用转换为直接引用的过程
  • 事实上，解析操作往往会伴随着jvm在执行完初始化之后再执行
  • 符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在《java虚拟机规范》的class文件格式中。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄
  • 解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等

初始化

  • 初始化阶段就是执行类构造器方法<clinit>()的过程
  • 此方法不需要定义，是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来
  • <clinit>()中指令按照语句在源文件中出现的顺序执行
  • <clinit>()不同于类的构造器。（构造器是虚拟机视角下的<init>()）
  • 若该类具有父类，jvm会保证子类的<clinit>()执行前，父类的<clinit>()已经执行完毕
  • 虚拟机必须保证一个类的<clinit>()方法在多线程下被同步加锁

类加载器

classLoader是java的核心组件，所有的Class都是由ClassLoader进行加载的，ClassLoader负责通过各种方式将Class信息的二进制数据流读入jvm内部，转换为一个与目标类对应的java.lang.Class对象实例。然后交给java虚拟机进行连接、初始化等操作。因此，ClassLoader在整个装载阶段，只能影响到类的加载，而无法通过ClassLoader去改变类的连接和初始化行为。至于类是否可用运行，则由ExecutionEngine决定

  • jvm支持两种类型的类加载器，分别为引导类加载器（Bootstrap ClassLoader）和自定义类加载器（User-Defined ClassLoader）
  • 从概念上来讲，自定义类加载器一般指的是程序中由开发人员定义的一类类加载器，但是java虚拟机规范没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器

类的加载器的关系是包含关系，不是上下级关系，也不是子父类的继承关系

显式加载和隐式加载

class文件的显式加载和隐式加载的方式是指jvm加载class文件到内存的方式

  • 显式加载：在代码中通过调用ClassLoader加载class对象，如直接使用Class.forName()或者this.getClass().getClassLoader().loadClass()加载class对象
  • 隐式加载：不直接在代码中调用ClassLoader的方法进行加载class对象，而是通过虚拟机自动加载到内存中，如在加载某个类的class文件时，该类的class文件中引用了另外一个类的对象，此时额外引用的类将通过jvm自动加载到内存中

数组

  • 数组使用的类加载器是由数组的元素决定的（基本数据类型不需要类加载器）

引导类加载器Bootstrap ClassLoader

  • 这个类加载器使用c/c++语言实现，嵌套在jvm内部
  • 它用来加载java的核心库（JAVA_HOME/jre/lib/rt.jar、resources.jar或sun.boot.class.path路径下的内容），用于提供jvm自身需要的类（可以通过Launcher.getBootstrapClassPath().getURLs()查看）
  • 并不继承自java.lang.ClassLoader，没用父加载器
  • 加载扩展类和应用类加载器，并指定他们的父加载器
  • 出于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类

扩展类加载器Extension ClassLoader

  • java语言编写，由sun.misc.Launcher$ExtClassLoader实现
  • 派生于ClassLoader类
  • 父类加载器为引导类加载器
  • 从java.ext.dirs系统属性所指定的目录中加载类库，或从jdk的安装目录的jre/lib/ext子目录（扩展目录）下加载类库。如果用户创建的jar放在此目录下，也会自动由扩展类加载器加载

应用类加载器AppClassLoader

  • java语言编写，由sun.misc.Launcher$AppClassLoader实现
  • 派生于ClassLoader类
  • 父类加载器为扩展类加载器
  • 它负责加载环境变量classpath或系统属性java.class.path指定路线下的类库
  • 该类加载器是程序中默认的类加载器，一般来说，java应用的类都是由它来完成加载
  • 通过ClassLoader#getSystemClassLoader()方法可以获取到该类加载器

自定义类加载器

可以通过继承抽象类java.lang.ClassLoader类，的方式实现自定义类加载器（如果没有太复杂的需求，可以直接继承URLClassLoader）

在jdk1.2之前，在自定义类加载器时，总会去继承ClassLoader类的方式，实现自己的类加载器，但是在jdk1.2之后，已不再建议覆盖loadClass()方法（会破坏双亲委派模型），而是建议把自定义的类加载逻辑写在findClass()方法中

如果没用太过于复杂的需求，可以直接继承URLClassLoader类，这样就可以避免自己去编写findClass()方法及其获取字节码流的方式

应用场景：

  • 隔离加载类
  • 修改类加载的方式
  • 扩展加载源
  • 防止源码泄露

案例

public class MyClassLoader extends ClassLoader {

    private String byteCodePath;

    public MyClassLoader(ClassLoader parent, String byteCodePath) {
        super(parent);
        this.byteCodePath = byteCodePath;
    }

    public MyClassLoader(String byteCodePath) {
        this.byteCodePath = byteCodePath;
    }

    @Override
    protected Class<?> findClass(String name) {
        //获取完整路径
        String fileName = byteCodePath + name + ".class";
        //获取输入输出流
        try (BufferedInputStream bis = new BufferedInputStream(new FileInputStream(fileName));
             ByteArrayOutputStream baos = new ByteArrayOutputStream();){
            //读入写出数据
            int len;
            byte[] data = new byte[1024];
            while ((len = bis.read(data))!=-1){
                baos.write(data,0,len);
            }
            //获取内存中的完整的字节数组数据
            byte[] byteCodes = baos.toByteArray();
            //调用defineClass将字节数组的数据转换为Class实例
            return defineClass(null, byteCodes, 0, byteCodes.length);
        }catch (Exception e){
            e.printStackTrace();
        }
        return null;
    }
}

ClassLoader类

ClassLoader类，它是一个抽象类，其后所有的类加载器都继承自ClassLoader（不包括引导类加载器）

方法

方法 描述
getParent 返回该类加载器的父类加载器
loadClass 加载指定名称的类(双亲委派的实现)
findClass 查找指定名称的类
findLoadedClass 查找指定名称的已经被加载过的类
defineClass 把字节数字中的内容转为一个java类。内部的preDefineClass()方法，该方法会包含核心api安全
resolveClass 连接指定的一个java类

获取途径

  1. 获取当前类的ClassLoader：clazz.getClassLoader()
  2. 获取当前线程上下文的ClassLoader：Thread.currentThread().getContextClassLoader()
  3. 获取系统的ClassLoader：ClassLoader.getSystemClassLoader()
  4. 获取调用者的ClassLoader：DriverManager.getCallerClassLoader()

双亲委派

jdk1.2引入了双亲委派模型

java虚拟机对class文件采用的是按需加载的方式，也就是说当需要使用该类时才会将它的class文件加载到内存生成Class对象。而且加载某个类的class文件时，java虚拟机采用的是双亲委派模式，即把请求交由父类处理，它是一种任务委派模式

工作原理

  1. 如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行
  2. 如果父类加载器还存在父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器
  3. 如果父类加载器可以完成类的加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派

作用

  • 避免类的重复加载，确保一个类的全局唯一
  • 保护程序安全，防止核心api被篡改

缺点

  • 父类加载器无法访问底层的类加载器。如果要需要访问，需要借助于线程上下文类加载器（是一个应用类加载器）完成，比如jndi、jdbc、jce、jaxb和jbi等

java虚拟机规范并没有明确要求类加载器的加载机制一定要使用双亲委派模型，只是建议采用这种方式而已。比如tomcat中，类加载器就是先自行加载，加载失败时才会交给父类加载器去执行

沙箱安全机制

java安全模型的核心就是java沙箱（sandbox）。沙箱是一个限制程序运行的环境

沙箱机制就是将java代码限定在jvm特定的运行范围中，并且严格限制对本地系统资源访问。通过这样的措施来保证对代码的有限隔离，防止对本地系统造成破坏

沙箱机制限制系统资源访问，包括cpu、内存、文件系统和网络等。不同级别的沙箱对这些资源访问的限制也不一样

所有的java程序运行都可以指定沙箱，可以定制安全策略

  • jdk1.0时期：远程代码不可以访问本地资源
  • jdk1.1时期：部分受信任的远程代码可以访问本地资源
  • jdk1.2时期：增加了权限组的概念，对每个组单独设置权限
  • jdk1.6时期：引入了域的概念。虚拟机会把所有代码加载到不同的系统域和应用域（应用域里有多个权限组）。系统域专门负责于关键资源交互，应用域通过系统域来对各种资源进行访问

作用：

  • 保证程序安全
  • 保护java原生的jdk代码

jdk9

为了保证兼容性，jdk9没有从根本上改变三层类加载架构和双亲委派模型，但为了模块化系统的顺利运行，仍然发生了一些值得注意的变动

  • 扩展机制被移除，扩展类加载器由于向后兼容性的原因被保留，不过被重命名为平台类加载器（platform classloader）。可以通过ClassLoader的新方法getPlatformClassLoader()获取

    jdk9时基于模块化进行构建（原来的rt.jar和tools.jar拆分为多个jmod文件），其中的java类库天然就可满足可扩展，自然无需保留\lib\ext目录

  • 平台类加载器和应用类加载器不再继承于java.net.URLClassLoader。改为jdk.internal.loader.BuiltinClassLoader

  • jdk9中类加载器有了名称，在构造中指定，通过getName()获取，平台类加载器是platform、应用类加载器是app

  • 启动类加载器现在是jvm内部和java类库共同实现的类加载器（以前是c++），但为了与之前代码兼容，在获取启动类加载器的场景时仍然返回null，而不是BootClassLoader

  • 双亲委派也发生了变化，在委派给父加载器之前，先判断该类是否能归属到某一系统模块中，如果可以找到归属关系，就优先委派给负责那个模块的加载器完成加载

jvm