因为系统类加载器在JVM启动时已固定classpath，无法感知运行时新增的插件JAR；而上下文类加载器可动态替换为能读取插件路径的URLClassLoader，从而实现插件类的正确加载与初始化。
为什么不能直接用 ClassLoader.getSystemClassLoader() 加载插件
系统类加载器（ClassLoader.getSystemClassLoader()）在 JVM 启动时就固定了 classpath，它看不到运行时才出现的插件 JAR 文件。如果你把插件放在 plugins/xxx.jar 下，直接用它去 loadClass() 会抛 ClassNotFoundException —— 不是类写错了，是加载器压根没扫描那个路径。
而 Thread.currentThread().getContextClassLoader() 是线程绑定的、可动态替换的加载器，插件框架（比如 OSGi、Java SPI 或自研热插拔模块）通常会在执行插件逻辑前，用 Thread.setContextClassLoader() 切换为一个能读取插件目录的 URLClassLoader。所以它才是“当前上下文里知道插件在哪”的那个加载器。
如何构造并设置能加载插件的 ContextClassLoader
你得自己创建一个 URLClassLoader，把插件 JAR 的 File.toURI().toURL() 加进去，再设给当前线程。注意：JDK 9+ 默认禁止反射访问 URLClassLoader.addURL()，所以必须在构造时一次性传入全部 URL。
- 确保插件 JAR 路径存在且可读，否则
new URL(file.toURI())会抛MalformedURLException - 不要复用已关闭的
URLClassLoader，它内部的ucp（URLClassPath）会被标记为 closed，后续loadClass()直接返回 null - 如果插件有依赖（比如用了 commons-lang3），要把依赖 JAR 也加进
urls列表，或让插件 JAR 自己带Class-Path清单项（需启用URLClassLoader的 manifest 解析，但默认不开启）
示例：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
File pluginJar = new File("plugins/my-plugin-1.0.jar");
URL pluginUrl = pluginJar.toURI().toURL();
URLClassLoader pluginCl = new URLClassLoader(new URL[]{pluginUrl},
Thread.currentThread().getContextClassLoader());
Thread.currentThread().setContextClassLoader(pluginCl);
// 后续调用 Class.forName("com.example.PluginMain") 就走这个 loader
Class.forName() 和 ClassLoader.loadClass() 的行为差异
两者都可能触发类初始化，但关键区别在于：如果用 Class.forName("X", true, cl)，JVM 会主动执行 X 的静态块；而 cl.loadClass("X") 默认不初始化（第二个参数 resolve 默认 false）。插件入口类通常靠静态块注册服务或初始化状态，所以漏掉 true 参数会导致“类加载成功但啥也没发生”。
- 推荐显式调用
Class.forName(className, true, cl)，避免隐式依赖上下文类加载器的行为 - 不要依赖
Thread.currentThread().getContextClassLoader()在Class.forName(String)单参数重载中自动生效 —— 它只在无指定 loader 时 fallback 使用，不可控 - 若插件类实现了某个接口（如
Plugin），转型前务必确认类型兼容性：clazz.asSubclass(Plugin.class)比直接(Plugin) instance更安全
卸载插件时 ContextClassLoader 的清理陷阱
很多人以为把 Thread.currentThread().setContextClassLoader(null) 就算清理完了，其实不是。JVM 不会回收仍在使用的 URLClassLoader 实例，它的 urls 数组和底层 jarFile 句柄会一直占着内存和文件锁 —— 特别是在 Windows 上，删不了正在被加载的 JAR 文件。
- 调用
pluginCl.close()（JDK 7+）才能释放资源；但要注意：close 后该 loader 不可再用于loadClass() - 如果插件启动了后台线程（比如监听端口），这些线程的 context classloader 仍是旧的
pluginCl，必须在线程退出前手动切换回父 loader，否则造成内存泄漏 - 更稳妥的做法是：插件执行完后，恢复到原始 context classloader（保存一份引用），而不是设为 null
容易被忽略的一点：URLClassLoader 关闭后，其 parent（比如 AppClassLoader）不会自动接管已加载的类，那些类实例仍持有对原 loader 的引用 —— 所以真正卸载插件，还得配合弱引用缓存 + 显式清空静态字段。
