阅读 86

从零了解JVM,先来看看类加载机制吧!

hello 我是宝哥,今天我们来聊聊JVM的类加载过程

要搞清楚JVM,首先要搞清楚几个问题:

  • jvm起到什么作用?
  • 怎么加载class文件的?
  • 加载类时会重复吗?顺序是什么样的?

说到jvm 那么不得不提类的加载过程.我们先来了解下类是如何被一步一步加载到jvm的

类的加载过程

我们先笼统的了解一下类加载的整个过程:

如上图所示,Java源代码文件(.java后缀)会被Java编译器编译为字节码文件(.class后缀)

然后由JVM中的类加载器加载各个类的字节码文件,加载完毕之后,交由JVM执行引擎执行。

在整个程序执行过程中,JVM用一段空间来存储程序执行期间需要用到的数据和相关信息,被称作为Runtime Data Area(运行时数据区),也就是我们常说的JVM内存。

此时,我们可以片面的理解为:JVM为我们的class字节码提供了加载,存储,执行的环境. (jvm是java可跨平台运行的基石,因为不同的系统有不同的jvm实现,都可以加载.class字节码文件)

Java的类加载机制

那么ClassLoader都做了什么呢?

我们先来看看 类加载机制的定义:

虚拟机把描述类的数据从 Class 文件加载到内存,并对数据进行校验、转换解析和初始化,最终形成可以被虚拟机直接使用的 Java 类型,这就是虚拟机的类加载机制

这里有几个阶段比较重要: 1.加载 2.连接 3.初始化

根据这3个阶段,我们可以剖析出,类的生命周期:

类的生命周期

  • 加载: 加载类的二进制字节流,并且将静态存储结构转化为方法区的运行时数据结构,然后在内存中生成一个代表此类的Class对象,作为方法区这个类各种数据的访问入口

  • 验证: 验证是在连接(Linking)部分的第一步,验证的目的是验证Class文件中的字节流符合当前虚拟机的要求,保证不会危害虚拟机.

  • 准备: 为类变量分配内存,并且设置类变量初始值,此时这此类变量所使用的内存都是在方法区中进行分配.

  • 解析: 解析是将符号引用替换为直接引用,解析动作针对类或接口,字段,类或接口的方法进行解析。

  • 初始化:初始化类或接口并且执行类或接口的初始化方法,此时,它的生命周期就开始了

    • 初始化的时机:
      • 虚拟机规范规定了有且只有 5 种情况必须立即对类进行初始化
      • 1.遇到new、getstatic 和 putstatic 或 invokestatic 这4条字节码指令时,如果类没有进行过初始化,则需要先触发其初始化。对应场景是:使用 new 实例化对象、读取或设置一个类的静态字段(被 final 修饰、已在编译期把结果放入常量池的静态字段除外)、以及调用一个类的静态方法。
      • 2.对类进行反射调用的时候,如果类没有进行过初始化,则需要先触发其初始化。
      • 3.当初始化类的父类还没有进行过初始化,则需要先触发其父类的初始化。(而一个接口在初始化时,并不要求其父接口全部都完成了初始化)
      • 4.虚拟机启动时,用户需要指定一个要执行的主类(包含 main() 方法的那个类),虚拟机会先初始化这个主类。
      • 5.当使用 JDK 1.7 的动态语言支持时,如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果 REF_getStatic、REF_putStatic、REF_invokeStatic 的方法句柄,并且这个方法句柄所对应的类没有进行过初始化,则需要先触发其初始化。
  • 使用: 此时我们可以通过new关键字,创建实例对象.顺带一提,一个Class对象总是会引用它的类加载器。调用Class对象的getClassLoader()方法,就能获得它的类加载器。由此可见,Class实例和加载它的加载器之间为双向关联关系。

  • 卸载: 当类不再被引用或被垃圾回收器标记为已死对象时,将会被回收,但是Java虚拟机本身会始终引用类加载器,而这些类加载器则会始终引用它们所加载的类的Class对象,因此这些Class对象始终是可触及的,也就是说jvm自带的类加载器所加载的类,在虚拟机还没有退出时,始终不会被卸载,当然也有特例 如:我们自己定义的类加载器的类是可以被卸载的.

ClassLoader 类加载器

类的唯一性

任意一个类,都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性

这句定义怎么理解呢?

