JVM系列（6）——类加载器详解&&双亲委派

痛定思痛。 2024-03-17 19:35 63阅读 0赞

### 一、类加载器 ###

类加载器是一个负责加载类的对象，用于实现类加载过程中的加载这一步。  
**主要作用就是加载 Java 类的字节码（ .class 文件）到 JVM 中（在内存中生成一个代表该类的 Class 对象）。**  
加载过程可以看 [JVM系列（5）——类加载过程][JVM_5]。  
类加载器有四种：  
*1、**BootstrapClassLoader(启动类加载器)：** 最顶层的加载类，由 C++实现，**主要用来加载 JDK 内部的核心类库**（ jre/lib/rt.jar）以及被 -Xbootclasspath参数指定的路径下的所有类。  
2、**ExtensionClassLoader(扩展类加载器)：** 平台类加载器，负责加载扩展jar包，比如XMl, 加密，压缩相关的功能类，主要位于jre/lib/ext/*.jar。  
*3、**AppClassLoader(应用程序类加载器)**：面向我们用户的加载器，负责加载当前应用 classpath 下的所有 jar 包和类。*  
4、**自定义加载器：** 用户可自定义加载器，模板方法模式，后面细讲。

### 二、双亲委派模型 ###

直接上图：  
![在这里插入图片描述][4b0b460becd4434abbbb6d82e4fc76f9.png]  
注意的是，**虽然上层的叫父加载器，但不是父子继承关系，是组合关系。**  
类加载的过程如图所示：  
![在这里插入图片描述][8fa70acacc6e4cca94e65ed0e44be54e.png]  
我们用代码演示一下加载器：

public static void main(String[] args) {
        
            System.out.println(String.class.getClassLoader());
            System.out.println(com.sun.java.accessibility.AccessBridge.class.getClassLoader());
            System.out.println(com.alibaba.fastjson.asm.ByteVector.class.getClassLoader());
            System.out.println(ClassLoaderTest.class.getClassLoader());
        }

![在这里插入图片描述][23607c97db1f411a9216803a2a59be0b.png]

### 三、Classloader源码解析 ###

sun.misc.Launcher类是java 虚拟机的入口，在启动 java应用 的时候会首先创建Launcher。在初始化Launcher对象的时候会创建一个ExtClassLoader拓展程序加载器 和 AppClassLoader应用程序类加载器，然后由这俩类加载器去加载应用程序中需要的各种类。  
构造方法如下：

public Launcher() {
        
            Launcher.ExtClassLoader var1;
            try {
        
            	//创建一个ExtClassLoader
                var1 = Launcher.ExtClassLoader.getExtClassLoader();
            } catch (IOException var10) {
        
                throw new InternalError("Could not create extension class loader", var10);
            }
    
            try {
        
            	//创建一个AppClassLoader
                this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
            } catch (IOException var9) {
        
                throw new InternalError("Could not create application class loader", var9);
            }
    
           ...

AppClassloader源码如下：

static class AppClassLoader extends URLClassLoader {
         
            public Class<?> loadClass(String var1, boolean var2) throws ClassNotFoundException {
        
                // ...
                //读取路径为"java.class.path"
                 final String var1 = System.getProperty("java.class.path");
                 //...
                // 调用了一个 native 本地方法 knownToNotExist()，去查找该类的加载记录
                if (this.ucp.knownToNotExist(var1)) {
                // 如果有该类加载记录
                    Class var5 = this.findLoadedClass(var1); // 直接去已经加载的类中找
                    if (var5 != null) {
        
                        if (var2) {
        
                            this.resolveClass(var5);
                        }
                        return var5;
                    } else {
                                         // 如果没找到报异常
                        throw new ClassNotFoundException(var1);
                    }
                } else {
                                             // 如果没有该类的加载记录
                    return super.loadClass(var1, var2);      // 调用父类 ClassLoader 的 loadClass()
                }
            }
    }

ExtClassLoader源码其中一段如下：

//读取路径为"java.ext.dirs"
     String var0 = System.getProperty("java.ext.dirs");

ExtClassLoader 并没有对 loadClass() 方法进行重写，也就是说它直接调用其父类 ClassLoader 的 loadClass() 方法。  
AppClassLoader 和ExtClassLoader 都继承了URLClassLoader 继承 SecureClassLoader 继承 ClassLoader。  
ClassLoader源码如下：

protected Class<?> loadClass(String name, boolean resolve)
            throws ClassNotFoundException
        {
        
        	 加载一个类的时候，锁住对应的类加载器对象
            synchronized (getClassLoadingLock(name)) {
        
                // First, check if the class has already been loaded
                Class<?> c = findLoadedClass(name);//查询已加载的类中是否有该类存在 
                if (c == null) {
        
                    long t0 = System.nanoTime();
                    try {
        
                        if (parent != null) {
        //非顶层类加载器,调用父加载器
                            c = parent.loadClass(name, false);
                        } else {
        
                            c = findBootstrapClassOrNull(name);//否则调用启动类加载器加载
                        }
                    } catch (ClassNotFoundException e) {
        
                        // ClassNotFoundException thrown if class not found
                        // from the non-null parent class loader
                    }
    
                    if (c == null) {
         //如果在 父类加载器 或 启动类加载器 没有找到需要加载的类
                        // If still not found, then invoke findClass in order
                        // to find the class.
                        long t1 = System.nanoTime();
                        c = findClass(name);//再由当前加载器加载
    
                        // this is the defining class loader; record the stats
                        sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                        sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                        sun.misc.PerfCounter.getFindClasses().increment();
                    }
                }
                if (resolve) {
        
                    resolveClass(c);//对类进行解析
                }
                return c;
            }
        }

由上面代码可以看出，双亲委派模型主要是由loadClass这个方法决定的。  
而不管是App还是Exe加载器，都继承了ClassLoader类，应用了其中的loadClass这个方法，这个模式是什么呢？  
没错，就是**模板方法模式**，也因此，我们可以很简单的自定义类加载器。

### 四、自定义类加载器 ###

要自定义自己的类加载器，很明显需要继承 ClassLoader抽象类。而jvm官方的API 文档中写到：

> 建议 ClassLoader的子类重写 findClass(String name)方法而不是loadClass(String name, boolean resolve) 方法。

如果我们不想打破双亲委派模型，就重写 ClassLoader 类中的 findClass() 方法即可，无法被父类加载器加载的类最终会通过这个方法被加载。但是，如果想打破双亲委派模型则需要重写 loadClass() 方法。  
findclass（）源码如下：

protected Class<?> findClass(String name) throws ClassNotFoundException {
        
            throw new ClassNotFoundException(name);
        }

可以看出，留着就是给我们重写的。哈哈哈哈哈哈哈哈  
自定义类加载器代码如下，**主要是将class文件转成二进制流，并且返回一个Class对象**：

@Override
        protected Class<?> findClass(String name) throws ClassNotFoundException {
        
            // IO流读取字节码文件为二进制流
            try (BufferedInputStream bis = new BufferedInputStream((new FileInputStream("home/app/" + ".class")));
                 ByteArrayOutputStream bos = new ByteArrayOutputStream()) {
        
                int len;
                byte[] bytes = new byte[1024];
                while ((len = bis.read(bytes)) != -1) {
        
                    bos.write(bytes, 0, len);
                }
                bos.flush();
                bytes = bos.toByteArray();
                return defineClass(null,bytes,0,bytes.length);
            } catch (FileNotFoundException e) {
        
                e.printStackTrace();
            } catch (IOException e) {
        
                e.printStackTrace();
            }
            return null;
        }

defineClass方法也是ClassLoader的方法，源码如下：

@Deprecated
        protected final Class<?> defineClass(byte[] b, int off, int len)
            throws ClassFormatError
        {
        
            return defineClass(null, b, off, len, null);
        }
        ...
        protected final Class<?> defineClass(String name, byte[] b, int off, int len,
                                             ProtectionDomain protectionDomain)
            throws ClassFormatError
        {
        
            protectionDomain = preDefineClass(name, protectionDomain);
            String source = defineClassSourceLocation(protectionDomain);
            Class<?> c = defineClass1(name, b, off, len, protectionDomain, source);
            postDefineClass(c, protectionDomain);
            return c;
        }

话锋一转，打破双亲委派模型，在哪里用到了呢？

> Tomcat 服务器为了能够优先加载 Web 应用目录下的类，然后再加载其他目录下的类，就自定义了类加载器WebAppClassLoader 来打破双亲委托机制。这也是 Tomcat 下 Web 应用之间的类实现隔离的具体原理。

### 五、双亲委派模型好处 ###

为什么要用双亲委派模型呢？  
**1、安全；**  
举个例子：你自定义了一个String类，在这个String类里做一下泄露用户信息的操作，用户在使用你的程序时，只要用到了String类，必然会触发泄露信息，造成极大的信息安全。  
**2、避免资源浪费。**  
这个简单，类不要重复加载了，省资源。

### 六、总结 ###

1、双亲委派模型：自下而上寻找，自上而下派任务去解析。  
2、类加载器是模板方法模式，重写findClass() 方法自定义类加载器，重写loadClass() 打破双亲委派模型。  
3、双亲委派模型安全、节省资源。

[JVM_5]: https://blog.csdn.net/liwangcuihua/article/details/131685959?spm=1001.2014.3001.5501
[4b0b460becd4434abbbb6d82e4fc76f9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/3c5d43a97b604bcea16f27b5872d7e46.png
[8fa70acacc6e4cca94e65ed0e44be54e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/2448f64713fb492290167aff5bcd0b1f.png
[23607c97db1f411a9216803a2a59be0b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/b9b5083c32c247c08382667d6ef13702.png