Jvm 类加载 balabala

本文大量挪用 我竟然被” 双亲委派” 给虐了！-HollisChuang’s Blog
如果可以还请看原文，原文写的非常好！！！强烈建议观看原文并点赞
并且全网写得比较全的，我找了好几篇，基本都是抄的这个文章！！！

另外juejin某篇 双亲委派机制（奥利给干就完了） 也是我写的，我正在慢慢把juejin里写过的文章慢慢倒过来。。。

起因

起因是因为某实习期的同事，在写代码的时候，写了大量static代码，导致启动缓慢

因为kotlin去掉了static关键字，所以很多人在使用的时候会写入很多static代码

趁此机会我输出一篇关于类加载的文章

看类加载器

1. 启动类加载器（Bootstrap Class Loader）

2. 扩展类加载器（Extension Class Loader）

3. 应用程序类加载器（Application Class Loader）

4. 自定义类加载器（Custom Class Loader）

分析 static 类加载

1. 静态变量（Static Variables）：

   • 静态变量是属于类而不是对象的成员变量。它们在类加载时被初始化，且只会初始化一次。
   • 静态变量的初始化通常发生在类加载的初始化阶段，这是类加载的一个子阶段。初始化是在类加载时执行的代码块，用来初始化静态变量。
   • 静态变量的值在整个应用程序中是共享的，可以通过类名访问，而不需要创建类的实例。

2. 静态方法（Static Methods）：

   • 静态方法也属于类而不是对象。它们在类加载时被加载到内存中，并且不需要类的实例来调用。

   • 静态方法可以在类加载时执行一些初始化工作，例如初始化静态变量，或执行其他与类相关的操作。

   • 静态方法通常用于工具类或辅助方法，不需要与特定的实例关联。

所以他会在加载类的时候，把静态成员执行加载

双亲委派机制是什么

当一个ClassLoader收到了 类加载的请求 的时候，他不会直接去加载指定的类，而是把这个请求 委托给自己的 父加载器 去加载。只有父加载器 无法加载这个类的时候，才会由 当前这个加载器 来负责类的加载。

为什么需要双亲委派？

首先，通过委派的方式，可以避免类的重复加载，当父加载器已经加载过某一个类时，子加载器就不会再重新加载这个类。

另外，通过双亲委派的方式，还保证了安全性。

因为Bootstrap ClassLoader在加载的时候，只会加载JAVA_HOME中的jar包里面的类，如java.lang.Integer，那么这个类是不会被随意替换的。

除非有人跑到你的机器上， 在你的应用启动前破坏你的JDK，
如果他在JDK已经启动的时候破坏你的JDK，因为你已经用Bootstrap ClassLoader加载了类，所以并不影响 ，所以只有从启动前对JDK搞破坏才可以。

“父子加载器” 之间的关系是继承吗？

很多人看到父加载器、子加载器这样的名字，就会认为Java中的类加载器之间存在着继承关系。

甚至网上很多文章也会有类似的错误观点。

这里需要明确一下，双亲委派模型中，类加载器之间的父子关系一般不会以继承（Inheritance）的关系来实现，而是都使用组合（Composition）关系来复用父加载器的代码的。

如下为 ClassLoader 中父加载器的定义：

1
2
3
4
5

public abstract class ClassLoader {

    // The parent class loader for delegation
    private final ClassLoader parent;
}

双亲委派是怎么实现的？

双亲委派模型对于保证Java程序的稳定运作很重要，但它的实现并不复杂。

