如何通过带参构造器使用Java ServiceLoader加载SPI实例？

一、替代方案：绕开ServiceLoader的无参构造限制 #

ServiceLoader本身仅支持无参构造实例化，要实现带参加载，推荐这几种更合理的方案：

1. 给SPI接口增加初始化方法（工厂模式变种） #

修改SPI接口，新增初始化方法让实现类在无参构造后注入依赖：

package com.myOrg.check.access;

public interface IRuleValidator{
    void validate();
    // 添加初始化方法传入依赖
    void init(MyDto myDto);
}

实现类调整：

package com.myModule.myService.check.access;

public class MyRuleValidatorProvider implements IRuleValidator {
    private MyDto myDto;

    public MyRuleValidatorProvider() {}

    @Override
    public void init(MyDto myDto) {
        this.myDto = myDto;
    }

    @Override
    public void validate() {
        // 使用myDto执行校验逻辑
    }
}

加载代码简化：

ServiceLoader<IRuleValidator> loader = ServiceLoader.load(IRuleValidator.class);
for (IRuleValidator validator : loader) {
    validator.init(myDto);
    // 后续直接使用初始化后的validator
}

2. 定义工厂SPI接口 #

单独创建工厂接口，把带参实例化的逻辑交给工厂类，再用ServiceLoader加载工厂：

public interface IRuleValidatorFactory {
    IRuleValidator createValidator(MyDto myDto);
}

工厂实现类：

public class MyRuleValidatorFactoryImpl implements IRuleValidatorFactory {
    @Override
    public IRuleValidator createValidator(MyDto myDto) {
        return new MyRuleValidatorProvider(myDto);
    }
}

加载逻辑：

ServiceLoader<IRuleValidatorFactory> factoryLoader = ServiceLoader.load(IRuleValidatorFactory.class);
for (IRuleValidatorFactory factory : factoryLoader) {
    IRuleValidator validator = factory.createValidator(myDto);
    // 使用validator
}

3. 结合依赖注入框架 #

如果项目已使用Spring、Guice等DI框架，可以将SPI实现类纳入容器管理，通过容器完成依赖注入后再使用。比如Spring中可以用@Autowired注入MyDto，ServiceLoader加载实例后由Spring自动填充依赖。

二、现有反射方案的问题 #

你的反射实现存在多处明显缺陷：

• 重复迭代器创建：每次循环都调用loader.iterator()，ServiceLoader的迭代器是懒加载的，重复调用会重新扫描配置文件、加载类，属于完全冗余的操作。
• 无意义的实例创建：先通过无参构造创建myImpl，之后又用反射创建新实例，之前的实例直接被丢弃，完全浪费资源。
• 反射逻辑冗余：Class.forName(myDto.getClass().getName())完全多余，直接用myDto.getClass()即可。
• 异常处理缺失：没有处理NoSuchMethodException、InstantiationException等反射相关异常，一旦实现类没有对应构造方法，会直接抛出运行时异常。
• 空指针风险：若循环中未找到匹配构造方法，constructor变量会为null，后续newInstance调用会触发空指针异常。

三、对性能的影响 #

1. 重复类加载与IO开销：每次调用getValidator都会重新初始化ServiceLoader，扫描META-INF/services下的配置文件，重复加载实现类，IO和类加载的开销极大。
2. 反射的固有性能损耗：反射调用构造方法本身比直接new慢几倍到几十倍，且你没有缓存构造器，每次调用都要重复遍历、获取构造方法，进一步放大损耗。
3. GC压力增加：无参构造创建的myImpl直接被丢弃，属于无效对象，会频繁触发Minor GC，影响整体性能。

四、其他缺陷 #

• 代码可读性差：反射逻辑复杂晦涩，后续维护者难以快速理解意图，修改时容易出错。
• 扩展性差：如果后续需要传入多个参数，反射逻辑需要大幅修改，而工厂模式或初始化方法的扩展成本极低。
• 兼容性问题：若实现类的构造方法不是public权限，getConstructor会抛出异常，你的代码未处理这种场景。

内容的提问来源于stack exchange，提问作者booyaakaashaa