[五]类加载机制双亲委派机制 底层代码实现原理 源码分析 java类加载双亲委派机制是如何实现的

  原文地址:[五]类加载机制双亲委派机制 底层代码实现原理 源码分析 java类加载双亲委派机制是如何实现的

Launcher启动类

本文是双亲委派机制的源码分析部分,类加载机制中的双亲委派模型对于jvm的稳定运行是非常重要的 不过源码其实比较简单,接下来简单介绍一下   我们先从启动类说起 有一个Launcher类   sun.misc.Launcher;   仔细看下这简短的几行注释,可以得到有用的信息 ps:直接IDE里面查看反编译的,看不到注释的,可以下载openJDK查看源码,我的这个版本是openjdk-8-src-b132-03_mar_2014  

sun.misc.Launcher 这个类是系统用于启动主应用的启动器

  构造方法 Launcher() 中做了四件事情

创建          扩展          类加载器

创建          应用程序    类加载器

设置ContextClassLoader

如果需要安装安全管理器 security manager

其中launcher是staitc的,所以初始化的时候就会创建对象,也就是触发了构造方法,所以初始化的时候就会执行上面四个步骤   ExtClassLoader 和  AppClassLoader  都是Launcher的静态内部类 而且,他们也都是ClassLoader的实现类   看下ExtClassLoader的创建中的关键几步   也在看下AppClassLoader的创建中的关键几步   另外还有 Launcher类中的静态变量   你应该可以想得到下面这三个到底是什么东西,如果真不懂,你需要再去研究下 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

    ps: 本文中的不少地方,我都在"父类加载器" 的"父 "和"类加载器"中间加了几个空格 千万不要理解成父类加载器  ,<父    类加载器> 指的是类加载器的加载顺序层级结构的优先顺序   而不是平时说的继承关系中的父类 父 意味着他的上一层级  

getSystemClassLoader 获取AppClassLoader 的过程

  那么再回头看一眼  应用程序   类加载器的构造 扩展  类加载器作为参数传递给了他,他最终调用的就是ClassLoader 的一个参数的构造方法   将ExtClassLoader 设置为 AppClassLoader  的parent   而ExtClassLoader,他的parent 是null   ps:启动  类加载器 是虚拟机的一部分,可能c/c++/java实现的,所以不是java语言的一部分 所以对于java本身来说,可以说他是不存在的,但是JVM是知道他的 所以说,此处为null ,parent为null说明他的父    类加载器是启动类加载器   或者可能就是启动  类加载器本身

---

loadClass与findClass

想要实现类 加载器,需要继承ClassLoader 并且有两个重要的方法 看下两个重要方法的声明,你可能就感觉出来了,想想public 和 protected都是啥意思?  

loadClass方法是类加载器执行   加载类逻辑   的方法,包括检查是否已经加载,调用父类加载,失败则自己尝试使用 findClass方法加载

findClass当前类加载器 实际执行加载二进制流的具体行为方法

 

Launcher.APPClassLoader中的loadClass方法,最终调用的是super.loadClass  , 实际上就是ClassLoader的loadClass方法 Launcher.ExtClassLoader  根本就没有实现自己的loadClass 方法,所以使用的也是ClassLoader中的

    再来看看ClassLoader的loadClass方法 他会调用parent的loadClass方法,如果他的parent不为空,将会一直调用父 类加载器, 直到最顶级的  启动   类加载器  如果 启动   类加载器仍旧找寻不到, 那么调用自身的findClass    如果自己调用findClass加载失败呢? 很显然, 函数调用结束之后,会返回到调用点位置,调用栈的形式嘛 也就是经过 必然要继续执行他的下一段 如果没抛出异常的话,就会走到下面这里 显然这就完成了一整个的双亲委派的类加载模式    

总结

Launcher作为启动器 创建了ExtClassLoader 以及AppClassLoader 他们都是ClassLoader的子类,并且ClassLoader有一个parent  指向他的父   类加载器 正是这个属性完成了自顶而下的 优先级层级顺序的确定 对于sun内置的ExtClassLoader 以及AppClassLoader  以及启动  类加载器 Bootstrap  他们的层级为 Bootstrap>ExtClassLoader>ExtClassLoader 并且,他们各自有不同的分工 通过ClassLoader的loadClass方法,确定了他们的调用逻辑,也就是双亲委派机制 每个层级都会向上传递类加载请求,只有上层  父     类加载器调用失败,才会自己尝试加载 双亲委派机制的意义重大,带来了更高的安全性等优点 不过他的实现逻辑却是的确很简单 一个loadClass就搞定了 findClass是类加载器自身加载类的具体行为 所以,如果你不需要破坏双亲委派机制,只需要覆盖这个方法即可 如果你想要完全自定义你的类加载器的逻辑机制,直接覆盖loadClass,当然,你可能还需要继续覆盖findClass

标签：loadClass,parent,ExtClassLoader,ClassLoader,Launcher,双亲,机制,加载
来源： https://www.cnblogs.com/JonaLin/p/11089802.html