如何利用ServiceLoader破坏委派实战框架解耦对象变量加载-java教程-PHP中文网

ServiceLoader 并未破坏双亲委派模型，而是通过 Thread.currentThread().getContextClassLoader() 主动绕过它，利用 TCCL 加载业务 classpath 下的 SPI 实现类，实现解耦与动态扩展。

如何利用serviceloader破坏委派实战框架解耦对象变量加载

ServiceLoader 本身不“破坏”双亲委派，而是**绕过它**——它通过线程上下文类加载器（TCCL）主动加载服务实现，从而让业务模块能加载自己 classpath 下的实现类，哪怕这些类对启动类加载器或扩展类加载器不可见。这种机制天然适配插件化、多租户、渠道变量等场景，是解耦“对象变量”的关键支点。

变量对象必须定义为标准 SPI 接口

业务变量不是配置项或常量，而是封装了“如何计算、何时生效、按什么优先级介入”的行为对象。接口需满足：

public 修饰，独立发布（如 variable-spi.jar），避免与实现混编
方法签名明确：例如 String key()（唯一标识）、Object resolve(Context c)（动态取值）、int order()（排序依据）
不依赖 Spring 注解，不声明 @Component 或 @Service

META-INF/services 是变量注册的唯一入口

每个提供变量行为的模块（如渠道模块、租户模块）必须在 src/main/resources/META-INF/services/ 下放置文件，文件名严格等于接口全限定名（如 com.example.VariableProvider），内容为一行一个实现类全名：

✅ 正确：com.channel.AlipaySourceProvider
❌ 错误：com/channel/AlipaySourceProvider（斜杠）、com.example.variableprovider（大小写不符）、带 BOM 或末尾空格
多个实现可共存，文件中每行一个，ServiceLoader 全部发现并返回 Iterator

加载时必须对齐线程上下文类加载器

ServiceLoader 默认用 Thread.currentThread().getContextClassLoader() 查找资源。Web 容器、模块化应用或自定义线程池中，若 TCCL 被重置（如 Tomcat 的 WebAppClassLoader 未设为当前上下文），就会找不到自己 jar 中的配置文件。

显式传入类加载器更可靠：ServiceLoader.load(VariableProvider.class, this.getClass().getClassLoader())
避免缓存 ServiceLoader 实例——它不预加载，只在 iterator().next() 时反射实例化；提前缓存却未遍历，等于“假装加载成功”
首次调用 next() 可能抛 NoClassDefFoundError 或 InstantiationException，需捕获并跳过失效实现