深入理解Java虚拟机，学习笔记（五）类加载器

irak

于 2019-01-07 20:47:02 发布

阅读量111

点赞数

分类专栏： jvm

本文链接：https://blog.csdn.net/xmzyjr123/article/details/86020831

版权

jvm 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

类加载器

加载与类加载器
类与类加载器
双亲委派模型
破坏双亲委派模型

加载与类加载器

之前说到加载有三个步骤：
1.根据类对全限定名来获取类的二进制字节流
2.将字节流中的静态结构转换成方法区的运行时的数据结构
3.在内存中生成一个Class对象，作为访问方法区的类数据的一个入口

类加载是与第一步相关，因为如何获取类的二进制字节流这个动作就被称为“类加载器”。

类与类加载器

类加载器

基本的类加载器有：bootstrap类加载器（启动类加载器、引导类加载器），扩展类加载器，应用程序类加载器。
bootstrap类加载器：这个有虚拟机实现，只加载JAVA_HOME/lib 下面的类，如：rt.jar 里面包含的基础类。
扩展类加载器：只加载 JAVA_HOME/lib/ext 下面的类
应用程序类加载器：加载classPath下面的类，也就是我们写的一般类。

显示加载与隐式加载

显示加载：类似Class.forName(“XXX”), 或者是获取类加载去加载它，在代码里面有显示声明的。
隐式加载：是由虚拟机来加载的，例如遇到 new 、getStatic、 putStatic、 involeStatic 等字节码指令的时候，类还没加载过则会由虚拟机来加载初始化。

双亲委派模型

在这里插入图片描述
双亲委派模型定义了，一个类被一个类加载器加载，该类加载器会将它委派给父类加载器加载，如果父类加载器加载不了，则把它给父类的子类加载器加载。
这样做的好处就是避免了关键类（基础类或者是需要被共享的类）被不同的类加载加载后，会引起程序的混乱。

破坏双亲委派模型

破坏双亲委派模型并不是破坏类加载器里面的规则，做不到将java.lang.String类由自定义的类加载器加载。

第一次破坏

在双亲委派模型出来之前，已经存在类加载器和抽象类ClassLoader类，用户继承ClassLoader类重写了里面的loadClass方法。
现在的ClassLoader类里面的loadClass的逻辑就是体现了，双亲委派模型的思想。并且建议用户重写findClass方法。

第二次破坏

因为越基础的类需要越顶层的类加载器来加载，但是顶层的类并不一定都是被引用的，也会有调用用户代码。但是顶层的类加载器并不认识这些代码。
例如：JNDI（java naming and directory interface），如果在代码中硬编码去连接数据库，修改了数据库密码后就要对代码进行重新编写并重启。jndi的目的对资源进行管理和查找，它需要调用独立厂商实现并部署在应用程序对ClassPath下对JNDI接口提供者（SPI，Service Provider Interface）的代码，但是启动类不认识这些“代码”，所以只好请求线程上下文类加载器。

线程上下文类加载器

java.lang.Thread的一个对象引用，如果没有对他进行设置的话，默认是应用程序类加载器。
Thread.currentThread().getContextClassLoader(); 这句就是获取线程上下文类加载器。
有了这个引用就可以在被bootstrap类加载器加载的类中再去委派给子类加载去加载。虽然这违反了双亲委派模型的初衷。

第三次破坏

用户对程序动态性对追求而导致对，（热替换HotSwap）。
这块对应对技术有OSGI。
因为像现在的系统不再是单机版了，而是把功能分模块来进行编程。每个模块在osgi里面被称为bundle，每个bundle都有自己的类加载器。当需要更换一给bundle时，就把bundle连同类加载器一起换掉以实现代码的热替换。
在osgi环境下，类加载器不在是双亲委派模型中的树状结构，而是复杂的网状结构。
在类请求时，osgi按照下面的顺序进行类搜索：
1）将以java.*开头的类委派给父类加载器加载。
2）否则，将委派列表名单内的类委派给父类加载器加载
3）否则，将Import列表中的类委派给Export这个类的bundle的类加载器加载。
4）否则，查找当前bundle的ClassPath，使用自己的类加载器加载。
5）否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给 Fragment Bundle的类加载器加载。
6）否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载
7）否则，类查找失败。