jdbc通过线程上下文类加载器（tccl）绕过双亲委派限制，实现bootstrap加载的drivermanager发现appclassloader加载的驱动类；核心是serviceloader主动使用tccl加载meta-inf/services/java.sql.driver中声明的实现类，而非修改类加载机制本身。
JDBC 利用线程上下文类加载器（TCCL）“打破”双亲委派，并不是真正废除了该机制，而是巧妙绕过其限制，在不改动模型的前提下实现跨层级类可见——核心在于换加载器，而非改逻辑。
JDBC 的类加载矛盾在哪？
Java 标准 JDBC 接口（如 java.sql.Driver、Connection）定义在 rt.jar（Java 9+ 为 java.base 模块），由启动类加载器（Bootstrap ClassLoader）加载；而 MySQL、PostgreSQL 等驱动实现类（如 com.mysql.cj.jdbc.Driver）打包在应用的 classpath 中，只能由系统类加载器（Application ClassLoader）加载。
按双亲委派规则：Bootstrap 加载器无法委托子加载器，也“看不见”子加载器加载的类。于是问题来了：DriverManager（Bootstrap 加载）怎么找到并实例化用户写的驱动类（AppClassLoader 加载）？
TCCL 是怎么“绕开”这个限制的？
TCCL 不是新加载器，而是线程上一个可设置的类加载器引用，默认值就是当前线程所属类的加载器（通常是 AppClassLoader）。JDBC 的关键动作发生在 ServiceLoader.load() 阶段：
-
DriverManager在初始化时，调用ServiceLoader.load(java.sql.Driver.class)； -
ServiceLoader不用自己类的加载器（Bootstrap），而是主动读取Thread.currentThread().getContextClassLoader()； - 该 TCCL 默认指向 AppClassLoader，能顺利定位到
META-INF/services/java.sql.Driver文件，并加载其中声明的驱动类（如com.mysql.cj.jdbc.Driver）； - 加载成功后，通过反射注册驱动，后续
getConnection()就能基于接口多态拿到具体实现。
为什么说这不是“彻底打破”，而是一种约定式协作？
TCCL 本身不改变双亲委派行为，它只是把一个“能访问应用类”的加载器传递给框架：
- AppClassLoader 自身仍严格遵循双亲委派：先查父加载器，找不到再自己加载 —— 它本就能加载 classpath 下的驱动类；
- 真正突破点在于：
DriverManager（Bootstrap 加载）放弃了用自己的类加载器去查驱动，转而信任线程上下文； - 这种协作依赖 Java SPI 规范约定：所有 JDBC 驱动必须在 jar 包中提供
META-INF/services/java.sql.Driver，且 ServiceLoader 必须使用 TCCL 加载。
动手验证一下关键事实
运行以下代码可直观看到类加载器分离现象：
System.out.println("DriverManager: " + DriverManager.class.getClassLoader()); // null（Bootstrap）
System.out.println("Driver: " + Driver.class.getClassLoader()); // null（Bootstrap）
System.out.println("Connection: " + Connection.class.getClassLoader()); // null（Bootstrap）
System.out.println("MySQL Driver: " + com.mysql.cj.jdbc.Driver.class.getClassLoader()); // AppClassLoader
System.out.println("TCCL: " + Thread.currentThread().getContextClassLoader()); // sun.misc.Launcher$AppClassLoader
输出会明确显示：接口与实现分属不同加载器层级，而 TCCL 正是连接二者的关键桥梁。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
