前言

上一节咱们简略理解了jvm类加载器的步骤并详细分析了jvm类加载步骤的具体细节，本节将会接着讲述对于双亲委派机制的细节。双亲委派机制是jvm一个类加载的重要加载机制，它是jvm的类继承构造的底层设计也是jvm类加载的外围步骤，咱们通常应用的tomcat对于双亲委派机制进行了毁坏这也是须要理解的内容。

概述

上面是书中jvm虚拟机执行引擎的内容概括：

虚拟机和类加载机制概述    把握双亲委派模型        三层模型            启动加载器            扩大类加载器                毁坏：在jdk9中转化为平台加载器            应用程序类加载器        Osgi模型    什么是类加载器        理解类加载器的作用        对于类加载器的理论利用    java模块化对双亲委派模型的影响    类加载的六个步骤        加载        连贯            验证            筹备            解析        初始化        应用        卸载

本文内容

  1. 讲述双亲委派机制的基本原理
  2. 模块化对于类加载器的影响

思维导图

上面是对应的幕布思维导图地址：https://www.mubucm.com/doc/6v...

类和类加载器

在本系列的第一篇咱们讲述了类加载器是加载类的外围，当咱们写好的java文件被jvm虚拟机编译为.class文件并且加载到jvm虚拟机当中转为字节码指令，通过执行字节码指令实现咱们编写的程序。一个类要被加载首先须要被jvm意识才行，而意识它就是靠的类加载器，类加载器毫无疑问就是来加载类的。

自定义类加载器

书中给了一个自定义类加载器的案例，这里间接贴过来了。这个类加载器所做的事件就是简略的构建一个类加载，然而在最初进行instanceof的操作的时候，发现后果是false，这是因为类加载器加载的类是自定义的，而不是jvm程序生成的类。

这里也能够认为如果有自定义加载器，则在进行类加载器判断的时候，须要进行“加载”的操作。因为在这里它存在 两个加载器。
public class ClassLoaderTest {    public static void main(String[] args) throws ClassNotFoundException, InstantiationException, IllegalAccessException {        ClassLoader myLoader = new ClassLoader() { @Override        public Class<?> loadClass(String name) throws ClassNotFoundException { try {            String fileName = name.substring(name.lastIndexOf(".") + 1)+".class"; InputStream is = getClass().getResourceAsStream(fileName);            if (is == null) {                return super.loadClass(name); }            byte[] b = new byte[is.available()]; is.read(b);            return defineClass(name, b, 0, b.length);        } catch (IOException e) {            throw new ClassNotFoundException(name);        } }        };        Object obj = myLoader.loadClass("com.headfirst.classloader.ClassLoaderTest").newInstance();        System.out.println(obj.getClass());        System.out.println(obj instanceof com.headfirst.classloader.ClassLoaderTest);    }/*运行后果：    class com.headfirst.classloader.ClassLoaderTest    false   */}

什么是双亲委派机制？

双亲委派机制指的是jvm的一品种加载机制，jvm的类加载构造如下图：

结构图如上所示，将分为三层构造，别离是启动类加载器，扩大类加载器和应用程序加载器，这三个加载器首先通过应用程序加载，如果发现无奈加载类，则向上委托给父类的扩大类加载器进行加载 ，如果同样加载则持续网上进行申请加载，最初如果顶层启动类也无奈加载，这时候又回从顶层向下进行加载，直到自定义加载器能够加载，最初如果都无奈加载，则抛出相干的异样。

对于启动类加载器等等具体的工作流程因为系列晚期的文章曾经讲述过这里间接给出链接：

## 对于IBM的OSGI

osgi是当初ibm公司为了jdk模块化标准做的一个致力，当然当初早曾经被jdk9的模块化取代，当然这也能够说是商业竞争下的一种斗争，最初的后果就是java的模块化和预期成果存在肯定的差距，并且尽管还是毁坏了双亲委派的机制，然而在整体上仍旧能放弃根本的类加载器的结构设计。

这让我想到了Jrocket和HotSpot的合并，其实成果远不如官网设计的完满成果，总是要差那么一点。

上面是osgi的运行流程，简略理解即可：

  1. Java.* 结尾，父类加载器加载
  2. 委派名单列表，父类加载器加载
  3. import列表委派给export bundle类加载器加载
  4. 查找Bundler的class path，本人类加载器
  5. 查找本人的Fragmet Bundle
  6. 委派Bundle的类加载加载
  7. 类查找失败

## Java双亲委派模型的挑战

双亲委派机制受到过三次挑战（也能够说是四次），因为双亲委派机制是jdk1.2才退出的，为了向前兼容在过后的为了斗争抉择了一个不太好的实现就是应用findClass()的办法进行了重写，然而这个办法在后续的兼容过程中很快就出了问题，如果有根底类型要回调上层的类比方典型的JNDI服务就是如此，这时候为了兼容又只能不太好的设计就是新增一个线程上下文类加载器，这个加载器能够了解为在启动类加载器做了一个插件，如果用户本人实现了这个插件，就会调用客户的代码，否则就会从父类的加载器中进行继承。

这个线程上下文加载器就是tomcat实现毁坏双亲委派机制的外围。当然不止tomcat，很多框架也有用到这个线程上下文加载器，在类的加载的阶段“做手脚”。

接着对于程序热替换的挑战了，简略来说就是程序的模块化，对于模块化的内容，在《Java8实战》的书籍外面有简略的实践根底探讨，然而如果要深刻模块化，内容有一本书能够来讲，这里也不再赘述对于OSGI和Jisaw的历史了，对于他所做的事件能够看上一个大节。

最初就是Jdk9实现模块化之后的平台类加载器了，这个类加载器基本上算是毁坏了JDK的规定，下文会有具体的介绍，如果简略了解这个类加载器就是把之前始终不太优雅的线程上下文加载器通过底层实现了， 也就是说平台类加载器将能够依据模块定义的类加载器进行自定义的加载操作。

最初简略总结下面的内容如下：

1. Jdk1.2之前旧代码兼容，应用findClass防止对loadClass() 重写2. JNDI 在Thread.setContextClassLoader() 进行设置    jdk6对serialLoader取代后果3. 程序动态性与模块化问题4. 平台加载器毁坏原有类加载规定，线程上下文类加载器的底层兼容实现

## 模块化之后双亲委派模型变动

撇去模块化对于类加载的其余细节，咱们这里间接讲述模块化之后最大的变动：扩大类加载器（Ext）替换为 平台加载器（plaform），次要变动是平台加载器和应用程序加载器不再派生自URLClassLoader ，因为存在BootClassLoader为了兼容旧版的加载器返回null应用下层疏导器这一条件，后果不会返回进去。

JDK 9中尽管依然维持着三层类加载器和双亲委派的架构，但类加载的委派关系也产生了 变动。当平台及应用程序类加载器收到类加载申请，在委派给父加载器加载前，要先判断该类是否能 够归属到某一个零碎模块中，如果能够找到这样的归属关系，就要优先委派给负责那个模块的加载器 实现加载，兴许这能够算是对双亲委派的第四次毁坏？其实从集体看来更像是扭转设计不太优雅的“线程上下文加载器”。

# 总结

本文的内容也比较简单，同样理解即可。重点在于记住双亲委派机制的步骤以及他的工作原理。

# 写在最初

下篇文章将会针对分派的内容进行解说，也是jvm十分重要的一部分，通过分派的学习能够对重载、多态、重写有更多的理解。