动态加载Jar包需用URLClassLoader配合反射实现热插拔，须规范插件Jar（含MANIFEST.MF、无参构造等），注意类加载器隔离与卸载限制，推荐面向接口编程和ServiceLoader机制。
动态加载 Jar 包是实现插件化架构的核心能力之一，关键在于绕过编译期绑定，让主程序在运行时发现、加载并调用外部 Jar 中的类。Java 原生支持这一机制，主要依靠 URLClassLoader 加载字节码，再通过反射（Class.forName、Method.invoke 等）实例化和调用——二者配合，即可完成“热插拔”式扩展。
准备可加载的 Jar 包
插件 Jar 必须满足基本规范，否则加载会失败：
- 包含有效的
META-INF/MANIFEST.MF，推荐声明Main-Class或自定义入口标识（如X-Plugin-Class: com.example.MyPlugin） - 目标类需有无参构造方法（便于反射实例化），或明确暴露工厂方法
- 避免与主程序冲突的依赖（如不同版本的 SLF4J、Jackson），建议插件 Jar 打包为“shaded”或仅含业务逻辑类
- 若需资源访问（如配置文件、模板），确保路径使用
getClassLoader().getResource()，而非绝对路径
用 URLClassLoader 加载 Jar 文件
不同于系统类加载器，URLClassLoader 支持运行时追加 Jar 路径。注意它不自动扫描子目录，需显式构造 URL 数组：
File pluginJar = new File("/path/to/plugin.jar");
URL jarUrl = pluginJar.toURI().toURL();
URLClassLoader classLoader = new URLClassLoader(new URL[]{jarUrl},
Thread.currentThread().getContextClassLoader());
重要细节：
- 第二个参数传入父加载器（通常是上下文类加载器），保证插件能访问主程序已加载的公共 API
- 加载后记得在适当时候调用
classLoader.close()（Java 7+），防止 Jar 文件被锁定（尤其在 Windows 上） - 多次加载同一 Jar 时，应复用或缓存
URLClassLoader实例，避免重复解析和内存泄漏
通过反射调用插件类
加载成功后，用反射获取类、创建实例、执行方法：
Class<?> pluginClass = classLoader.loadClass("com.example.MyPlugin");
Object instance = pluginClass.getDeclaredConstructor().newInstance();
Method execute = pluginClass.getMethod("execute", String.class);
Object result = execute.invoke(instance, "hello from host");
实际工程中建议：
- 定义统一插件接口（如
Plugin），主程序只面向接口编程，避免硬编码类名和方法名 - 用
ServiceLoader机制替代手动反射：在插件 Jar 的META-INF/services/下放接口全限定名文件，写入实现类名，主程序用ServiceLoader.load(Plugin.class, classLoader)获取实例 - 捕获
ClassNotFoundException、NoClassDefFoundError、IllegalAccessException等异常，并提供清晰错误上下文（如报错 Jar 路径、类名），便于调试
隔离与卸载的现实约束
Java 类加载器支持加载，但**标准 JVM 不支持安全卸载已加载的类**。一旦类被某个 ClassLoader 加载，其 Class 对象将长期驻留方法区（元空间），除非整个类加载器被回收。因此：
- 避免频繁创建新
URLClassLoader实例；可设计“插件容器”，每个插件独占一个 ClassLoader，停用时置空引用 + 触发 GC - 确保插件不持有主线程、静态资源、JNI 句柄等外部引用，否则类加载器无法被回收
- 如需真正热更新，需结合 OSGi、JPMS 或第三方框架（如 JPF、Apache Felix），它们在 ClassLoader 层做了深度封装和生命周期管理
不复杂但容易忽略：动态加载不是“把 Jar 放进去就能跑”，而是需要约定接口、管控依赖、处理异常、尊重类加载委托模型。做对这四点，插件化才真正可控。
