第2章动态加载核心原理

动态加载核心原理：类加载机制、SPI与动态编译

各位同学，今天我们来聊聊动态加载的核心原理。说实话，这部分内容在风控系统里特别重要。你想想看，规则要热更新，策略要动态切换，底层靠的就是这几个机制。

我个人习惯把动态加载拆成三个层面来看：类加载机制解决“怎么找到类”，SPI机制解决“怎么发现实现”，动态编译解决“怎么现场造类”。咱们一个一个说。

一、类加载机制：双亲委派模型

先讲类加载。Java的类加载器，说白了就是“找类”的。JVM启动时，会从classpath、jar包这些地方把.class文件拉进来。但这里有个关键设计——双亲委派模型。

什么叫双亲委派？简单说：
当一个类加载器收到加载请求，它不会自己先干，而是先扔给父加载器。父加载器搞不定，自己再上。这样一层层往上抛，直到顶层的Bootstrap ClassLoader。

为什么要这么设计？
我举个例子你就明白了。假设你自己写了个java.lang.String类，想替换JDK自带的。如果没有双亲委派，你的String可能就被加载了，那整个JVM就乱套了。双亲委派保证了核心类库的安全性——父加载器优先加载，你的自定义类根本没机会覆盖核心API。

  核心要点：双亲委派模型保证了Java核心类库的完整性和安全性。在风控系统中，我们经常需要自定义ClassLoader来加载外部规则jar包，这时候就要注意不要破坏这个模型。

我在项目中遇到过一个问题：规则引擎需要加载不同版本的规则jar包，但默认的ClassLoader会缓存已加载的类。结果就是，更新规则后，新jar包里的类根本不会被重新加载。解决方案？自定义ClassLoader，每次更新都new一个新的加载器实例，旧的让它GC掉。

实战技巧：自定义ClassLoader时，记得重写findClass()而不是loadClass()。loadClass()实现了双亲委派逻辑，你重写它反而容易出问题。findClass()是留给子类扩展的钩子。

二、Java SPI机制：服务发现的艺术

SPI，全称Service Provider Interface。说白了就是：接口你定义，实现别人来写，运行时动态发现。

Java SPI的工作流程很简单：

定义接口（比如 RuleEvaluator）
在jar包的 META-INF/services/ 目录下，创建一个以接口全限定名命名的文件
文件内容写实现类的全限定名
调用方用 ServiceLoader.load() 来加载所有实现

我记得有一次做风控规则平台，需要支持多种规则引擎（Drools、EasyRules、自研引擎）。如果用硬编码，每次新增引擎都要改代码、重新部署。用SPI就爽了——新引擎打个jar包扔进classpath，ServiceLoader自动发现，完全不用改主程序。

来看个代码示例：

// 1. 定义接口
public interface RuleEvaluator {
    boolean evaluate(RuleContext context);
}

// 2. 实现类
public class DroolsEvaluator implements RuleEvaluator {
    @Override
    public boolean evaluate(RuleContext context) {
        // Drools规则评估逻辑
        return true;
    }
}

// 3. META-INF/services/com.example.RuleEvaluator 文件内容：
// com.example.impl.DroolsEvaluator

// 4. 客户端加载
ServiceLoader<RuleEvaluator> loader = ServiceLoader.load(RuleEvaluator.class);
for (RuleEvaluator evaluator : loader) {
    // 自动发现所有实现
    boolean result = evaluator.evaluate(context);
}

避坑指南：我曾经遇到过一个坑——ServiceLoader是懒加载的，每次迭代时才会真正实例化。如果你在迭代过程中修改了服务文件，不会生效。另外，多个实现类如果有依赖顺序，SPI本身不保证顺序，需要自己加@Order注解或者排序逻辑。

三、动态编译技术：javax.tools.JavaCompiler

这个就更有意思了。JavaCompiler允许你在运行时把字符串编译成Class。想想看，用户在前端写了一段规则代码，传到后端，你直接编译加载执行——这不就是动态规则的终极形态吗？

javax.tools.JavaCompiler 是JDK 1.6引入的，藏在tools.jar里。用法其实不复杂：

// 获取编译器实例
JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();

// 准备编译参数
String sourceCode = "public class DynamicRule { " +
    "public boolean execute(int score) { " +
    "    return score > 100; " +
    "} }";

// 编译并加载
// 这里需要自定义JavaFileObject来包装源码字符串
// 然后用compiler.getTask()执行编译
// 最后用ClassLoader加载编译后的字节码

嗯，这里要注意几个关键点：

编译环境：需要JDK环境，JRE不行。生产环境记得配好tools.jar
类名冲突：每次编译的类名不能重复，我习惯用UUID或时间戳生成类名
安全沙箱：用户提交的代码不能为所欲为，要用SecurityManager限制权限
性能问题：编译本身有开销，不适合高频调用。一般配合缓存使用

  实战经验：我在一个风控规则中心里，用动态编译实现了“在线规则编辑器”。运营同学写一段Groovy或Java代码，保存后立即生效。底层就是JavaCompiler + 自定义ClassLoader。但注意，一定要做代码沙箱——我曾经没限制System.exit()，结果有人提交了段代码直接让JVM退出了，血的教训。

动态编译的完整流程大概是：
源码字符串 → JavaFileObject → 编译任务 → 编译后的byte[] → 自定义ClassLoader加载 → 反射调用

这里有个小技巧：编译后的字节码可以写入文件系统缓存起来，下次直接加载，避免重复编译。我一般用LRU缓存，保留最近100个编译结果。

性能优化：如果规则变化不频繁，建议用“编译一次，多次执行”的模式。把编译结果缓存到内存或本地文件，下次直接加载Class对象，省掉编译开销。

总结一下

这三个机制，在风控规则动态加载里各司其职：

机制	核心作用	风控场景
类加载机制	加载外部jar包中的规则类	规则jar包热部署、版本隔离
Java SPI	动态发现规则引擎实现	多引擎支持、插件化扩展
动态编译	运行时编译规则源码	在线规则编辑器、脚本规则

说实话，这三个技术单独拿出来都不难，但组合起来就能构建出非常灵活的动态规则系统。我建议你在本地搭个demo试试——先写个自定义ClassLoader加载外部类，再试试SPI自动发现，最后玩一下JavaCompiler在线编译。动手之后，理解会深很多。

📚 课程目录

动态加载核心原理：类加载机制、SPI与动态编译

一、类加载机制：双亲委派模型

二、Java SPI机制：服务发现的艺术

三、动态编译技术：javax.tools.JavaCompiler

总结一下