实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass()方法之中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
{
    synchronized (getClassLoadingLock(name)) {
    
        // 第一步，先检查类是否已经被加载过 
        Class<?> c = findLoadedClass(name);
        
        
        if (c == null) {
        
            // 第二步，若没有加载则调用父加载器的 loadClass() 方法进行加载
            long t0 = System.nanoTime();
            try {
                if (parent != null) {
                    c = parent.loadClass(name, false);
               } else {
               
                   // 第三步，若父加载器为空则默认使用 Bootstrap ClassLoader 作为父加载器 
                   c = findBootstrapClassOrNull(name);
               }
           } catch (ClassNotFoundException e) {
               // 第四步，如果父类加载失败，抛出 ClassNotFoundException 异常
               // ClassNotFoundException thrown if class not found
               // from the non-null parent class loader
           }
           
           if (c == null) {
               // 第五步，如果前面都失败，再调用自己的 findclass() 
               long t1 = System.nanoTime();
               c = findClass(name);
               // this is the defining class loader; record the stats
               PerfCounter.getParentDelegationTime().addTime(t1 - t0);
               PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
               PerfCounter.getFindClasses().increment();
           }
       }
       if (resolve) {
           resolveClass(c);
       }
       return c;
   }
}

代码不难理解，主要就是以下几个步骤：

1. 先检查类是否已经被加载过
2. 若没有加载则调用父加载器的loadClass()方法进行加载
3. 若父加载器为空则默认使用Bootstrap ClassLoader作为父加载器
4. 如果父类加载失败，抛出ClassNotFoundException异常
5. 上一步如果失败，再调用自己的findClass()方法进行加载。

如何主动破坏双亲委派机制？

知道了双亲委派模型的实现，那么想要破坏双亲委派机制就很简单了。

因为他的双亲委派过程都是在 loadClass 方法中实现的，那么想要破坏这种机制，那么就自定义一个类加载器，重写其中的 loadClass 方法，使其不进行双亲委派即可。

loadClass（）、findClass（）、defineClass（）区别

ClassLoader中和类加载有关的方法有很多，前面提到了loadClass，除此之外，还有findClass和defineClass等，那么这几个方法有什么区别呢？

loadClass()
就是主要进行类加载的方法，默认的双亲委派机制就实现在这个方法中，重写这个方法可以破坏双亲委派机制。

findClass()
根据名称或位置加载.class字节码

definclass()
把.class字节码转化为Class

这里面需要展开讲一下loadClass和findClass，我们前面说过，当我们想要自定义一个类加载器的时候，并且想破坏双亲委派原则时，我们会重写loadClass方法。

那么，如果我们想定义一个类加载器，但是不想破坏双亲委派模型的时候呢？

这时候，就可以继承ClassLoader，并且重写findClass方法。findClass()方法是JDK1.2之后的ClassLoader新添加的一个方法。

这是显而易见的，ClassLoader是一个抽象类，并且findClass(String name)是一个没有具体实现的方法，并且在上面我们看到了loadClass()里面调用了findClass()


如图：这个方法只抛出了一个异常，没有默认实现。

JDK1.2之后已不再提倡用户直接覆盖loadClass()方法，而是建议把自己的类加载逻辑实现到findClass()方法中。

因为在loadClass()方法的逻辑里，如果父类加载器加载失败，则会调用自己的findClass()方法来完成加载。

所以，如果你想定义一个自己的类加载器，并且要遵守双亲委派模型，那么可以继承ClassLoader，并且在findClass()中实现你自己的加载逻辑即可。

双亲委派被破坏的例子

双亲委派机制的破坏不是什么稀奇的事情，很多框架、容器等都会破坏这种机制来实现某些功能。

1. 第一种被破坏的情况是在双亲委派出现之前。
   由于双亲委派模型是在JDK1.2之后才被引入的，而在这之前已经有用户自定义类加载器在用了。所以，这些是没有遵守双亲委派原则的。

2. 第二种，是 JNDI、JDBC 等需要加载 SPI 接口实现类的情况。

3. 第三种是为了实现热插拔热部署工具。
   为了让代码动态生效而无需重启，实现方式时把模块连同类加载器一起换掉就实现了代码的热替换。

4. tomcat 等 web 容器的出现。

5. OSGI、Jigsaw 等模块化技术的应用。

为什么 JNDI，JDBC 等需要破坏双亲委派？

我们日常开发中，大多数时候会通过API的方式调用Java提供的那些基础类，这些基础类时被Bootstrap加载的。

