不能彻底打破双亲委派机制。contextclassloader仅是传递通道，是否打破取决于所设自定义类加载器是否重写loadclass()并改变委托逻辑，而非其自身能力。
不能通过 Thread.currentThread().getContextClassLoader() 彻底打破双亲委派机制。
ContextClassLoader 本质仍是双亲委派链上的一环
它本身不是独立的类加载器，而是一个可被显式设置的引用，默认指向当前线程所属类的 ClassLoader（通常是应用类加载器）。即使你手动设为自定义类加载器，该加载器在加载类时仍会遵循自己的双亲委派逻辑——除非你重写了 loadClass() 方法并绕过 super.loadClass()。
真正“打破”的动作发生在自定义 ClassLoader 内部
ContextClassLoader 只是提供了一个传递通道，把一个非默认的类加载器“塞”给框架或库（如 JNDI、JAXB、SPI 服务加载等），让它们用这个加载器去加载资源。是否打破双亲委派，取决于这个被传入的类加载器自己怎么实现 loadClass()：
- 若它直接委托父加载器（默认行为），那就没打破；
- 若它先尝试自己 defineClass，失败再委托父类（即“逆向查找”），才算局部打破；
- 若它完全不调用
super.loadClass()，而是全部自己加载（含java.*以外的类），则属于彻底绕过——但这是危险且不推荐的，可能引发LinkageError或类重复加载问题。
典型打破场景依赖的是“约定”，而非 ContextClassLoader 自身能力
比如 JDBC 驱动加载：ServiceLoader 使用 Thread.currentThread().getContextClassLoader() 查找 META-INF/services/java.sql.Driver，再用它加载驱动类。这里能加载到 mysql-connector-java 中的实现类，是因为该 jar 包在应用 classpath 下，而上下文类加载器（AppClassLoader）本就能加载它——仍是双亲委派在工作。真正的“突破点”在于：它没有用当前类（如 DriverManager）的类加载器（Bootstrap 或 Extension）去加载，而是换成了能访问应用类的加载器。
想控制加载逻辑？重点不在 setContextClassLoader，而在定制 ClassLoader
如果你需要特定类由特定加载器加载（例如热部署、模块隔离），应：
- 继承
ClassLoader，重写loadClass(String, boolean)，调整委托顺序（如先本地后父类）； - 确保重写中正确处理
findClass()和defineClass()； - 必要时在关键位置（如 new Thread 时、框架初始化前）调用
Thread.currentThread().setContextClassLoader(yourLoader)； - 注意线程上下文类加载器不会自动继承给子线程，需显式传递。
ContextClassLoader 是一个桥梁，不是扳手。打破双亲委派的关键，在于你放进桥另一端的那个类加载器是怎么写的。
