打破双亲委派（）SPI+线程上下文

最新推荐文章于 2025-08-11 10:38:58 发布
转载 最新推荐文章于 2025-08-11 10:38:58 发布 · 470 阅读 · 0 ·
CC 4.0 BY-SA版权
原文链接：https://blog.youkuaiyun.com/yangcheng33/article/details/52631940

本文详细解析了如何在优快云上发布一篇技术博客，包括标题、标签和内容的规范，以及如何生成新的标题、摘要、关键词和标签的方法。
破坏双亲委派模型（利用线程上下文类加载器）
weixin_43729854的博客
05-21 853
这里就用JDBC为例来探索一下为何，如何利用 线程上下文类加载器 破坏双亲委派模型。 java给数据库操作提供了一个Driver接口： public interface Driver { Connection connect(String url, java.util.Properties info) throws SQLException; boolean acceptsURL(String url) throws SQLException; Dri
SPI : ServiceLoader如何打破双亲委派
轰鸣
08-28 997
JDK的SPI是怎么打破双亲委派的？
证明SPI打破双亲委派
头发茂密的假程序猿
04-01 2722
1、什么是双亲委派？ 注：此处直接摘抄周志明老师的《深入理解java虚拟机》 ​ 站在Java虚拟机的角度来看,只存在两种不同的类加载器:一种是启动类加载器(Bootstrap ClassLoader),这个类加载器使用C++语言实现[1] ,是虚拟机自身的一部分;另外一种就是其他所有 的类加载器,这些类加载器都由Java语言实现,独立存在于虚拟机外部,并且全都继承自抽象类 java.lang.ClassLoader。 ​ 站在Java开发人员的角度来看,类加载器就应当划分得更细致一些。自JDK 1
为什么说SPI打破双亲委派机制?
kunpeng90的博客
09-01 1955
简单介绍ClassLoader的双亲委派机制: java类通过Classloader加载，Classloader之间有继承关系，AppClassLoader继承ExtClassloader继承BootstrapClassloader。在类加载时，子加载器会调用父加载器来加载类，如果父加载器不能加载类，才会交给子加载器来加载；如果子加载器也加载失败，那么就报异常。 可以看出双亲委派机制是一种至下...
打破双亲委派机制有什么用_为什么说SPI打破双亲委派机制
weixin_39653622的博客
12-21 340
简单介绍ClassLoader的双亲委派机制:java类通过Classloader加载，Classloader之间有继承关系，AppClassLoader继承ExtClassloader继承BootstrapClassloader。在类加载时，子加载器会调用父加载器来加载类，如果父加载器不能加载类，才会交给子加载器来加载；如果子加载器也加载失败，那么就报异常。可以看出双亲委派机制是一种至下而上的加...
【JVM基础篇】打破双亲委派机制
我只管埋头前行，剩下的交给时间。
05-13 3029
本文探讨了Java中双亲委派机制的细节与例外情况，重点解析了三种打破该机制的方式：自定义类加载器重写`loadClass`方法、利用线程上下文类加载器和Osgi框架的类加载机制。以Tomcat为例，展示了如何通过自定义类加载器实现Web应用间类的隔离。同时，文章分析了JDBC中DriverManager如何利用SPI机制和线程上下文类加载器加载驱动，解释了这并不算真正打破双亲委派机制。最后，提到了Osgi框架的历史作用及其热部署能力，并简述了使用Arthas工具在不重启服务情况下更新字节码的热部署流程。。
【从零学习JVM|第五篇】打破双亲委派机制
uybji的博客
06-10 1072
文章摘要：双亲委派机制虽能避免重复加载类并保护核心类库安全，但在实际开发中常需打破以满足业务需求。打破该机制主要为了：1）实现模块化系统中不同版本类库共存；2）解决多应用环境下的类冲突；3）支持动态加载/卸载和热部署；4）满足特殊业务需求。实现方法包括：自定义类加载器重写loadClass方法、使用线程上下文类加载器（如JDBC的SPI机制）以及OSGi框架的"本地优先"加载策略。这些方式突破了传统类加载限制，实现了更灵活的类管理，但需权衡安全性与灵活性。
双亲委派模型的破坏者-线程上下文类加载器
qq_24095055的博客
03-13 699
在Java应用中存在着很多服务提供者接口（Service Provider Interface，SPI），这些接口允许第三方为他们提供实现，如常见的SPI有JDBC、JNDI等，这些SPI的接口属于Java核心库，一般存在rt.jar包中，由bootstrap类加载器加载，而SPI的第三方实现代码则是作为Java应用所依赖的jar包被存放在classpath路径下，由于SPI接口中的代码经常需要加...
JVM-深入浅出 打破双亲委派模型
最新发布
weixin_45226668的博客
08-11 296
JVM-深入浅出 打破双亲委派模型
为什么说java spi破坏双亲委派模型？
大叶子不小的博客
10-09 916
这个问题在之前粗略的了解过，知道有这么回事，也不难理解，但是究其细节，很多点并非足够经得起推敲。现在就来抽丝剥茧梳理一遍。 类加载器（classloader） 先从类加载器说起，凡事先问是什么，首先什么是类加载器？ 我们知道，一个 *.java 的代码源文件要执行起来之前，必须通过 javac 构建抽象语法树并编译成字节码，字节码仍然是不能被机器所识别，那么一个 .class 文件要被机器识别并执行的前提就是将字节码转化成机器码加载到内存里，这一转化过程就是类加载的执行过程。 ...
细说Tomcat如何打破双亲委派(有源码和图)
06-01
NULL 博文链接：https://flyfoxs.iteye.com/blog/2114149
聊聊SPI与API、SPI打破双亲委派的原因
山鬼谣的专栏
03-31 2031
环境 Java 1.8 API想必大家都很熟悉，开发人员，日常开发中干的基本都是API开发。 API 全称：Application Programming Interface 应用程序接口。 类似上图的情形，我们称之为API，规则如下： 服务方提供接口规则，并实现。 调用方需对服务方有依赖引用。 我们现在就基于API思路来，来为JDK设计一套数据库访问的接口，即：我们自己来设计一下JDBC的思路； 我们首先要定义一套数据库的交互接口，接着去实现它，然后开发人员在引入JDK时，就可以开发使用了。 如下
破坏双亲委派机制之SPI
学无止境
01-31 947
我们知道双亲委派模型很好的解决了各个类加载器基础类型的一致性问题，而基础类型往往是被用户代码继承、调用的API存在，但这总设计有时候并不是完美的，比如基础类型又要调用用户的代码，那该怎么办？ 典型的例子就是SPI机制的实现，以JDBC的实现为例。 JDK提供了统一的JDBC驱动接口Driver，各种数据库厂商（MySQL、Oracle等）会根据SPI规范，以jar包形式提供自己的实现。对于实现...
聊聊SPI机制以及为什么说SPI破坏了双亲委派模型
womeiyouzaihuashui的博客
10-11 2957
目录1、前言2、SPI的概念2.1 典型应用：JDBC2.2 SPI机制的通俗理解3、双亲委派模型3.1 双亲委派模型的好处4、为什么说SPI破坏了双亲委派模型4.1 可见性原则4.2 双亲委派模型的妥协5、结尾 1、前言 SPI？一开始接触这个概念大部分人都会很懵，SPI是啥？平时就听过API和SCP（狗头），老夫CRUD这么多年了， 还从来没有听说过Java有这么一个玩意。 然而事实是，你虽然没有听过，但你几乎每天都在享受它给你带来的便利。今天我们就来聊聊这个传说中的SPI机制。 2、SPI的概念 S
java-如何打破双亲委派机制
weixin_41247813的博客
07-22 673
在Java虚拟机（JVM）中，双亲委派模型是一种类加载器之间的层次模型，它定义了类加载的规则，即当一个类需要被加载时，JVM默认的行为是首先请求父类加载器加载该类，只有当父类加载器无法加载该类时，才由自己来加载。1. **SPI（Service Provider Interface）**：Java的SPI机制允许第三方为接口提供实现，而这些实现类通常是由不同的类加载器加载的，如果坚持双亲委派模型，将无法加载这些实现类。- **兼容性**：不同类加载器加载的类可能存在版本不兼容的问题。
SPI机制是如何规避双亲委派机制的？
苦行僧
08-29 525
SPI机制是如何规避双亲委派机制的？
双亲委派和破坏双亲委派SPI
Z先生的博客
12-08 287
一、双亲委派作用 保证每个加载的类在jvm中保持唯一性，也保证系统类（例如Integer，String）在加载时不被串改 二、双亲委派原理 jvm提供三种加载器： 启动类加载器（Bootstrap ClassLoader） C++实现，在java里无法获取，负责加载<JAVA_HOME>/lib下的类。 扩展类加载器（Extension ClassLoader） Java实现，可以在java里获取，负责加载<JAVA_HOME>/lib/ext下的类。 系统类加载器/应用程序类加载
为什么说java的SPI破坏了双亲委派模型
常威打来福
09-23 295
public static <S> ServiceLoader<S> load(Class<S> service) { // 获取线程上下文类加载器 ClassLoader cl = Thread.currentThread().getContextClassLoader(); return ServiceLoader.load(service, cl); } public static <S> ServiceLoader<S
问什么SPI机制会打破双亲委派
07-03
<think>我们正在讨论SPI机制如何打破Java的双亲委派模型。根据引用，双亲委派模型是Java类加载的标准机制，子类加载器会先将类加载请求委托给父类加载器，只有当父类加载器无法完成加载时，子类加载器才会尝试自己加载。这种机制保证了核心类库的安全性（如java.lang包下的类只能由Bootstrap类加载器加载），避免重复加载。然而，SPI（ServiceProvider Interface）场景需要打破这一机制。原因如下： 1. **核心接口与实现类的加载器分离**：SPI的核心接口（如JDBC的java.sql.Driver）通常位于rt.jar中，由Bootstrap类加载器加载。但SPI的实现类（如MySQL的com.mysql.jdbc.Driver）由第三方提供，放在classpath下，应由AppClassLoader加载。2.**父加载器无法委托子加载器**：根据双亲委派模型，父加载器（如Bootstrap）无法将加载请求委托给子加载器（如AppClassLoader）。因此，当核心接口需要加载实现类时，Bootstrap类加载器无法直接加载classpath下的实现类。 3. **SPI的运行时依赖**：在SPI接口的初始化过程中（如DriverManager的静态初始化块），需要主动加载并实例化实现类。例如，JDBC的DriverManager在初始化时会扫描并加载所有META-INF/services/java.sql.Driver文件中指定的驱动实现类。**解决方案：打破双亲委派**- **线程上下文类加载器（Thread ContextClassLoader）**：Java提供了`java.lang.Thread.setContextClassLoader()`方法，允许将一个类加载器绑定到当前线程。在SPI场景中，通常将AppClassLoader设置为线程上下文类加载器。这样，当核心接口（由Bootstrap加载）需要加载实现类时，可以通过当前线程的上下文类加载器（即AppClassLoader）来加载classpath下的实现类[^3][^4]。例如，在DriverManager的初始化代码中：```java//伪代码示例ServiceLoader<Driver> drivers= ServiceLoader.load(Driver.class);//内部实际调用：Thread.currentThread().getContextClassLoader()```- **反向委派**：这实质上是让父加载器（Bootstrap）通过子加载器（AppClassLoader）间接加载实现类，打破了“父到子”的单向委派规则。**总结原因**：SPI打破双亲委派的核心矛盾是：**核心接口由父加载器加载，但实现类必须由子加载器加载，且父加载器需要主动触发对实现类的加载**。若不打破双亲委派，SPI机制无法实现[^3][^5]。 ###相关问题1.线程上下文类加载器的工作原理是什么？2.除了SPI，还有哪些场景需要打破双亲委派模型？ 3.如何自定义类加载器并打破双亲委派？</think>### 为什么 SPI 机制会打破 Java 类加载的双亲委派模型？ SPI（Service Provider Interface）机制打破 Java 双亲委派模型的核心原因在于其**加载方向与双亲委派的单向委托机制存在根本冲突**。具体分析如下： --- #### 一、双亲委派模型的局限性 1. **单向委托规则**： - 子类加载器（如 AppClassLoader）可以委托父类加载器（如 BootstrapClassLoader）加载类 - 但父类加载器**不能反向委托**子类加载器加载类[^2][^3] 2. **核心类加载边界**： - 核心接口（如 JDBC 的 `java.sql.Driver`）由 BootstrapClassLoader 加载（位于 rt.jar） - 第三方实现类（如 MySQL Driver）由 AppClassLoader 加载（位于 classpath）[^3][^4] #### 二、SPI 的加载冲突场景 当核心接口需要加载实现类时（例如 JDBC 的 `DriverManager` 初始化过程）： ```java // DriverManager 静态初始化块中需加载所有 Driver 实现类 ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class); ``` 此时产生矛盾： 1. **加载主体**：`DriverManager` 由 BootstrapClassLoader 加载 2. **加载目标**：`com.mysql.jdbc.Driver` 需由 AppClassLoader 加载 3. **规则限制**：BootstrapClassLoader 无法委托 AppClassLoader（违反双亲委派单向性）[^3][^5] #### 三、打破双亲委派的实现方式 SPI 通过 **线程上下文类加载器（Thread Context ClassLoader）** 解决该问题： 1. **机制**： - 将 AppClassLoader 绑定到当前线程：`Thread.currentThread().setContextClassLoader()` - 核心代码通过线程上下文加载器获取实现类[^4] ```java ClassLoader cl = Thread.currentThread().getContextClassLoader(); ServiceLoader.load(service, cl); // 显式指定类加载器 ``` 2. **加载流程转变**： ```mermaid graph LR A[BootstrapClassLoader] -->|无法加载| B[Driver接口] B -->|调用| C[DriverManager] C -->|通过线程上下文| D[Thread Context ClassLoader] D -->|加载| E[MySQL Driver实现类] ``` 3. **实质突破**： 父加载器（Bootstrap）通过线程上下文**间接调用**子加载器（AppClassLoader），实现了反向加载[^3][^4]。 --- #### 四、根本原因总结 | 机制 | 约束条件 | SPI 需求 | 冲突结果 | |---------------------|----------------------------------|----------------------------------|-----------------------| | 双亲委派 | 父加载器不能委托子加载器 | 父加载器需加载子加载器的类 | 必须打破委派规则 | | 核心类隔离 | Bootstrap 不加载 classpath 类 | 核心接口需调用 classpath 实现类 | 需要跨加载器协作 | 这种设计是 Java 生态的**主动妥协**：在保证核心库安全性的前提下，通过可控方式突破加载限制，实现服务扩展的灵活性[^4][^5]。 --- ### 相关问题 1. 线程上下文类加载器在 SPI 中具体如何工作？ 2. 除了 SPI，还有哪些场景需要打破双亲委派模型？ 3. 如何自定义类加载器实现 SPI 扩展？ 4. 打破双亲委派模型会带来哪些安全隐患？
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值