但是，调用方式除了API之外，还有一种SPI的方式。

如典型的JDBC服务，我们通常通过以下方式创建数据库连接：

1

Connection conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/mysql", "root", "1234");

在以上代码执行之前，DriverManager会先被类加载器加载，因为java.sql.DriverManager类是位于rt.jar下面的 ，所以他会被Bootstrap ClassLoader加载。

类加载时，会执行该类的静态方法。其中有一段关键的代码是：

1

ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);

这段代码，会尝试加载classpath下面的所有实现了Driver接口的实现类。

那么，问题就来了。

DriverManager是被Bootstrap ClassLoader加载的，那么在加载时遇到以上代码，会尝试加载所有Driver的实现类，但是这些实现类基本都是第三方提供的，根据双亲委派原则，第三方的类不能Bootstrap ClassLoader加载。

那么，怎么解决这个问题呢？

于是，就在JDBC中通过引入ThreadContextClassLoader（线程上下文加载器，默认情况下是ApplicationClassLoader）的方式破坏了双亲委派原则。

我们深入到ServiceLoader.load方法就可以看到：

1
2
3
4

public static <S> ServiceLoader<S> load(Class<S> service) {
    ClassLoader cl = Thread.currentThread().getContextClassLoader();
    return ServiceLoader.load(service, cl);
}

第一行，获取当前线程的线程上下⽂类加载器ApplicationClassLoader，⽤于加载classpath中的具体实现类。

说实话，我没怎么深入了解过JDBC，这一段没看太懂

为什么 Tomcat 要破坏双亲委派

我们知道，Tomcat 是 web 容器，那么一个 web 容器可能需要部署多个应用程序。

不同的应用程序可能会依赖同一个第三方类库的不同版本，但是不同版本的类库中某一个类的全路径名可能是一样的。

如多个应用都要依赖lucas.jar，但是 A 应用需要依赖1.0.0版本，但是 B 应用需要依赖1.0.1版本。这两个版本中都有一个类是com.lucas.Test.class。

如果采用默认的双亲委派类加载机制，那么是无法加载多个相同的类。

所以，Tomcat破坏双亲委派原则，提供隔离的机制，为每个web 容器单独提供一个WebAppClassLoader加载器。

Tomcat的类加载机制：为了实现隔离性，优先加载Web 应用自己定义的类，所以没有遵照双亲委派的约定，每一个应用自己的类加载器——WebAppClassLoader负责加载本身的目录下的class文件，加载不到时再交给CommonClassLoader加载，这和双亲委派刚好相反。

模块化技术与类加载机制

近几年模块化技术已经很成熟了，在 JDK 9 中已经应用了模块化的技术。

其实早在JDK 9之前，OSGI这种框架已经是模块化的了，而OSGI之所以能够实现模块热插拔和模块内部可见性的精准控制都归结于其特殊的类加载机制，加载器之间的关系不再是双亲委派模型的树状结构，而是发展成复杂的网状结构。

在JDK中，双亲委派也不是绝对的了。

在JDK9之前，JVM的基础类以前都是在rt.jar这个包里，这个包也是JRE运行的基石。

这不仅是违反了单一职责原则，同样程序在编译的时候会将很多无用的类也一并打包，造成臃肿。

在JDK9中，整个JDK都基于模块化进行构建，以前的rt.jar,tool.jar被拆分成数十个模块，编译的时候只编译实际用到的模块，同时各个类加载器各司其职，只加载自己负责的模块。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Class<?> c = findLoadedClass(cn);
if (c == null) {
    // 找到当前类属于哪个模块
    LoadedModule loadedModule = findLoadedModule(cn);
    if (loadedModule != null) {
        //获取当前模块的类加载器
        BuiltinClassLoader loader = loadedModule.loader();
        //进行类加载
        c = findClassInModuleOrNull(loadedModule, cn);
     } else {
          // 找不到模块信息才会进行双亲委派
            if (parent != null) {
              c = parent.loadClassOrNull(cn);
            }
      }
}

总结

… 没有总结