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

Posted noteless

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了[五]类加载机制双亲委派机制 底层代码实现原理 源码分析 java类加载双亲委派机制是如何实现的相关的知识,希望对你有一定的参考价值。

 

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,当然,你可能还需要继续覆盖findClass
 
 

以上是关于[五]类加载机制双亲委派机制 底层代码实现原理 源码分析 java类加载双亲委派机制是如何实现的的主要内容,如果未能解决你的问题,请参考以下文章

Tomcat打破双亲委派机制执行顺序底层代码原理JVM04_Tomcat JDBC破坏双亲委派机制带来的面试

Java 虚拟机原理Android 类加载机制 ( 双亲委派机制 | BootClassLoader | PathClassLoader | DexClassLoader )

从源码理解双亲委派机制,原来如此简单

双亲委派机制

Java双亲委派模型:为什么要双亲委派?如何打破它?破在哪里?

Java双亲委派模型:为什么要双亲委派?如何打破它?破在哪里?