阅读目录 Launcher启动类 ClassLoader的构造方法 loadClass与findClass 总结 回到顶部 Launcher启动类 本文是双亲委派机制的源码分析部分,类加载机制中的双亲委派模型对于jvm的稳定运行是非常重要的 不过源码其实比较简单,接下来简单介绍一下 我们先从启动类说起 有一个Launcher类 sun.misc.Launcher; image_5b8be55e_4272 仔细看下这简短的几行注释,可以得到有用的信息 ps:直接IDE里面查看反编译的,看不到注释的,可以下载openJDK查看源码,我的这个版本是openjdk-8-src-b132-03_mar_2014 sun.misc.Launcher 这个类是系统用于启动主应用的启动器 构造方法 Launcher() 中做了四件事情 创建 扩展 类加载器 创建 应用程序 类加载器 设置ContextClassLoader 如果需要安装安全管理器 security manager 其中launcher是staitc的,所以初始化的时候就会创建对象,也就是触发了构造方法,所以初始化的时候就会执行上面四个步骤 image_5b8be55e_3add ExtClassLoader 和 AppClassLoader 都是Launcher的静态内部类 image_5b8be55e_6921 而且,他们也都是ClassLoader的实现类 image_5b8be55e_3cb7 看下ExtClassLoader的创建中的关键几步 image_5b8be55e_77fe 也在看下AppClassLoader的创建中的关键几步 image_5b8be55e_7080 另外还有 Launcher类中的静态变量 image_5b8be55e_62a5 你应该可以想得到下面这三个到底是什么东西,如果真不懂,你需要再去研究下 System.getProperty("sun.boot.class.path") System.getProperty("java.ext.dirs") System.getProperty("java.class.path") 回到顶部 ClassLoader的构造方法 前面说过,对于虚拟机来说只有两种类加载器 启动类加载器以及其他所有,而其他所有都是java.lang.ClassLoader的子类 所以想要自定义类加载器,必须要继承实现ClassLoader 而且,我们上面说到的,java给我们提供的AppClassLoader 和 ExtClassLoader 也都是ClassLoader的子类 看下ClassLoader的构造方法 和变量parent 你会发现,其实构造方法实际上只有双参数版本这一种 第二个参数为parent,这个parent是一个ClassLoader, 用于记录他的 父 类加载器 不管调用哪个构造方法 parent必然会被初始化 要么是你调用带参数的构造方法, 显式指定一个来设置parent 如果你不指定,默认的构造方法,会使用 getSystemClassLoader返回的AppClassLoader 设置parent image_5b8be55e_2925 ps: 本文中的不少地方,我都在"父类加载器" 的"父 "和"类加载器"中间加了几个空格 千万不要理解成父类加载器 ,<父 类加载器> 指的是类加载器的加载顺序层级结构的优先顺序 而不是平时说的继承关系中的父类 父 意味着他的上一层级 getSystemClassLoader 获取AppClassLoader 的过程 image_5b8be55f_2f0b 那么再回头看一眼 应用程序 类加载器的构造 扩展 类加载器作为参数传递给了他,他最终调用的就是ClassLoader 的一个参数的构造方法 将ExtClassLoader 设置为 AppClassLoader 的parent image_5b8be55f_4098 而ExtClassLoader,他的parent 是null image_5b8be55f_53e0 ps:启动 类加载器 是虚拟机的一部分,可能c/c++/java实现的,所以不是java语言的一部分 所以对于java本身来说,可以说他是不存在的,但是JVM是知道他的 所以说,此处为null ,parent为null说明他的父 类加载器是启动类加载器 或者可能就是启动 类加载器本身 回到顶部 loadClass与findClass 想要实现类 加载器,需要继承ClassLoader 并且有两个重要的方法 看下两个重要方法的声明,你可能就感觉出来了,想想public 和 protected都是啥意思? image_5b8be55f_6d2f loadClass方法是类加载器执行 加载类逻辑 的方法,包括检查是否已经加载,调用父类加载,失败则自己尝试使用 findClass方法加载 findClass当前类加载器 实际执行加载二进制流的具体行为方法 Launcher.APPClassLoader中的loadClass方法,最终调用的是super.loadClass , 实际上就是ClassLoader的loadClass方法 Launcher.ExtClassLoader 根本就没有实现自己的loadClass 方法,所以使用的也是ClassLoader中的 image_5b8be55f_66ff 再来看看ClassLoader的loadClass方法 他会调用parent的loadClass方法,如果他的parent不为空,将会一直调用父 类加载器, 直到最顶级的 启动 类加载器 如果 启动 类加载器仍旧找寻不到, 那么调用自身的findClass image_5b8be55f_2ac5 如果自己调用findClass加载失败呢? 很显然, 函数调用结束之后,会返回到调用点位置,调用栈的形式嘛 也就是经过 image_5b8be55f_1e1a 必然要继续执行他的下一段 如果没抛出异常的话,就会走到下面这里 image_5b8be55f_5b1f 显然这就完成了一整个的双亲委派的类加载模式 image_5b8be55f_4c07 回到顶部 总结 Launcher作为启动器 创建了ExtClassLoader 以及AppClassLoader 他们都是ClassLoader的子类,并且ClassLoader有一个parent 指向他的父 类加载器 正是这个属性完成了自顶而下的 优先级层级顺序的确定 对于sun内置的ExtClassLoader 以及AppClassLoader 以及启动 类加载器 Bootstrap 他们的层级为 Bootstrap>ExtClassLoader>ExtClassLoader 并且,他们各自有不同的分工 通过ClassLoader的loadClass方法,确定了他们的调用逻辑,也就是双亲委派机制 每个层级都会向上传递类加载请求,只有上层 父 类加载器调用失败,才会自己尝试加载 双亲委派机制的意义重大,带来了更高的安全性等优点 不过他的实现逻辑却是的确很简单 一个loadClass就搞定了 findClass是类加载器自身加载类的具体行为 所以,如果你不需要破坏双亲委派机制,只需要覆盖这个方法即可 如果你想要完全自定义你的类加载器的逻辑机制,直接覆盖loadClass,当然,你可能还需要继续覆盖findClasshttps://www.cnblogs.com/noteless/p/9575448.html