两个类来源于同一个 Class 文件,被同一个虚拟机加载,但是加载它们的类加载器不同,那这两个类也不相等

那有的小伙伴就有疑惑了,还有很多类加载器吗? emm..那加载的顺序呢?会不会重复加载了?

别急,我们了解下双亲委派原则.

双亲委派原则

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

这里举例几个面试会问的classloader职责:

  • Bootstrap ClassLoader:根类加载器,负责加载java的核心类,它不是java.lang.ClassLoader的子类,而是由JVM自身实现;
  • Extension ClassLoader:扩展类加载器,扩展类加载器的加载路径是JDK目录下jre/lib/ext,扩展类的getParent()方法返回null,实际上扩展类加载器的父类加载器是根加载器,只是根加载器并不是Java实现的;
  • System ClassLoader:系统(应用)类加载器,它负责在JVM启动时加载来自java命令的-classpath选项、java.class.path系统属性或CLASSPATH环境变量所指定的jar包和类路径。程序可以通过getSystemClassLoader()来获取系统类加载器;
  • User Define ClassLoader: 用户自定义的classloader,自定义的加载器必须继承ClassLoader。

它们的加载顺序: show me the code:

// 代码摘自《深入理解Java虚拟机》
    protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
        // 首先,检查请求的类是否已经被加载过了,同时也解决了小伙伴的疑虑
        Class c = findLoadedClass(name);
        if (c == null) {
            try {
                if (parent != null) {
                    c = parent.loadClass(name, false);
                } else {
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
            // 如果父类加载器抛出ClassNotFoundException
            // 说明父类加载器无法完成加载请求
            }
            if (c == null) {
                // 在父类加载器无法加载的时候
                // 再调用本身的findClass方法来进行类加载
                c = findClass(name);
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
复制代码

那么我们不禁要思考一下为何要用这种原则有何优点?

  • 1,一个当然是避免重复加载,提升性能

  • 2,避免了核心类被用户篡改(例如我在用户自定义的classloader中加载一个String类去覆盖自带的String类,由于先让父类加载,我定义的顺序在后.不会出现覆盖成功的问题)

这里有几个点小伙伴需要注意,不然要被面试官吊打了:

  1. 类加载器之间的父子关系不会以继承的关系来实现,他们虽然都继承于抽象类java.lang.ClassLoader但是他们的关系是组合关系,使用组合关系复用父类的加载器.
  2. Bootstrap 类加载器是用 C++ 实现的,不继承于抽象类java.lang.ClassLoader,它是虚拟机自身的一部分,如果获取它的对象,将会返回 null;
  3. jvm自带的类加载器所加载的类,在虚拟机还没有退出时,始终不会被卸载,我们自己定义的类加载器,加载的类是可以被卸载的.

破坏双亲委派原则

当然类加载器的双亲委派原则是可以被破坏的,破坏它是由于双亲委派模型自身缺陷导致,他没有办法解决用户基础类又要重新调用户类的代码。为了解决这个问题就有了线程上下文加载器,例如JNDI、JDBC、JCE等

举个Tomcat的例子:

每个Tomcat的webappClassLoader加载自己的目录下的class文件,不会传递给父类加载器。tomcat之所以造了一堆自己的classloader,大致是出于下面三个原因:

  • 对于各个 webapp中的 class和 lib,需要相互隔离,不能出现一个应用中加载的类库会影响另一个应用的情况,而对于许多应用,需要有共享的lib以便不浪费资源。
  • 与 jvm一样的安全性问题。使用单独的 classloader去装载 tomcat自身的类库,以免其他恶意或无意的破坏;
  • 热部署。相信大家一定为 tomcat修改文件不用重启就自动重新装载类库而惊叹吧。

破坏双亲委派的方式

双亲委派机制原则在loadclass方法中。 只需要绕开loadclass方法中即可。

  1. 自定义类加载器 ,重写loadclass方法

  2. 使用SPI机制绕开loadclass 方法。当前线程设定关联类加载器

关于SPI在我另外一篇文章mp.weixin.qq.com/s/2UFHJ_i09…


讲了那么久的加载,此时我们才刚刚一只脚踏进JVM的大门,后面我们将分析JVM运行时数据区.大家持续关注java宝典公众号,我们下章再聊

最近我创建了一个微信-学习群,有热爱学习的小伙伴可以进群讨论

欢迎关注公众号:java宝典 领取更多教程福利

文章分类
后端
文章标签