父加载器启动的线程默认使用父类加载器作为上下文类加载器，无法访问子加载器加载的类；解决关键是在线程执行业务逻辑前显式设置子加载器为上下文类加载器，并避免跨加载器传递Class实例。
这个问题的核心在于：父加载器创建的线程默认使用父加载器作为上下文类加载器（Context ClassLoader），而它天然无法访问子加载器命名空间里的类——这不是加载失败，而是可见性被JVM主动切断。要解开这个“死结”，关键不是让父加载器去“找”子类，而是让需要加载业务类的代码在正确的类加载器上下文中执行。
明确线程上下文类加载器的作用边界
每个线程都有一个 Thread.currentThread().getContextClassLoader()，它独立于当前代码所在类的类加载器。框架（如 Spring、JDBC、JNDI）在动态加载服务时，普遍依赖它来定位类。如果父加载器（如 AppClassLoader）启动了线程，但没显式设置上下文加载器，那该线程就“看不见”子加载器（如 WebAppClassLoader 或自定义 PluginClassLoader）加载的任何业务类。
- 验证方式：在线程内打印 Thread.currentThread().getContextClassLoader() 和目标业务类的 clazz.getClassLoader()，两者不一致就是根源
- 典型表现：调用 Class.forName("com.mybiz.Service") 报 ClassNotFoundException，但同一段代码放在子加载器的 Servlet 或 Plugin 初始化块中就能成功
在子加载器作用域内主动设置上下文加载器
子加载器拿到控制权后，必须在触发业务逻辑前，把自身设为当前线程的上下文加载器。这不是可选项，是打破死结的必要动作。
- 在 Web 场景中，Tomcat 的 WebAppClassLoader 会在每个请求线程进入 Filter/Servlet 前自动设置上下文加载器——你只需确保没在中间件层意外重置它
- 在插件或模块化系统中，启动业务线程时应包裹一层设置逻辑：
Thread t = new Thread(() -> {
Thread.currentThread().setContextClassLoader(pluginLoader);
// 此处再调用 Class.forName 或反射初始化
}); - 若使用线程池（如 ExecutorService），需配合 ThreadFactory 统一注入上下文加载器，避免每次手动设置
避免跨加载器直接传递 Class 或实例引用
即使通过上下文加载器成功加载了类，若将该 Class 对象或其实例传给父加载器环境中的代码（比如回调、监听器、静态工具类），仍可能触发 ClassCastException 或方法不可见——因为 JVM 视其为两个完全不同的类型。
- 推荐做法：用字符串类名 + 反射调用，或统一通过接口契约通信（接口由父加载器提供，实现类由子加载器加载并代理调用）
- 例如定义 ServiceInvoker 接口在 common.jar（由 AppClassLoader 加载），子模块实现该接口，并通过上下文加载器加载实现类后，只暴露接口引用给上层
- 慎用序列化或 RMI 跨加载器传递对象，它们会因类定义不匹配而失败
检查是否误用双亲委派破坏隔离前提
有些自定义加载器试图“优化”加载路径，比如在 findClass() 中 fallback 到父加载器，结果导致本该隔离的业务类被提前加载进 AppClassLoader，后续子加载器再加载同名类就会失败（LinkageError）。
- 真正隔离的加载器必须重写 loadClass(String, boolean)，对业务包路径直接 defineClass，跳过 super.loadClass
- 仅重写 findClass() 不够——父加载器仍会先尝试加载，一旦命中（比如碰巧有同名类在 classpath），子加载器就彻底失去机会
- 确认子加载器的 parent 字段正确指向 AppClassLoader（而非 null 或错误实例），否则委派链断裂会导致基础类（如 java.lang.Object）找不到
