类加载的完善

最新推荐文章于 2024-10-13 23:27:44 发布

xing_S

最新推荐文章于 2024-10-13 23:27:44 发布

阅读量243

点赞数

分类专栏： jvm 文章标签： java 开发语言

本文链接：https://blog.csdn.net/xing_S/article/details/123168990

版权

jvm 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

学习目标

对类加载器和类加载器的完善，知识包括：破坏双亲委派机制的应用、jdk9后双亲委派的改变、自定义类加载器的实现。

双亲委派机制的破坏

“破坏”并不是一种贬义，而是对技术的一种创新，通过’破坏’双亲委派机制，可以更好的满足用户对加载需要的要求。
知道java模块的（jdk9）位置，双亲委派机制出现过三次较大规模的破坏的情况。

第一次

双亲委派机制是在jdk1.2的时候引入的，为了兼顾以前的代码，所以对ClassLoader扩展的一个新的Protected的findClass()方法来让用户实现加载的时候尽量重写这个方法。即jdk1.2之前的代码不遵循双亲委派机制

第二次

是双亲委派机制这个模型本身的一些缺陷导致的。双亲委派机制的作用是：越基础的类越由上层加载器来加载，但是没有决对的事情，随着技术的发展，有些基础的类需要使用其下层的类，但是启动类加载器不可能认识下次的类，所以对双亲委派机制进行了破坏。
如jdbc，它是一种规范，需要调用其他厂商的对jdbc的实现的代码（如mysql），但是启动类加载器是不认识其他厂商（mysql）的代码的，所以引入了线程上下文类加载器。这个时候父类加载器就可以去请求子类加载器对类进行加载了。
在这里插入图片描述

第三次

第三次被破坏是最求的‘热替换’功能，也就是说，希望java代码可以像电脑的外设设备一样，不用关机便对设备进行替换（如鼠标）。也就是希望在运行的程序，不用继续下线，便可以重新加载更新的代码（如：jsp）。

tomcat的源码分析

public Class loadClass(String name, boolean resolve)
 2             throws ClassNotFoundException {
 3         Class clazz = null;
 4         // (0) 先从自己的缓存中查找，有则返回，无则继续
 5         clazz = findLoadedClass0(name);
 6         if (clazz != null) {
 7             if (resolve) resolveClass(clazz);            
 8             return (clazz);
 9         }
10         // (0.1) 再从parent的缓存中查找
11         clazz = findLoadedClass(name);
12         if (clazz != null) {
13             if (resolve) resolveClass(clazz);
14             return (clazz);
15         }
16         // (0.2) 缓存中没有，则首先使用system类加载器来加载
17         clazz = system.loadClass(name);
18          if (clazz != null) {
19              if (resolve) resolveClass(clazz);
20              return (clazz);
21          }
22         //判断是否需要先让parent代理
23         boolean delegateLoad = delegate || filter(name);
24         // (1) 先让parent加载，通常delegateLoad == false，即这一步不会执行
25 
26         if (delegateLoad) {
27             ClassLoader loader = parent;
28             if (loader == null)
29                 loader = system;
30             clazz = loader.loadClass(name);
31             if (clazz != null) {
32                 if (resolve) resolveClass(clazz);
33                 return (clazz);
34             }
35         }
36         // (2) delegateLoad == false 或者 parent加载失败，调用自身的加载机制
37         clazz = findClass(name);
38         if (clazz != null) {
39             if (resolve) resolveClass(clazz);
40             return (clazz);
41         }
42         // (3) 自己加载失败，则请求parent代理加载
43 
44         if (!delegateLoad) {
45             ClassLoader loader = parent;
46             if (loader == null)
47                 loader = system;
48             clazz = loader.loadClass(name);
49             if (clazz != null) {
50                 return (clazz);
51             }
52         }
53         throw new ClassNotFoundException(name);
54     }

流程图：
在这里插入图片描述

自定义类加载器

