这篇文章主要介绍“Java的三次破坏双亲委派模型是什么”，在日常操作中，相信很多人在Java的三次破坏双亲委派模型是什么问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”Java的三次破坏双亲委派模型是什么”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

创新互联公司-专业网站定制、快速模板网站建设、高性价比江津网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式江津网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖江津地区。费用合理售后完善，10多年实体公司更值得信赖。

类加载

我们平常写的代码是保存在一个 .java文件里面，经过编译会生成.class文件，这个文件存储的就是字节码，如果要用上我们的代码，那就必须把它加载到  JVM 中。

当然，加载到 JVM 生成 class 对象的来源不一定得是.class文件，也可以来自网络等等，反正只要是符合 JVM 规范的都行。

而类加载的步骤主要分为：加载、链接、初始化。

加载

其实就是找到字节流，然后将其加载到 JVM 中，生成类对象。这个阶段就是类加载器派上用场的阶段，等下我们再细说。

链接

这个阶段是要让生成的类对象融入到 JVM 中，分别要经历以下三个步骤：

验证就是检验一下加载的类是否满足 JVM 的约束条件，也就是判断是否合规。

准备就是为加载类的静态变量申请内存空间，并赋予初始值，例如是 int 类型那初始值就是 0。

解析就是将符号引用解析成为实际引用，讲人话就是：例如 Yes 类里面引用了一个 XX 类，那一开始 Yes 类肯定不知道 XX  类在内存里面的地址，所以就先搞个符号引用替代一下，假装知道，等类加载解析的时候再找到 XX 类真正地址，做一个实际引用。

这就是解析要做的事情。还有一点，虽说把解析放到链接阶段里面，但是 JVM 规范并没有要求在链接过程中完成解析。

初始化

这个阶段就是为常量字段赋值，然后执行静态代码块，将一堆要执行的静态代码块方法包装成 clinit 方法执行，这个方法会加锁，由 JVM 来保证  clinit 方法只会被执行一次。

所以可以用一个内部静态类来实现延迟初始化的单例设计模式，同时保证了线程安全。

这个阶段完毕之后，类加载过程就 ok 了，可以投入使用啦，再来画个图汇总一下：

双亲委派模型

加载阶段，需要用到类加载器来将 class 文件里面的内容搞到 JVM 中生成类对象。

那什么是双亲委派模型?

双亲委派模型用一句话讲就是子类加载器先让父类加载器去查找该类来加载，父类又继续请求它的父类直到最顶层，在父类加载器没有找到所请求的类的情况下，子类加载器才会尝试去加载，这样一层一层上去又下来。

每个类加载器都有固定的查找类的路径，在 JDK8 的时候一共有三种类加载器。

• 启动类加载器(Bootstrap ClassLoader)，它是属于虚拟机自身的一部分，用 C++  实现的，主要负责加载

  \lib目录中或被 -Xbootclasspath  指定的路径中的并且文件名是被虚拟机识别的文件。它是所有类加载器的爸爸。

• 扩展类加载器(Extension ClassLoader)，它是 Java  实现的，独立于虚拟机，主要负责加载

  \lib\ext目录中或被 java.ext.dirs 系统变量所指定的路径的类库。

• 应用程序类加载器(Application  ClassLoader)，它是Java实现的，独立于虚拟机。主要负责加载用户类路径(classPath)上的类库，如果我们没有实现自定义的类加载器那这玩意就是我们程序中的默认加载器。

为什么要提出双亲委派模型?

其实就是为了让基础类得以正确地统一地加载。

从上面的图可以看出，如果你也定义了一个  java.lang.Object类，通过双亲委派模式是会把这个请求委托给启动类加载器，它扫描\lib目录就找到了 jdk 定义的  java.lang.Object 类来加载，所以压根不会加载你写的 java.lang.Object类，这就可以避免一些程序不小心或者有意的覆盖基础类。

至此我们已经清楚了什么是双亲委派，和为什么要双亲委派。接下来我们来看看三次破坏。

第一次破坏

在 jdk 1.2 之前，那时候还没有双亲委派模型，不过已经有了 ClassLoader 这个抽象类，所以已经有人继承这个抽象类，重写 loadClass  方法来实现用户自定义类加载器。

而在 1.2 的时候要引入双亲委派模型，为了向前兼容， loadClass 这个方法还得保留着使之得以重写，新搞了个 findClass  方法让用户去重写，并呼吁大家不要重写 loadClass 只要重写 findClass。

这就是第一次对双亲委派模型的破坏，因为双亲委派的逻辑在 loadClass 上，但是又允许重写  loadClass，重写了之后就可以破坏委派逻辑了。

第二次破坏

第二次破坏指的是 JNDI、JDBC 之类的情况。

首先得知道什么是 SPI(Service Provider Interface)，它是面向拓展的，也就是说我定义了个规矩，就是 SPI  ，具体如何实现由扩展者实现。

像我们比较熟的 JDBC 就是如此。

MySQL 有 MySQL 的 JDBC 实现，Oracle 有 Oracle 的 JDBC 实现，我 Java  不管你内部如何实现的，反正你们这些数据库厂商都得统一按我这个来，这样我们 Java 开发者才能容易的调用数据库操作，所以在 Java 核心包里面定义了这个  SPI。

而核心包里面的类都是由启动类加载器去加载的，但它的手只能摸到\lib或Xbootclasspath指定的路径中，其他的它鞭长莫及。

而 JDBC 的实现类在我们用户定义的 classpath  中，只能由应用类加载器去加载，所以启动类加载器只能委托子类来加载数据库厂商们提供的具体实现，这就违反了自下而上的委托机制。

具体解决办法是搞了个线程上下文类加载器，通过setContextClassLoader()默认情况就是应用程序类加载器，然后利用Thread.current.currentThread().getContextClassLoader()获得类加载器来加载。

这就是第二次破坏双亲委派模型。

第三次破坏

这次破坏是为了满足热部署的需求，不停机更新这对企业来说至关重要，毕竟停机是大事。

OSGI  就是利用自定义的类加载器机制来完成模块化热部署，而它实现的类加载机制就没有完全遵循自下而上的委托，有很多平级之间的类加载器查找，具体就不展开了，有兴趣可以自行研究一下。

这就是第三次破坏。

第四次破坏

在 JDK9 引入模块系统之后，类加载器的实现其实做了一波更新。

像扩展类加载器被重命名为平台类加载器，核心类加载归属了做了一些划分，平台类加载器承担了更多的类加载，上面提到的  -Xbootclasspath、java.ext.dirs 也都无效了，rt.jar 之类的也被移除，被整理存储在 jimage 文件中，通过新的 JRT  文件系统访问。

当收到类加载请求，会先判断该类在具名模块中是否有定义，如果有定义就自己加载了，没的话再委派给父类。

关于 JDK9 相关的知识点就不展开了，有兴趣的自行查阅。

所以这就是第四次破坏。

其他注意点

首先，虽说是子类父类，但是加载器之间的关系不是继承，而是组合。

看下代码就很清晰了，具体的逻辑如下：

在 JVM 中，类的唯一性是由类加载器实例和类的全限定名一同确定的，也就是说即使是同一个类文件加载的类，用不同的类加载器实例加载，在 JVM  看来这也是两个类。

到此，关于“Java的三次破坏双亲委派模型是什么”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！