先别急着写代码这个需求背后藏着几个很关键的设计决策。你拿到一个Spring动态加载.java文件代码(插件开发)的标题第一反应可能是这不就是用反射加URLClassLoader加载个jar吗但等真上手就会发现动态编译、类加载隔离、Spring容器注册、热卸载每一步都能卡你半天。尤其是加载.java这个字眼意味着你得在运行期自己把源码编译成字节码再想办法把它变成Spring容器里真正可用的Bean。这篇文章我把整套链路拆开讲清楚从JVM编译API到类加载器再到容器注册一步步带你把一个可运行、可热替换的Spring插件管理器搭出来。1. 插件为什么非要动态加载 Java 源码1.1 从业务场景说起先想一个问题什么样的系统会需要动态加载插件我见过最典型的场景有两种。一种是平台型产品。交付给客户之后客户业务部门隔三差五提需求审批流里加一个特殊判定逻辑、报价单里按某条规则计算折扣、数据导入时做一次自定义清洗。这些逻辑说大不大说小不小如果每次都发版走CI/CD流程一个需求拖两周很正常。如果能允许业务方直接上传一段Java代码系统运行期编译并加载进去当天就能生效交付体验完全不一样。另一种是规则频繁变化的内部系统。比如风控、计费、消息路由这类场景规则引擎用表达式脚本有时候表达力不够但完整发版又太重。把变化的部分抽象成插件接口让维护人员编辑Java源文件系统监听文件变更后自动重新加载这是很多团队实际会采用的折中方案。这里有个看似绕路的选择值得先说清楚既然是运行期改逻辑为什么要选择编译Java源码而不是直接用Groovy脚本Groovy语法兼容Java还能直接跑脚本理论上更省事。但真实情况是Groovy在JVM里要额外维护一个GroovyClassLoader每次脚本变更都会产生新的类定义长期运行同样会踩元空间泄漏的问题而且Groovy依赖本身在不少偏保守的企业项目里是不允许引入的。相比之下JDK原生自带的javax.tools.JavaCompiler可以零额外依赖完成源码编译项目组对Java语法和编译错误的处理也更熟悉。1.2 为什么不是 Class 文件、不是 jar有人会问既然都编译了为什么不让业务方直接上传编译好的.class文件或者jar包这里面有个很现实的问题你在服务器上拿到的.class文件大概率跟你本地JDK版本编译出来的字节码不是一回事。业务方开发机上JDK17编译的class放到你JDK11的运行环境上轻则UnsupportedClassVersionError重则因为某些依赖版本不一致直接NoSuchMethodError。而接收.java源文件由服务端用自己环境的JDK编译字节码版本、依赖引用都以服务端为准兼容性问题被压缩到最小。jar包则面临另一个麻烦一旦允许上传jar你实际上就开放了一个类库依赖的入口。这个jar里依赖了什么版本的第三方库、是否会跟宿主应用的类冲突、里面有没有一些不该有的东西这些全都需要管控。而单文件.java把依赖边界限制在编译classpath内宿主给什么依赖插件才能用什么依赖控制面清晰很多。1.3 适用边界不过这事也不是万能的。动态加载Java源码有几个难以回避的局限语法错误和大部分依赖缺失问题要等运行期编译时才会暴露没法像静态代码一样在发版阶段被CI兜住。插件代码如果写得烂死循环、内存泄漏、跑飞线程宿主进程会跟着遭殃。Java没有真正意义上的代码沙箱这个问题只能靠制度和代码审查缓解。基于自定义类加载器的热卸载不是完全无痕静态变量、后台线程、资源句柄都是泄漏点后面专门有一节讲排查链路。所以这个方案的适用边界大概是你需要运行期扩展业务逻辑但你信任写插件的人或者有代码评审和灰度机制兜底。如果完全不可信那不应该用这个方案应该考虑独立进程隔离。2. 运行期编译与类加载的核心机制动手写代码之前先把三个核心机制理清楚。这三块拼起来才是完整的插件加载器缺一个都会在运行期出幺蛾子。2.1 javax.tools.JavaCompilerJDK 自带的编译入口javax.tools.JavaCompiler是JDK 1.6就有的编译API平时写代码的人基本用不上但做动态编译它是最正统的选择。它的工作方式跟命令行javac一致核心几个对象JavaCompiler编译器入口通过ToolProvider.getSystemJavaCompiler()获取StandardJavaFileManager负责管理源文件和编译产物的输入输出Iterable? extends JavaFileObject编译单元的集合一个JavaFileObject对应一个源文件CompilationTask一次编译任务DiagnosticCollector收集编译错误和警告一个最常见的用法是JavaCompiler compiler ToolProvider.getSystemJavaCompiler(); if (compiler null) { throw new IllegalStateException(未找到系统编译器请使用完整JDK运行); } StandardJavaFileManager fileManager compiler.getStandardFileManager(null, null, null); Iterable? extends JavaFileObject units fileManager.getJavaFileObjectsFromFiles( Collections.singletonList(sourceFile) ); ListString options new ArrayList(); options.add(-d); options.add(outputDir.getAbsolutePath()); if (classpath ! null !classpath.isEmpty()) { options.add(-classpath); options.add(classpath); } DiagnosticCollectorJavaFileObject diagnostics new DiagnosticCollector(); JavaCompiler.CompilationTask task compiler.getTask( null, fileManager, diagnostics, options, null, units ); boolean success task.call(); fileManager.close(); if (!success) { for (Diagnostic? extends JavaFileObject d : diagnostics.getDiagnostics()) { System.err.println(d.getMessage(null)); } throw new IllegalStateException(插件源码编译失败); }这里有一个非常多人踩的坑ToolProvider.getSystemJavaCompiler()只有在完整的JDK环境下才会返回非null。如果你的应用跑在一个纯JRE里或者Spring Boot是用jre裁剪过的镜像启动的这个API会直接返回null。我在生产环境排查过一次发现运维把程序跑在了一个只有JRE的精简容器里编译插件时直接抛NPE查了半天才发现JDK压根不在。2.2 自定义类加载器打破双亲委派编译产物只是一堆.class字节码放在磁盘上要把它变成JVM里可用的Class对象必须经过类加载器。JVM默认的类加载机制是双亲委派一个类加载器接到加载请求先委托给父加载器父加载器找不到才自己加载。这个设计的目的是保证核心类库比如java.lang.String永远由启动类加载器加载不会出现多个版本的混乱。但插件场景恰恰需要打破这种默认行为。原因很直接如果不同版本的同一个插件类都被父加载器优先加载了那就永远只有一个版本生效热替换根本无从谈起。所以插件类必须由我们自己创建的、独立的ClassLoader实例来加载——每个插件版本对应一个新的类加载器实例旧版本被替换后旧的类加载器连同它加载的类一起可以被GC回收。自定义类加载器的核心代码长这样public class DynamicClassLoader extends ClassLoader { private final MapString, byte[] classBytes new ConcurrentHashMap(); public DynamicClassLoader(ClassLoader parent) { super(parent); } public void putClass(String className, byte[] bytes) { this.classBytes.put(className, bytes); } Override protected Class? findClass(String name) throws ClassNotFoundException { byte[] bytes classBytes.get(name); if (bytes ! null) { return defineClass(name, bytes, 0, bytes.length); } return super.findClass(name); } Override protected Class? loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { // 本加载器管理的类优先加载避免父加载器抢先加载了旧版本 Class? c findLoadedClass(name); if (c null classBytes.containsKey(name)) { c findClass(name); } if (c null) { c super.loadClass(name, false); } if (resolve) { resolveClass(c); } return c; } } }注意这个loadClass的覆写。如果只覆写findClass那么类加载器在执行loadClass(com.example.MyPlugin)时会先走上层的ClassLoader.loadClass逻辑它内部是先委托父加载器。假设父加载器应用的ClassLoader里恰好有个同名的com.example.MyPlugin旧版本就会被返回你的新类永远没机会加载。所以我在覆写时做了一个判断只要classBytes里有这个类名就直接从本加载器加载。这就是打破双亲委派在插件场景下的具体做法。2.3 Spring 容器动态注册 Bean 的原理Class被加载出来了实例也能new了但这时候它还只是一个普通的Java对象跟Spring容器没关系。要让Autowired、Transactional这些注解在插件里生效让别的Bean能Autowired注入这个插件必须把插件实例注册进Spring容器。Spring容器的底层是DefaultListableBeanFactory它同时实现了BeanDefinitionRegistry和SingletonBeanRegistry。所以容器注册Bean本质上就两个入口registerBeanDefinition(String beanName, BeanDefinition beanDefinition)注册Bean的定义后续由容器实例化、注入、初始化registerSingleton(String beanName, Object singletonObject)直接注册一个现成的单例对象我们这里的情况比较特殊插件实例是我们自己通过反射创建出来的而且它的宿主类不在容器的默认类加载器可见范围内。所以不能直接注册一个Class让容器去实例化而是要把现成的实例交给容器管理。推荐的做法是GenericApplicationContext.registerBeanGenericApplicationContext context (GenericApplicationContext) applicationContext; context.registerBean(beanName, Plugin.class, () - pluginInstance);这里注册的bean定义类型是Plugin接口Supplier返回的是已经创建好的插件实例。这样做的好处是Bean定义存在了容器里其他组件可以通过Plugin接口类型按名字注入或查找同时我们也绕开了容器直接实例化自定义类加载器里的类这个容易出问题的环节。因为如果直接registerBeanDefinition传插件的ClassDefaultListableBeanFactory在解析ResolvableType时会对Class做一些处理而自定义类加载器加载的Class在跨加载器边界时很容易触发一些莫名其妙的问题。3. 手写一个可运行的动态插件加载器理论部分说清楚了下面把完整实现过一遍。我会尽量把代码写全保证你照着敲完能跑起来。3.1 定义插件契约先定义一个所有插件都必须实现的接口这是宿主和插件之间的合同public interface Plugin { String getName(); void start(); void stop(); }getName()用于在宿主侧标识插件start()是插件的初始化入口比如启动定时任务、加载配置stop()是停用入口用于释放资源。接口越简单越好复杂接口会提高插件的编写门槛。3.2 动态编译把 .java 变成字节码动态编译工具类我包装一下输入源文件路径和输出目录输出编译结果。核心还是上节那段代码这里加上编译失败时输出诊断信息的功能方便定位问题public class DynamicCompiler { public static void compile(File sourceFile, File outputDir, String classpath) throws IOException { if (!sourceFile.exists()) { throw new IllegalArgumentException(源码文件不存在: sourceFile); } Files.createDirectories(outputDir.toPath()); JavaCompiler compiler ToolProvider.getSystemJavaCompiler(); if (compiler null) { throw new IllegalStateException(当前JVM没有提供JavaCompiler请使用完整JDK启动应用); } DiagnosticCollectorJavaFileObject diagnostics new DiagnosticCollector(); try (StandardJavaFileManager fileManager compiler.getStandardFileManager(diagnostics, null, null)) { Iterable? extends JavaFileObject units fileManager.getJavaFileObjectsFromFiles( Collections.singletonList(sourceFile) ); ListString options new ArrayList(); options.add(-d); options.add(outputDir.getAbsolutePath()); if (StringUtils.hasText(classpath)) { options.add(-classpath); options.add(classpath); } options.add(-encoding); options.add(UTF-8); JavaCompiler.CompilationTask task compiler.getTask( null, fileManager, diagnostics, options, null, units ); boolean success task.call(); if (!success) { StringBuilder errorMsg new StringBuilder(插件编译失败: ); for (Diagnostic? extends JavaFileObject d : diagnostics.getDiagnostics()) { errorMsg.append(\n).append(d.getKind()).append(: ) .append(d.getMessage(null)) .append( at line ).append(d.getLineNumber()) .append(, column ).append(d.getColumnNumber()); } throw new IllegalStateException(errorMsg.toString()); } } } }编译产物默认输出到outputDir目录结构按包名自动分好。下一步就要从这个目录里把.class字节码读出来喂给自定义类加载器。3.3 把编译产物装载进类加载器编译完成之后遍历输出目录把所有.class文件的字节码读出来写入DynamicClassLoaderpublic class PluginClassLoader extends DynamicClassLoader { public PluginClassLoader(ClassLoader parent) { super(parent); } public void loadClassDirectory(File classDir) throws IOException { ListPath classFiles; try (StreamPath stream Files.walk(classDir.toPath())) { classFiles stream.filter(p - p.toString().endsWith(.class)).toList(); } for (Path classFilePath : classFiles) { String className classDir.toPath().relativize(classFilePath) .toString() .replace(File.separatorChar, .) .replace(/, .); className className.substring(0, className.length() - .class.length()); byte[] bytes Files.readAllBytes(classFilePath); putClass(className, bytes); } } }这里我特意把类名计算成一个包名加类名的完整形式对应putClass的key。注意相对路径在不同操作系统下分隔符可能不一样统一替换成.拼接类名这个细节在Windows上跑很容易疏忽。3.4 PluginManager编译-加载-注册-初始化的完整编排核心管理器负责统筹整个流程。它需要拿到ApplicationContext并把上下文转成GenericApplicationContext来调用动态注册APIService public class PluginManager implements ApplicationContextAware { private GenericApplicationContext applicationContext; private final MapString, PluginRuntime plugins new ConcurrentHashMap(); public static class PluginRuntime { private PluginClassLoader classLoader; private Class? pluginClass; private Plugin instance; private File classDir; } Override public void setApplicationContext(ApplicationContext applicationContext) throws BeansException { this.applicationContext (GenericApplicationContext) applicationContext; } public synchronized void loadPlugin(String beanName, String pluginClassName, File sourceFile) { unloadPlugin(beanName); try { // 1. 生成独立类加载器 PluginClassLoader classLoader new PluginClassLoader( Thread.currentThread().getContextClassLoader() ); // 2. 编译 File classDir Files.createTempDirectory(plugin-class- beanName).toFile(); DynamicCompiler.compile(sourceFile, classDir, buildClassPath()); // 3. 加载类 classLoader.loadClassDirectory(classDir); Class? pluginClass classLoader.loadClass(pluginClassName); // 4. 创建实例 Object rawInstance pluginClass.getDeclaredConstructor().newInstance(); // 5. 执行Spring依赖注入和Bean初始化 AutowireCapableBeanFactory beanFactory applicationContext.getAutowireCapableBeanFactory(); Object initialized beanFactory.initializeBean(rawInstance, beanName); Plugin instance (Plugin) initialized; // 6. 注册进Spring容器 applicationContext.registerBean(beanName, Plugin.class, () - instance); // 7. 启动插件 instance.start(); PluginRuntime runtime new PluginRuntime(); runtime.classLoader classLoader; runtime.pluginClass pluginClass; runtime.instance instance; runtime.classDir classDir; plugins.put(beanName, runtime); log.info(插件加载成功: {} - {}, beanName, pluginClassName); } catch (Exception e) { throw new RuntimeException(插件加载失败: pluginClassName, e); } } public synchronized void unloadPlugin(String beanName) { PluginRuntime runtime plugins.remove(beanName); if (runtime null) { return; } try { runtime.instance.stop(); } catch (Exception e) { log.warn(插件{}停止时发生异常, beanName, e); } ConfigurableListableBeanFactory beanFactory applicationContext.getDefaultListableBeanFactory(); if (beanFactory.containsBeanDefinition(beanName)) { beanFactory.removeBeanDefinition(beanName); } if (beanFactory.containsSingleton(beanName)) { beanFactory.destroySingleton(beanName); } // 手动解除强引用让类加载器和类可以被GC回收 runtime.instance null; runtime.pluginClass null; runtime.classLoader null; log.info(插件已卸载: {}, beanName); } private String buildClassPath() { StringBuilder cp new StringBuilder(System.getProperty(java.class.path, )); ClassLoader cl Thread.currentThread().getContextClassLoader(); if (cl instanceof URLClassLoader urlClassLoader) { for (URL url : urlClassLoader.getURLs()) { String path url.getPath(); if (cp.indexOf(path) 0) { cp.append(File.pathSeparator).append(path); } } } return cp.toString(); } }第5步值得单独说明一下。initializeBean这个方法是Spring Bean生命周期里非常核心的一环它会执行BeanPostProcessor#postProcessBeforeInitializationPostConstruct标注的初始化方法InitializingBean#afterPropertiesSetBeanPostProcessor#postProcessAfterInitialization也就是说调用initializeBean之后插件类里如果用Resource、Autowired、Value标注的字段才真正被填充这一步其实在applyBeanPropertyValues阶段做实际initializeBean内部会先执行populateBean这里我简化了流程组合直接用initializeBean覆盖了依赖注入和初始化回调Transactional这类AOP代理也会在这个时候生成并返回代理对象。所以第5步拿到的initialized不一定等于rawInstance必须用返回值继续后面的流程。另外注意第6步registerBean注册的是接口类型Plugin的BeanDefinitionSupplier返回插件实例。这样其他组件就可以用Autowired按Plugin类型或Qualifier按beanName拿到了。3.5 用 HTTP 接口验证动态加载效果光有框架不能直观感受效果写个简单的Controller来触发加载和验证RestController RequestMapping(/plugin) public class PluginController { private final PluginManager pluginManager; private final ApplicationContext applicationContext; public PluginController(PluginManager pluginManager, ApplicationContext applicationContext) { this.pluginManager pluginManager; this.applicationContext applicationContext; } PostMapping(/load) public String load(RequestParam String beanName, RequestParam String className, RequestParam String sourcePath) { pluginManager.loadPlugin(beanName, className, new File(sourcePath)); Plugin plugin applicationContext.getBean(beanName, Plugin.class); return 插件已加载: plugin.getName(); } PostMapping(/unload) public String unload(RequestParam String beanName) { pluginManager.unloadPlugin(beanName); return 插件已卸载: beanName; } }实际操作时你只需要准备一个实现了Plugin接口的Java文件调用load接口传入路径就能看到插件被编译、加载、注入、注册、启动的全过程。第二次修改源码后再次调用load新版本会替换旧版本这就是动态加载的核心能力。4. 实测中的重点坑从失效的 Autowired 到 Spring Boot 打包环境理论讲得再好不踩坑等于没讲。下面这是我实际调试过程中排掉的几个坑每一个都花了至少半天时间按排查链路写清楚希望能帮你省下这些时间。4.1 依赖注入失效为什么插件里的 Autowired 是 null第一次跑通插件加载流程时我在插件里写了这样一个类public class DemoPlugin implements Plugin { Autowired private UserService userService; Override public void start() { System.out.println(userService.count()); } }结果start()执行时直接NPEuserService是null。当时第一反应是这个类不是Spring管理的所以注入不生效。这是对的但关键在于怎么修。当时我用的方式是pluginClass.getDeclaredConstructor().newInstance()拿到实例后再调用applicationContext.getAutowireCapableBeanFactory().autowireBean(pluginInstance)。但实测发现Value注入的配置项还是空的而且PostConstruct也没执行。排查之后发现autowireBean只做了依赖注入并不会执行后续的初始化回调。正确的做法是用initializeBean一次性完成注入加初始化也就是上面PluginManager里第5步的写法。initializeBean内部会调用populateBean完成属性填充再走完整个BeanPostProcessor链。还有一个隐藏问题插件类里如果字段用了Autowired而注入的目标Bean类型恰好也在插件的类加载器里定义了一个同名类Spring在类型匹配时会因为Class对象不是同一个而匹配失败。这种情况一般建议插件只面向接口编程宿主注入的依赖类型尽量用宿主侧的接口不要直接用插件自定义类作为注入点。4.2 Spring Boot 打包环境下编译 classpath 丢失问题这是最让我头疼的一个坑没有之一。在IDE里直接main()启动时System.getProperty(java.class.path)返回的是完整的类路径包括项目target/classes、所有maven依赖jar的绝对路径编译插件一点问题都没有。但用Spring Boot打成fat jar后应用是由JarLauncher启动的java.class.path里其实只有一个xxx.jar真实的依赖都放在BOOT-INF/lib/下靠自定义的LaunchedURLClassLoader去加载此时再拿java.class.path拼classpath传给JavaCompiler编译插件时所有依赖都找不到直接报package org.springframework.beans.factory.annotation does not exist。排查链路的转折点在于我意识到编译classpath跟运行期类加载器的视角有关。Spring Boot自己的LaunchedURLClassLoader2.x版本继承自URLClassLoader可以通过getURLs()拿到全部依赖URL但这些URL在fat jar里是jar:file:/xxx.jar!/BOOT-INF/lib/xxx.jar!/这种嵌套形式。传给JavaCompiler时它是否能理解这种嵌套jarURL跟JDK版本和编译器实现有关实测JDK11以下不支持。我的最终方案是分两层处理本地开发和IDE环境直接取java.class.path完整可靠。Spring Boot打包环境不再依赖java.class.path改为让部署目录保持BOOT-INF/lib可枚举或者更简单——在application.yml里配一个plugin.classpath把插件可能需要用到的依赖显式列出来编译时用这个配置拼classpath。如果你不想在配置里手工维护依赖列表还有一个相对自动的办法用ApplicationHome拿到jar所在目录然后遍历同目录或lib目录下的所有jar拼成classpath。我这边因为插件会被限制只能使用一部分公共API所以配置化反而更合适也更安全。4.3 类加载器可见性边界插件能不能用宿主的工具类这个坑一般是跑通了基本流程之后才会遇到。插件里如果引用了宿主工程里某个工具类比如StringUtils编译的时候能编过但是运行期报NoClassDefFoundError。原因在于DynamicClassLoader的父加载器是Thread.currentThread().getContextClassLoader()也就是应用的类加载器它能加载宿主类。但前提是你在loadClassDirectory之后调用loadClass时类加载器能正确委派给父加载器。正常情况下是可以的。真正会出问题的场景是插件源码引用了宿主里某个注解或类但那个类位于一个不在应用ClassLoader可见范围内的模块。比如宿主应用用ClassLoader.getSystemClassLoader()启动但插件引用了一个仅存在于webapp目录下的类。这种情况在Spring Boot里不常见因为整个应用统一一个类加载器但在老式Tomcat部署模式里WEB-INF/lib和WEB-INF/classes的可见性是跟应用类加载器挂钩的反而没问题。真正需要警惕的是反向可见性插件自定义类加载器加载了自己的类但这个类又作为某个方法参数暴露给了宿主侧代码两边ClassLoader不同可能导致ClassCastException。解决办法是如前所述跨边界一律使用宿主侧的接口类型不要让插件自定义类型出现在宿主侧的签名里。4.4 反复加载后的元空间泄漏排查我做过一个压测循环加载同一个插件100次每次改一行代码重新load。跑了大概几十次后jstat看到Metaspace持续上涨GC之后也不回收。用jmap -clstats看类加载器数量发现旧类加载器一个都没少。根因是经典的类加载器泄漏。类加载器和它加载的类被某个地方持有强引用导致无法GC。我排查之后发现首恶是日志框架。插件里用了哪个日志框架它就可能持有ClassLoader引用比如Log4j2的LoggerContext会持有创建它的ClassLoader。其他排查点还包括插件里启动的线程如果线程没结束线程对象会持有ClassLoader引用插件里创建的静态单例比如static Map缓存了类信息通过ContextClassLoader设置的临时值没有还原Spring容器中残留的BeanDefinition或单例没有清理缓解手段有几个卸载插件时严格按stop()、移除BeanDefinition、销毁单例的顺序操作插件编码规范里禁止自启线程确实需要后台任务就通过宿主管控的TaskScheduler来跑最后类加载器本身加上弱引用监视在stop()之后立刻置空引用把是否可回收交给JVM判断。这类泄漏不是一次就能彻底解决的核心思路是卸载时把跟插件实例和类加载器相关的强引用全都断掉包括容器里的、日志框架里的、线程栈上的。可以用jmap -dump配合MAT的Path to GC Roots逐个排查。5. 热替换与插件生命周期管理动态加载做到能编译、能加载、能注册只是第一步。真实生产环境里插件是要反复变更的所以热替换和生命周期管理决定了这个方案能不能长期稳定运行。5.1 卸载插件的完整操作顺序我在PluginManager里写的unloadPlugin顺序是经过几次踩坑后固定下来的先从注册表移除保证后续请求不再获取到旧实例调用stop()让插件有机会释放自己的资源从Spring容器移除BeanDefinitiondestroySingleton触发PreDestroy等销毁回调置空所有强引用顺序上有个细节先stop()再destroySingleton。因为Spring的destroySingleton只会对容器管理的Bean触发销毁方法而我们的插件实例严格来说是在initializeBean阶段被容器加工过的但它的生命周期回调不一定能完全覆盖插件自己的stop()语义。先调stop()由插件自己把握状态清理再走Spring的销毁逻辑补一刀双保险。如果stop()里抛出异常要不要中断卸载我的选择是记录告警日志后继续避免一个插件把整个卸载链路卡死。生产环境里一个插件卸载失败应该被监控发现并告警但不应该阻塞其他插件的更新。5.2 如何确认旧类真的被卸载了热替换之后怎么验证旧类真的被卸载了最直接的办法是看Metaspace是否回落。可以用jstat -gc pid观察Metaspace指标通常在触发Full GC之后会看到明显下降。更精细的验证方式是用-XX:TraceClassUnloading参数启动应用替换插件后日志里会出现类似[Unloading class com.example.plugin.DemoPlugin]的输出。这个参数在JDK 11以上默认是开启的只是输出到safepoint日志里可以通过-Xlog:classunloadinfo查看。还有一个我在实践中的土办法在插件的stop()里给一个静态字段打标记然后在宿主的某个接口查这个类的加载记录。不过这种方法只能用来验证代码路径有没有执行不能证明类真的被GC。5.3 插件状态数据迁移插件要支持热替换必然面临一个现实问题新版本插件启动时老版本的运行状态比如计数器、缓存、持久化句柄要不要继承这个没有标准答案取决于你的插件类型。我目前的做法是不支持状态自动迁移。每个插件预置一个StateStore宿主负责把状态按key-value序列化存储插件启动时从StateStore恢复数据。这样插件的状态跟类加载器解耦了替换时旧类加载器里哪怕有静态变量也不会影响新实例。插件代码设计要求幂等和可重入因为热替换可能发生在任意业务时刻。6. 生产环境落地前的最后一个问题安全与隔离6.1 插件代码的安全边界Java的SecurityManager在JDK 17里已经标记废弃JDK 24正式移除所以不要指望用安全管理器来约束插件代码。现实一点说在同一个JVM里插件代码拥有跟宿主几乎同等的权限。它能反射调用sun.misc.Unsafe能开网络连接能读环境变量甚至能System.exit()直接把宿主进程搞挂。所以我的建议是把这个方案的使用范围定义为可信团队内部使用在上传入口做几层拦截编译前做静态扫描禁止引用java.lang.System里的危险方法虽然反射能绕过但至少拦掉不小心的代码对插件源码做大小限制和代码行数限制防止有人传几十万行代码进来插件运行期用单独的ContextClassLoader但这不是安全边界只是为了类隔离如果插件来源真的不可信唯一靠谱的方案是独立进程隔离通过HTTP或消息队列通信但那样就不叫动态加载了超出本文范围。6.2 插件之间的命名空间隔离多个插件同时存在时不能让它们共享同一个类加载器否则插件A里有个com.example.PluginConfig插件B里也有个同名类后加载的会把先加载的顶掉。每个插件必须有一个独立的PluginClassLoader实例这就是我在代码里每次loadPlugin都new PluginClassLoader的原因。隔离带来的新问题是对同一份第三方依赖的重复加载。假设插件A和插件B都用到了commons-lang3因为父加载器优先这个依赖实际上还是被宿主的类加载器加载两者共享一份。这正好符合我们的期望——避免同一个类加载两份造成实例状态不一致。但如果两个插件依赖了不同版本的同一个第三方库就会出问题。父加载器加载了版本较新的类旧版本的插件运行时如果用到旧版本独有的方法签名会报NoSuchMethodError。这个问题我现在也没有特别好的解法只能在插件编码规范中要求不得显式引入宿主已有的依赖不得依赖插件独有的第三方库版本。真要支持多版本隔离就得定制更复杂的父加载器链把共享类提取到公共父加载器把冲突类下沉到各插件自己的加载器里复杂度会上升一个量级。6.3 版本管理与回滚动态加载比普通发版多了一个需求出问题要能秒级回滚。我建议在插件管理器中维护一个插件文件副本的归档机制上传插件源码时落一份到/data/plugin-history/{pluginName}/{version}/加载时把当前版本记录下来如果新版本启动失败或者业务监控报警直接回滚到上一个版本重新编译加载即可。版本号可以从上传的文件名或者内容hash里解析。内容hash还有一个附带好处同一份代码重复上传时可以不重新编译直接从缓存里拿Class对象省掉编译时间和个性化命名空间带来的内存压力。说到底Spring动态加载Java源码做插件本质上是把编译期和运行期之间的墙打穿。它适合中小规模、可信团队、逻辑变化频率高但会话粒度有限的场景。我在这套方案踩过的坑绝大多数是类加载器可见性和Spring容器生命周期管理的问题这两块搞透整个方案就能稳定运行。我在实际使用中发现很多问题其实是插件编码习惯问题比如不释放线程、沉迷静态缓存、跨类加载器抛类型转换异常。所以到了后期我花在框架上的时间远少于花在插件规范制定上的时间——这大概才是插件化方案真正成熟的分水岭。 Spring动态加载Java源码做插件？编译-类加载-容器注册全链路详解
先别急着写代码这个需求背后藏着几个很关键的设计决策。你拿到一个Spring动态加载.java文件代码(插件开发)的标题第一反应可能是这不就是用反射加URLClassLoader加载个jar吗但等真上手就会发现动态编译、类加载隔离、Spring容器注册、热卸载每一步都能卡你半天。尤其是加载.java这个字眼意味着你得在运行期自己把源码编译成字节码再想办法把它变成Spring容器里真正可用的Bean。这篇文章我把整套链路拆开讲清楚从JVM编译API到类加载器再到容器注册一步步带你把一个可运行、可热替换的Spring插件管理器搭出来。1. 插件为什么非要动态加载 Java 源码1.1 从业务场景说起先想一个问题什么样的系统会需要动态加载插件我见过最典型的场景有两种。一种是平台型产品。交付给客户之后客户业务部门隔三差五提需求审批流里加一个特殊判定逻辑、报价单里按某条规则计算折扣、数据导入时做一次自定义清洗。这些逻辑说大不大说小不小如果每次都发版走CI/CD流程一个需求拖两周很正常。如果能允许业务方直接上传一段Java代码系统运行期编译并加载进去当天就能生效交付体验完全不一样。另一种是规则频繁变化的内部系统。比如风控、计费、消息路由这类场景规则引擎用表达式脚本有时候表达力不够但完整发版又太重。把变化的部分抽象成插件接口让维护人员编辑Java源文件系统监听文件变更后自动重新加载这是很多团队实际会采用的折中方案。这里有个看似绕路的选择值得先说清楚既然是运行期改逻辑为什么要选择编译Java源码而不是直接用Groovy脚本Groovy语法兼容Java还能直接跑脚本理论上更省事。但真实情况是Groovy在JVM里要额外维护一个GroovyClassLoader每次脚本变更都会产生新的类定义长期运行同样会踩元空间泄漏的问题而且Groovy依赖本身在不少偏保守的企业项目里是不允许引入的。相比之下JDK原生自带的javax.tools.JavaCompiler可以零额外依赖完成源码编译项目组对Java语法和编译错误的处理也更熟悉。1.2 为什么不是 Class 文件、不是 jar有人会问既然都编译了为什么不让业务方直接上传编译好的.class文件或者jar包这里面有个很现实的问题你在服务器上拿到的.class文件大概率跟你本地JDK版本编译出来的字节码不是一回事。业务方开发机上JDK17编译的class放到你JDK11的运行环境上轻则UnsupportedClassVersionError重则因为某些依赖版本不一致直接NoSuchMethodError。而接收.java源文件由服务端用自己环境的JDK编译字节码版本、依赖引用都以服务端为准兼容性问题被压缩到最小。jar包则面临另一个麻烦一旦允许上传jar你实际上就开放了一个类库依赖的入口。这个jar里依赖了什么版本的第三方库、是否会跟宿主应用的类冲突、里面有没有一些不该有的东西这些全都需要管控。而单文件.java把依赖边界限制在编译classpath内宿主给什么依赖插件才能用什么依赖控制面清晰很多。1.3 适用边界不过这事也不是万能的。动态加载Java源码有几个难以回避的局限语法错误和大部分依赖缺失问题要等运行期编译时才会暴露没法像静态代码一样在发版阶段被CI兜住。插件代码如果写得烂死循环、内存泄漏、跑飞线程宿主进程会跟着遭殃。Java没有真正意义上的代码沙箱这个问题只能靠制度和代码审查缓解。基于自定义类加载器的热卸载不是完全无痕静态变量、后台线程、资源句柄都是泄漏点后面专门有一节讲排查链路。所以这个方案的适用边界大概是你需要运行期扩展业务逻辑但你信任写插件的人或者有代码评审和灰度机制兜底。如果完全不可信那不应该用这个方案应该考虑独立进程隔离。2. 运行期编译与类加载的核心机制动手写代码之前先把三个核心机制理清楚。这三块拼起来才是完整的插件加载器缺一个都会在运行期出幺蛾子。2.1 javax.tools.JavaCompilerJDK 自带的编译入口javax.tools.JavaCompiler是JDK 1.6就有的编译API平时写代码的人基本用不上但做动态编译它是最正统的选择。它的工作方式跟命令行javac一致核心几个对象JavaCompiler编译器入口通过ToolProvider.getSystemJavaCompiler()获取StandardJavaFileManager负责管理源文件和编译产物的输入输出Iterable? extends JavaFileObject编译单元的集合一个JavaFileObject对应一个源文件CompilationTask一次编译任务DiagnosticCollector收集编译错误和警告一个最常见的用法是JavaCompiler compiler ToolProvider.getSystemJavaCompiler(); if (compiler null) { throw new IllegalStateException(未找到系统编译器请使用完整JDK运行); } StandardJavaFileManager fileManager compiler.getStandardFileManager(null, null, null); Iterable? extends JavaFileObject units fileManager.getJavaFileObjectsFromFiles( Collections.singletonList(sourceFile) ); ListString options new ArrayList(); options.add(-d); options.add(outputDir.getAbsolutePath()); if (classpath ! null !classpath.isEmpty()) { options.add(-classpath); options.add(classpath); } DiagnosticCollectorJavaFileObject diagnostics new DiagnosticCollector(); JavaCompiler.CompilationTask task compiler.getTask( null, fileManager, diagnostics, options, null, units ); boolean success task.call(); fileManager.close(); if (!success) { for (Diagnostic? extends JavaFileObject d : diagnostics.getDiagnostics()) { System.err.println(d.getMessage(null)); } throw new IllegalStateException(插件源码编译失败); }这里有一个非常多人踩的坑ToolProvider.getSystemJavaCompiler()只有在完整的JDK环境下才会返回非null。如果你的应用跑在一个纯JRE里或者Spring Boot是用jre裁剪过的镜像启动的这个API会直接返回null。我在生产环境排查过一次发现运维把程序跑在了一个只有JRE的精简容器里编译插件时直接抛NPE查了半天才发现JDK压根不在。2.2 自定义类加载器打破双亲委派编译产物只是一堆.class字节码放在磁盘上要把它变成JVM里可用的Class对象必须经过类加载器。JVM默认的类加载机制是双亲委派一个类加载器接到加载请求先委托给父加载器父加载器找不到才自己加载。这个设计的目的是保证核心类库比如java.lang.String永远由启动类加载器加载不会出现多个版本的混乱。但插件场景恰恰需要打破这种默认行为。原因很直接如果不同版本的同一个插件类都被父加载器优先加载了那就永远只有一个版本生效热替换根本无从谈起。所以插件类必须由我们自己创建的、独立的ClassLoader实例来加载——每个插件版本对应一个新的类加载器实例旧版本被替换后旧的类加载器连同它加载的类一起可以被GC回收。自定义类加载器的核心代码长这样public class DynamicClassLoader extends ClassLoader { private final MapString, byte[] classBytes new ConcurrentHashMap(); public DynamicClassLoader(ClassLoader parent) { super(parent); } public void putClass(String className, byte[] bytes) { this.classBytes.put(className, bytes); } Override protected Class? findClass(String name) throws ClassNotFoundException { byte[] bytes classBytes.get(name); if (bytes ! null) { return defineClass(name, bytes, 0, bytes.length); } return super.findClass(name); } Override protected Class? loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { // 本加载器管理的类优先加载避免父加载器抢先加载了旧版本 Class? c findLoadedClass(name); if (c null classBytes.containsKey(name)) { c findClass(name); } if (c null) { c super.loadClass(name, false); } if (resolve) { resolveClass(c); } return c; } } }注意这个loadClass的覆写。如果只覆写findClass那么类加载器在执行loadClass(com.example.MyPlugin)时会先走上层的ClassLoader.loadClass逻辑它内部是先委托父加载器。假设父加载器应用的ClassLoader里恰好有个同名的com.example.MyPlugin旧版本就会被返回你的新类永远没机会加载。所以我在覆写时做了一个判断只要classBytes里有这个类名就直接从本加载器加载。这就是打破双亲委派在插件场景下的具体做法。2.3 Spring 容器动态注册 Bean 的原理Class被加载出来了实例也能new了但这时候它还只是一个普通的Java对象跟Spring容器没关系。要让Autowired、Transactional这些注解在插件里生效让别的Bean能Autowired注入这个插件必须把插件实例注册进Spring容器。Spring容器的底层是DefaultListableBeanFactory它同时实现了BeanDefinitionRegistry和SingletonBeanRegistry。所以容器注册Bean本质上就两个入口registerBeanDefinition(String beanName, BeanDefinition beanDefinition)注册Bean的定义后续由容器实例化、注入、初始化registerSingleton(String beanName, Object singletonObject)直接注册一个现成的单例对象我们这里的情况比较特殊插件实例是我们自己通过反射创建出来的而且它的宿主类不在容器的默认类加载器可见范围内。所以不能直接注册一个Class让容器去实例化而是要把现成的实例交给容器管理。推荐的做法是GenericApplicationContext.registerBeanGenericApplicationContext context (GenericApplicationContext) applicationContext; context.registerBean(beanName, Plugin.class, () - pluginInstance);这里注册的bean定义类型是Plugin接口Supplier返回的是已经创建好的插件实例。这样做的好处是Bean定义存在了容器里其他组件可以通过Plugin接口类型按名字注入或查找同时我们也绕开了容器直接实例化自定义类加载器里的类这个容易出问题的环节。因为如果直接registerBeanDefinition传插件的ClassDefaultListableBeanFactory在解析ResolvableType时会对Class做一些处理而自定义类加载器加载的Class在跨加载器边界时很容易触发一些莫名其妙的问题。3. 手写一个可运行的动态插件加载器理论部分说清楚了下面把完整实现过一遍。我会尽量把代码写全保证你照着敲完能跑起来。3.1 定义插件契约先定义一个所有插件都必须实现的接口这是宿主和插件之间的合同public interface Plugin { String getName(); void start(); void stop(); }getName()用于在宿主侧标识插件start()是插件的初始化入口比如启动定时任务、加载配置stop()是停用入口用于释放资源。接口越简单越好复杂接口会提高插件的编写门槛。3.2 动态编译把 .java 变成字节码动态编译工具类我包装一下输入源文件路径和输出目录输出编译结果。核心还是上节那段代码这里加上编译失败时输出诊断信息的功能方便定位问题public class DynamicCompiler { public static void compile(File sourceFile, File outputDir, String classpath) throws IOException { if (!sourceFile.exists()) { throw new IllegalArgumentException(源码文件不存在: sourceFile); } Files.createDirectories(outputDir.toPath()); JavaCompiler compiler ToolProvider.getSystemJavaCompiler(); if (compiler null) { throw new IllegalStateException(当前JVM没有提供JavaCompiler请使用完整JDK启动应用); } DiagnosticCollectorJavaFileObject diagnostics new DiagnosticCollector(); try (StandardJavaFileManager fileManager compiler.getStandardFileManager(diagnostics, null, null)) { Iterable? extends JavaFileObject units fileManager.getJavaFileObjectsFromFiles( Collections.singletonList(sourceFile) ); ListString options new ArrayList(); options.add(-d); options.add(outputDir.getAbsolutePath()); if (StringUtils.hasText(classpath)) { options.add(-classpath); options.add(classpath); } options.add(-encoding); options.add(UTF-8); JavaCompiler.CompilationTask task compiler.getTask( null, fileManager, diagnostics, options, null, units ); boolean success task.call(); if (!success) { StringBuilder errorMsg new StringBuilder(插件编译失败: ); for (Diagnostic? extends JavaFileObject d : diagnostics.getDiagnostics()) { errorMsg.append(\n).append(d.getKind()).append(: ) .append(d.getMessage(null)) .append( at line ).append(d.getLineNumber()) .append(, column ).append(d.getColumnNumber()); } throw new IllegalStateException(errorMsg.toString()); } } } }编译产物默认输出到outputDir目录结构按包名自动分好。下一步就要从这个目录里把.class字节码读出来喂给自定义类加载器。3.3 把编译产物装载进类加载器编译完成之后遍历输出目录把所有.class文件的字节码读出来写入DynamicClassLoaderpublic class PluginClassLoader extends DynamicClassLoader { public PluginClassLoader(ClassLoader parent) { super(parent); } public void loadClassDirectory(File classDir) throws IOException { ListPath classFiles; try (StreamPath stream Files.walk(classDir.toPath())) { classFiles stream.filter(p - p.toString().endsWith(.class)).toList(); } for (Path classFilePath : classFiles) { String className classDir.toPath().relativize(classFilePath) .toString() .replace(File.separatorChar, .) .replace(/, .); className className.substring(0, className.length() - .class.length()); byte[] bytes Files.readAllBytes(classFilePath); putClass(className, bytes); } } }这里我特意把类名计算成一个包名加类名的完整形式对应putClass的key。注意相对路径在不同操作系统下分隔符可能不一样统一替换成.拼接类名这个细节在Windows上跑很容易疏忽。3.4 PluginManager编译-加载-注册-初始化的完整编排核心管理器负责统筹整个流程。它需要拿到ApplicationContext并把上下文转成GenericApplicationContext来调用动态注册APIService public class PluginManager implements ApplicationContextAware { private GenericApplicationContext applicationContext; private final MapString, PluginRuntime plugins new ConcurrentHashMap(); public static class PluginRuntime { private PluginClassLoader classLoader; private Class? pluginClass; private Plugin instance; private File classDir; } Override public void setApplicationContext(ApplicationContext applicationContext) throws BeansException { this.applicationContext (GenericApplicationContext) applicationContext; } public synchronized void loadPlugin(String beanName, String pluginClassName, File sourceFile) { unloadPlugin(beanName); try { // 1. 生成独立类加载器 PluginClassLoader classLoader new PluginClassLoader( Thread.currentThread().getContextClassLoader() ); // 2. 编译 File classDir Files.createTempDirectory(plugin-class- beanName).toFile(); DynamicCompiler.compile(sourceFile, classDir, buildClassPath()); // 3. 加载类 classLoader.loadClassDirectory(classDir); Class? pluginClass classLoader.loadClass(pluginClassName); // 4. 创建实例 Object rawInstance pluginClass.getDeclaredConstructor().newInstance(); // 5. 执行Spring依赖注入和Bean初始化 AutowireCapableBeanFactory beanFactory applicationContext.getAutowireCapableBeanFactory(); Object initialized beanFactory.initializeBean(rawInstance, beanName); Plugin instance (Plugin) initialized; // 6. 注册进Spring容器 applicationContext.registerBean(beanName, Plugin.class, () - instance); // 7. 启动插件 instance.start(); PluginRuntime runtime new PluginRuntime(); runtime.classLoader classLoader; runtime.pluginClass pluginClass; runtime.instance instance; runtime.classDir classDir; plugins.put(beanName, runtime); log.info(插件加载成功: {} - {}, beanName, pluginClassName); } catch (Exception e) { throw new RuntimeException(插件加载失败: pluginClassName, e); } } public synchronized void unloadPlugin(String beanName) { PluginRuntime runtime plugins.remove(beanName); if (runtime null) { return; } try { runtime.instance.stop(); } catch (Exception e) { log.warn(插件{}停止时发生异常, beanName, e); } ConfigurableListableBeanFactory beanFactory applicationContext.getDefaultListableBeanFactory(); if (beanFactory.containsBeanDefinition(beanName)) { beanFactory.removeBeanDefinition(beanName); } if (beanFactory.containsSingleton(beanName)) { beanFactory.destroySingleton(beanName); } // 手动解除强引用让类加载器和类可以被GC回收 runtime.instance null; runtime.pluginClass null; runtime.classLoader null; log.info(插件已卸载: {}, beanName); } private String buildClassPath() { StringBuilder cp new StringBuilder(System.getProperty(java.class.path, )); ClassLoader cl Thread.currentThread().getContextClassLoader(); if (cl instanceof URLClassLoader urlClassLoader) { for (URL url : urlClassLoader.getURLs()) { String path url.getPath(); if (cp.indexOf(path) 0) { cp.append(File.pathSeparator).append(path); } } } return cp.toString(); } }第5步值得单独说明一下。initializeBean这个方法是Spring Bean生命周期里非常核心的一环它会执行BeanPostProcessor#postProcessBeforeInitializationPostConstruct标注的初始化方法InitializingBean#afterPropertiesSetBeanPostProcessor#postProcessAfterInitialization也就是说调用initializeBean之后插件类里如果用Resource、Autowired、Value标注的字段才真正被填充这一步其实在applyBeanPropertyValues阶段做实际initializeBean内部会先执行populateBean这里我简化了流程组合直接用initializeBean覆盖了依赖注入和初始化回调Transactional这类AOP代理也会在这个时候生成并返回代理对象。所以第5步拿到的initialized不一定等于rawInstance必须用返回值继续后面的流程。另外注意第6步registerBean注册的是接口类型Plugin的BeanDefinitionSupplier返回插件实例。这样其他组件就可以用Autowired按Plugin类型或Qualifier按beanName拿到了。3.5 用 HTTP 接口验证动态加载效果光有框架不能直观感受效果写个简单的Controller来触发加载和验证RestController RequestMapping(/plugin) public class PluginController { private final PluginManager pluginManager; private final ApplicationContext applicationContext; public PluginController(PluginManager pluginManager, ApplicationContext applicationContext) { this.pluginManager pluginManager; this.applicationContext applicationContext; } PostMapping(/load) public String load(RequestParam String beanName, RequestParam String className, RequestParam String sourcePath) { pluginManager.loadPlugin(beanName, className, new File(sourcePath)); Plugin plugin applicationContext.getBean(beanName, Plugin.class); return 插件已加载: plugin.getName(); } PostMapping(/unload) public String unload(RequestParam String beanName) { pluginManager.unloadPlugin(beanName); return 插件已卸载: beanName; } }实际操作时你只需要准备一个实现了Plugin接口的Java文件调用load接口传入路径就能看到插件被编译、加载、注入、注册、启动的全过程。第二次修改源码后再次调用load新版本会替换旧版本这就是动态加载的核心能力。4. 实测中的重点坑从失效的 Autowired 到 Spring Boot 打包环境理论讲得再好不踩坑等于没讲。下面这是我实际调试过程中排掉的几个坑每一个都花了至少半天时间按排查链路写清楚希望能帮你省下这些时间。4.1 依赖注入失效为什么插件里的 Autowired 是 null第一次跑通插件加载流程时我在插件里写了这样一个类public class DemoPlugin implements Plugin { Autowired private UserService userService; Override public void start() { System.out.println(userService.count()); } }结果start()执行时直接NPEuserService是null。当时第一反应是这个类不是Spring管理的所以注入不生效。这是对的但关键在于怎么修。当时我用的方式是pluginClass.getDeclaredConstructor().newInstance()拿到实例后再调用applicationContext.getAutowireCapableBeanFactory().autowireBean(pluginInstance)。但实测发现Value注入的配置项还是空的而且PostConstruct也没执行。排查之后发现autowireBean只做了依赖注入并不会执行后续的初始化回调。正确的做法是用initializeBean一次性完成注入加初始化也就是上面PluginManager里第5步的写法。initializeBean内部会调用populateBean完成属性填充再走完整个BeanPostProcessor链。还有一个隐藏问题插件类里如果字段用了Autowired而注入的目标Bean类型恰好也在插件的类加载器里定义了一个同名类Spring在类型匹配时会因为Class对象不是同一个而匹配失败。这种情况一般建议插件只面向接口编程宿主注入的依赖类型尽量用宿主侧的接口不要直接用插件自定义类作为注入点。4.2 Spring Boot 打包环境下编译 classpath 丢失问题这是最让我头疼的一个坑没有之一。在IDE里直接main()启动时System.getProperty(java.class.path)返回的是完整的类路径包括项目target/classes、所有maven依赖jar的绝对路径编译插件一点问题都没有。但用Spring Boot打成fat jar后应用是由JarLauncher启动的java.class.path里其实只有一个xxx.jar真实的依赖都放在BOOT-INF/lib/下靠自定义的LaunchedURLClassLoader去加载此时再拿java.class.path拼classpath传给JavaCompiler编译插件时所有依赖都找不到直接报package org.springframework.beans.factory.annotation does not exist。排查链路的转折点在于我意识到编译classpath跟运行期类加载器的视角有关。Spring Boot自己的LaunchedURLClassLoader2.x版本继承自URLClassLoader可以通过getURLs()拿到全部依赖URL但这些URL在fat jar里是jar:file:/xxx.jar!/BOOT-INF/lib/xxx.jar!/这种嵌套形式。传给JavaCompiler时它是否能理解这种嵌套jarURL跟JDK版本和编译器实现有关实测JDK11以下不支持。我的最终方案是分两层处理本地开发和IDE环境直接取java.class.path完整可靠。Spring Boot打包环境不再依赖java.class.path改为让部署目录保持BOOT-INF/lib可枚举或者更简单——在application.yml里配一个plugin.classpath把插件可能需要用到的依赖显式列出来编译时用这个配置拼classpath。如果你不想在配置里手工维护依赖列表还有一个相对自动的办法用ApplicationHome拿到jar所在目录然后遍历同目录或lib目录下的所有jar拼成classpath。我这边因为插件会被限制只能使用一部分公共API所以配置化反而更合适也更安全。4.3 类加载器可见性边界插件能不能用宿主的工具类这个坑一般是跑通了基本流程之后才会遇到。插件里如果引用了宿主工程里某个工具类比如StringUtils编译的时候能编过但是运行期报NoClassDefFoundError。原因在于DynamicClassLoader的父加载器是Thread.currentThread().getContextClassLoader()也就是应用的类加载器它能加载宿主类。但前提是你在loadClassDirectory之后调用loadClass时类加载器能正确委派给父加载器。正常情况下是可以的。真正会出问题的场景是插件源码引用了宿主里某个注解或类但那个类位于一个不在应用ClassLoader可见范围内的模块。比如宿主应用用ClassLoader.getSystemClassLoader()启动但插件引用了一个仅存在于webapp目录下的类。这种情况在Spring Boot里不常见因为整个应用统一一个类加载器但在老式Tomcat部署模式里WEB-INF/lib和WEB-INF/classes的可见性是跟应用类加载器挂钩的反而没问题。真正需要警惕的是反向可见性插件自定义类加载器加载了自己的类但这个类又作为某个方法参数暴露给了宿主侧代码两边ClassLoader不同可能导致ClassCastException。解决办法是如前所述跨边界一律使用宿主侧的接口类型不要让插件自定义类型出现在宿主侧的签名里。4.4 反复加载后的元空间泄漏排查我做过一个压测循环加载同一个插件100次每次改一行代码重新load。跑了大概几十次后jstat看到Metaspace持续上涨GC之后也不回收。用jmap -clstats看类加载器数量发现旧类加载器一个都没少。根因是经典的类加载器泄漏。类加载器和它加载的类被某个地方持有强引用导致无法GC。我排查之后发现首恶是日志框架。插件里用了哪个日志框架它就可能持有ClassLoader引用比如Log4j2的LoggerContext会持有创建它的ClassLoader。其他排查点还包括插件里启动的线程如果线程没结束线程对象会持有ClassLoader引用插件里创建的静态单例比如static Map缓存了类信息通过ContextClassLoader设置的临时值没有还原Spring容器中残留的BeanDefinition或单例没有清理缓解手段有几个卸载插件时严格按stop()、移除BeanDefinition、销毁单例的顺序操作插件编码规范里禁止自启线程确实需要后台任务就通过宿主管控的TaskScheduler来跑最后类加载器本身加上弱引用监视在stop()之后立刻置空引用把是否可回收交给JVM判断。这类泄漏不是一次就能彻底解决的核心思路是卸载时把跟插件实例和类加载器相关的强引用全都断掉包括容器里的、日志框架里的、线程栈上的。可以用jmap -dump配合MAT的Path to GC Roots逐个排查。5. 热替换与插件生命周期管理动态加载做到能编译、能加载、能注册只是第一步。真实生产环境里插件是要反复变更的所以热替换和生命周期管理决定了这个方案能不能长期稳定运行。5.1 卸载插件的完整操作顺序我在PluginManager里写的unloadPlugin顺序是经过几次踩坑后固定下来的先从注册表移除保证后续请求不再获取到旧实例调用stop()让插件有机会释放自己的资源从Spring容器移除BeanDefinitiondestroySingleton触发PreDestroy等销毁回调置空所有强引用顺序上有个细节先stop()再destroySingleton。因为Spring的destroySingleton只会对容器管理的Bean触发销毁方法而我们的插件实例严格来说是在initializeBean阶段被容器加工过的但它的生命周期回调不一定能完全覆盖插件自己的stop()语义。先调stop()由插件自己把握状态清理再走Spring的销毁逻辑补一刀双保险。如果stop()里抛出异常要不要中断卸载我的选择是记录告警日志后继续避免一个插件把整个卸载链路卡死。生产环境里一个插件卸载失败应该被监控发现并告警但不应该阻塞其他插件的更新。5.2 如何确认旧类真的被卸载了热替换之后怎么验证旧类真的被卸载了最直接的办法是看Metaspace是否回落。可以用jstat -gc pid观察Metaspace指标通常在触发Full GC之后会看到明显下降。更精细的验证方式是用-XX:TraceClassUnloading参数启动应用替换插件后日志里会出现类似[Unloading class com.example.plugin.DemoPlugin]的输出。这个参数在JDK 11以上默认是开启的只是输出到safepoint日志里可以通过-Xlog:classunloadinfo查看。还有一个我在实践中的土办法在插件的stop()里给一个静态字段打标记然后在宿主的某个接口查这个类的加载记录。不过这种方法只能用来验证代码路径有没有执行不能证明类真的被GC。5.3 插件状态数据迁移插件要支持热替换必然面临一个现实问题新版本插件启动时老版本的运行状态比如计数器、缓存、持久化句柄要不要继承这个没有标准答案取决于你的插件类型。我目前的做法是不支持状态自动迁移。每个插件预置一个StateStore宿主负责把状态按key-value序列化存储插件启动时从StateStore恢复数据。这样插件的状态跟类加载器解耦了替换时旧类加载器里哪怕有静态变量也不会影响新实例。插件代码设计要求幂等和可重入因为热替换可能发生在任意业务时刻。6. 生产环境落地前的最后一个问题安全与隔离6.1 插件代码的安全边界Java的SecurityManager在JDK 17里已经标记废弃JDK 24正式移除所以不要指望用安全管理器来约束插件代码。现实一点说在同一个JVM里插件代码拥有跟宿主几乎同等的权限。它能反射调用sun.misc.Unsafe能开网络连接能读环境变量甚至能System.exit()直接把宿主进程搞挂。所以我的建议是把这个方案的使用范围定义为可信团队内部使用在上传入口做几层拦截编译前做静态扫描禁止引用java.lang.System里的危险方法虽然反射能绕过但至少拦掉不小心的代码对插件源码做大小限制和代码行数限制防止有人传几十万行代码进来插件运行期用单独的ContextClassLoader但这不是安全边界只是为了类隔离如果插件来源真的不可信唯一靠谱的方案是独立进程隔离通过HTTP或消息队列通信但那样就不叫动态加载了超出本文范围。6.2 插件之间的命名空间隔离多个插件同时存在时不能让它们共享同一个类加载器否则插件A里有个com.example.PluginConfig插件B里也有个同名类后加载的会把先加载的顶掉。每个插件必须有一个独立的PluginClassLoader实例这就是我在代码里每次loadPlugin都new PluginClassLoader的原因。隔离带来的新问题是对同一份第三方依赖的重复加载。假设插件A和插件B都用到了commons-lang3因为父加载器优先这个依赖实际上还是被宿主的类加载器加载两者共享一份。这正好符合我们的期望——避免同一个类加载两份造成实例状态不一致。但如果两个插件依赖了不同版本的同一个第三方库就会出问题。父加载器加载了版本较新的类旧版本的插件运行时如果用到旧版本独有的方法签名会报NoSuchMethodError。这个问题我现在也没有特别好的解法只能在插件编码规范中要求不得显式引入宿主已有的依赖不得依赖插件独有的第三方库版本。真要支持多版本隔离就得定制更复杂的父加载器链把共享类提取到公共父加载器把冲突类下沉到各插件自己的加载器里复杂度会上升一个量级。6.3 版本管理与回滚动态加载比普通发版多了一个需求出问题要能秒级回滚。我建议在插件管理器中维护一个插件文件副本的归档机制上传插件源码时落一份到/data/plugin-history/{pluginName}/{version}/加载时把当前版本记录下来如果新版本启动失败或者业务监控报警直接回滚到上一个版本重新编译加载即可。版本号可以从上传的文件名或者内容hash里解析。内容hash还有一个附带好处同一份代码重复上传时可以不重新编译直接从缓存里拿Class对象省掉编译时间和个性化命名空间带来的内存压力。说到底Spring动态加载Java源码做插件本质上是把编译期和运行期之间的墙打穿。它适合中小规模、可信团队、逻辑变化频率高但会话粒度有限的场景。我在这套方案踩过的坑绝大多数是类加载器可见性和Spring容器生命周期管理的问题这两块搞透整个方案就能稳定运行。我在实际使用中发现很多问题其实是插件编码习惯问题比如不释放线程、沉迷静态缓存、跨类加载器抛类型转换异常。所以到了后期我花在框架上的时间远少于花在插件规范制定上的时间——这大概才是插件化方案真正成熟的分水岭。