应用场景

隔离加载类

在某些框架内进行中间件与应用的模块隔离，把类加载到不同的环境。比如：阿里内某容器框架通过自定义类加载器确保应用中依赖的jar包不会影响到中间件运行时使用的jar包。再比如：Tomcat这类Web应用服务器，内部自定义了好几种类加载器，用于隔离同一个Web应用服务器上的不同应用程序。（类的仲裁–>类冲突）

修改类加载的方式

类的加载模型并非强制，除Bootstrap外，其他的加载并非一定要引入，或者根据实际情况在某个时间点进行按需进行动态加载

扩展加载源

比如从数据库、网络、甚至是电视机机顶盒进行加载

防止源码泄漏

Java代码容易被编译和篡改，可以进行编译加密。那么类加载也需要自定义，还原加密的字节码。

注意：在一般情况下，使用不同的类加载器去加载不同的功能模块，会提高应用程序的安全性。但是，如果涉及Java类型转换，则加载器反而容易产生不美好的事情。在做Java类型转换时，只有两个类型都是由同一个加载器所加载，才能进行类型转换，否则转换时会发生异常。

手写自定义加载器：

public class UserClassLoader extends ClassLoader {
    private String rootDir;

    public UserClassLoader(String rootDir) {
        this.rootDir = rootDir;
    }

    /**
     * 编写findClass方法的逻辑
     */
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        // 获取类的class文件字节数组
        byte[] classData = getClassData(name);
        if (classData == null) {
            throw new ClassNotFoundException();
        } else {
            //直接生成class对象,调用ClassLoader类的
            return defineClass(name, classData, 0, classData.length);
        }
    }

    /**
     * 编写获取class文件并转换为字节码流的逻辑 * @param className * @return
     */
    private byte[] getClassData(String className) {
        // 读取类文件的字节
        String path = classNameToPath(className);
        try {
            InputStream ins = new FileInputStream(path);
            ByteArrayOutputStream baos = new ByteArrayOutputStream();
            byte[] buffer = new byte[1024];
            int len = 0;
            // 读取类文件的字节码
            while ((len = ins.read(buffer)) != -1) {
                baos.write(buffer, 0, len);
            }
            return baos.toByteArray();
        } catch (IOException e) {
            e.printStackTrace();
        }
        return null;
    }
    
}

jdk9加载器的变化

为了兼容性，jdk9没有从本质上破坏双亲委派机制，但是对双亲外派机制的结构进了修改

扩展类机制被移除，但是为了保证向后兼容，扩展类加载器任被保留，不过被重命名为了平台类加载器（platform class loader）。由于jdk9的模块化构建，原来的 rt.jar 和 tools.jar 被拆分成数十个 JMOD 文件，其中的 Java 类库就已天然地满足了可扩展的需求，那自然无须再保留 <JAVA_HOME>\lib\ext 目录，此前使用这个目录或者 java.ext.dirs 系统变量来扩展 JDK 功能的机制已经没有继续存在的价值了。
平台类加载器和应用程序类加载器都不再继承自 java.net.URLClassLoader。现在启动类加载器、平台类加载器、应用程序类加载器全都继承于 jdk.internal.loader.BuiltinClassLoader。如果有程序直接依赖了这种继承关系，或者依赖了 URLClassLoader 类的特定方法，那代码很可能会在 JDK 9 及更高版本的 JDK 中崩溃。
在Java 9中，类加载器有了名称。该名称在构造方法中指定，可以通过getName()方法来获取。平台类加载器的名称是platform，应用类加载器的名称是app。类加载器的名称在调试与类加载器相关的问题时会非常有用。
启动类加载器现在是在jvm内部和java类库共同协作实现的类加载器（以前是 C++实现），但为了与之前代码兼容，在获取启动类加载器的场景中仍然会返回null，而不会得到BootClassLoader实例。

jdk9的加载器委派关系图：
在这里插入图片描述