双亲委派被打破的典型信号是noclassdeffounderror或classnotfoundexception发生在同一类名、不同模块间；本质是当前classloader找不到类而父加载器却有，需检查加载器链及osgi的import-package声明。
双亲委派被打破的典型信号：NoClassDefFoundError 或 ClassNotFoundException 发生在同一个类名、不同模块间
当你看到同一个 com.example.Service 类，在插件 A 里能加载，在插件 B 里却报 NoClassDefFoundError，且堆栈里出现多个 URLClassLoader 或 BundleClassLoader，基本就是双亲委派被主动绕过了。OSGi 和热加载框架（如 JRebel、自研插件系统）都依赖这个“打破”来实现类隔离——不是 bug，是 feature。
关键判断点：错误不是因为类根本不存在，而是「当前 ClassLoader 找不到它，但父加载器明明有」。这时候别急着加 -classpath，先查加载器链。
- 用
Thread.currentThread().getContextClassLoader()打印实际生效的加载器 - 检查该加载器的
getParent()是否真的指向了预期的父级（比如AppClassLoader） - OSGi 中优先看
BundleWiring.listResources("com/example/", true)确认类是否真在该 bundle 的 classpath 内
OSGi 中如何安全绕过双亲委派：靠 Import-Package 和 DynamicImport-Package
OSGi 不是粗暴地禁用双亲委派，而是用元数据声明替代硬编码委托。每个 bundle 的 META-INF/MANIFEST.MF 决定它“想从哪找类”，而不是“让父加载器无条件代劳”。
-
Import-Package: com.google.gson; version="[2.8,3)"→ 显式声明依赖，由 framework 在启动时解析并绑定提供方 bundle -
DynamicImport-Package: *→ 慎用！仅用于反射调用未知包（如 JSON 序列化任意 POJO），会破坏模块边界，导致类加载冲突 - 不写
Import-Package却直接 new 某个类？那就会 fallback 到 parent classloader —— 这时双亲委派“被动生效”，反而可能加载到旧版本类
常见坑：Require-Bundle 看似方便，但会强耦合 bundle 生命周期；一旦被依赖 bundle 停止，当前 bundle 的类加载直接失败，比 Import-Package 更难诊断。
立即学习“Java免费学习笔记（深入）”；
热加载插件中自定义 ClassLoader 的致命陷阱：defineClass 后没清理旧实例
自己写 URLClassLoader 子类做热替换时，defineClass 成功不代表旧类就消失了。JVM 里旧 Class 对象仍被静态字段、线程栈、JNI 引用持有，GC 不掉 —— 这就是内存泄漏和 OutOfMemoryError: Metaspace 的根源。
- 必须确保所有对该类的强引用（尤其是单例、缓存、监听器注册）在 reload 前被显式清除
- 避免在
static块里初始化任何跨插件状态；改用BundleActivator.start()或插件自己的生命周期回调 - 调试技巧：用
jcmd <pid> VM.native_memory summary</pid>观察 metaspace 增长，配合jmap -histo:live <pid></pid>查残留类实例数
注意：URLClassLoader.close() 只关闭资源，不卸载已加载类 —— JVM 层面没有“卸载类”的 API，只能靠 GC 回收整个 ClassLoader 及其加载的所有类，前提是没任何引用残留。
为什么 Thread.setContextClassLoader 是热加载最常用也最危险的开关
很多框架（Spring Boot DevTools、MyBatis、甚至 JDBC 驱动）默认用 Thread.currentThread().getContextClassLoader() 加载资源或类。你一换插件 ClassLoader，又忘了设回上下文，下游就全乱套。
- 在插件执行入口（如
PluginExecutor.run()）开头必须Thread.currentThread().setContextClassLoader(pluginClassLoader) - 执行完立刻 restore 原来的 CL，最好用 try-finally 或 try-with-resources 封装
- 异步任务（
CompletableFuture、线程池）默认继承提交线程的上下文 CL —— 如果你在主线程设了 plugin CL，又 submit 到共享线程池，其他插件的代码可能意外使用这个 CL，引发类冲突
真正麻烦的不是设不设，而是设在哪、何时恢复、谁负责清理。一个没 restore 的 setContextClassLoader 能让整个 JVM 后续所有动态加载行为不可预测。
