// 1. 定义接口
package com.example.spi;
public interface LoadBalance {
    String select(List<String> providers);
}

// 2. 编写实现
package com.example.spi.impl;
public class RoundRobinLoadBalance implements LoadBalance {
    private int index = 0;
    
    @Override
    public String select(List<String> providers) {
        return providers.get(index++ % providers.size());
    }
}

// 3. 配置文件：META-INF/services/com.example.spi.LoadBalance
// 内容：
// com.example.spi.impl.RoundRobinLoadBalance
// com.example.spi.impl.RandomLoadBalance

// 4. 加载使用
ServiceLoader<LoadBalance> loader = ServiceLoader.load(LoadBalance.class);
for (LoadBalance lb : loader) {
    System.out.println(lb.select(Arrays.asList("192.168.1.1", "192.168.1.2")));
}

Java SPI的三大缺陷：

缺陷1：一次性加载所有实现

ServiceLoader会把配置文件里所有的实现类都实例化，即使你只需要其中一个。如果有10个LoadBalance实现，但你只用Random，另外9个也被加载了，浪费内存和初始化时间。

缺陷2：不支持按名称获取

只能遍历所有实现，无法通过名称（如"roundrobin"）直接获取特定实现。

缺陷3：没有依赖注入和AOP支持

Java SPI加载的对象不经过容器管理，无法做依赖注入，也无法织入切面（日志、监控等）。

2.3 Dubbo SPI的四大增强

增强1：按需加载（Lazy Loading）

Dubbo的ExtensionLoader不会一次性实例化所有扩展，只在getExtension(name)时才实例化指定的扩展。

增强2：按名称获取

配置格式改为name=className，支持通过名称直接获取：

# Dubbo的扩展配置格式（META-INF/dubbo/）
roundrobin=org.apache.dubbo.rpc.cluster.loadbalance.RoundRobinLoadBalance
random=org.apache.dubbo.rpc.cluster.loadbalance.RandomLoadBalance
leastactive=org.apache.dubbo.rpc.cluster.loadbalance.LeastActiveLoadBalance

// 按名称获取
ExtensionLoader<LoadBalance> loader = ExtensionLoader.getExtensionLoader(LoadBalance.class);
LoadBalance lb = loader.getExtension("roundrobin"); // 只加载这一个

增强3：依赖注入（IOC）

Dubbo的扩展加载器支持set方法注入，加载扩展时会自动注入其他扩展点。

public class MyProtocol implements Protocol {
    private LoadBalance loadBalance; // 会被自动注入
    
    // Dubbo会调用这个setter注入LoadBalance的自适应扩展
    public void setLoadBalance(LoadBalance loadBalance) {
        this.loadBalance = loadBalance;
    }
}

增强4：自适应扩展（@Adaptive）

这是Dubbo SPI最精妙的设计。有时候用哪个扩展实现，需要在运行时根据URL参数决定，而不是在加载时固定。

@Adaptive注解可以用在接口方法上，Dubbo会动态生成一个代理类，代理类在调用时根据URL中的参数选择具体的实现：

@SPI("random") // 默认实现是random
public interface LoadBalance {
    
    @Adaptive("loadbalance") // 运行时从URL的loadbalance参数取值
    String select(List<String> providers, URL url);
}

Dubbo为这个接口动态生成的适配器大概长这样：

// 动态生成的适配器（简化版）
public class LoadBalance$Adaptive implements LoadBalance {
    
    @Override
    public String select(List<String> providers, URL url) {
        // 从URL中取loadbalance参数，没有则用@SPI指定的默认值"random"
        String extName = url.getParameter("loadbalance", "random");
        // 用ExtensionLoader按名称获取具体实现
        LoadBalance lb = ExtensionLoader.getExtensionLoader(LoadBalance.class)
                                        .getExtension(extName);
        // 委托给具体实现
        return lb.select(providers, url);
    }
}

这样，调用方只需要持有这个自适应扩展（而不是具体实现），运行时根据URL动态路由到不同的实现，实现了运行时的多态。

2.4 Wrapper机制（AOP）

Dubbo SPI还支持Wrapper，用于给扩展点织入切面逻辑（类似Spring AOP）。

Wrapper类的特征：实现了扩展点接口，且构造函数的参数中有该接口类型。

// ProtocolWrapper是Protocol的包装器
public class ProtocolFilterWrapper implements Protocol {
    private final Protocol protocol; // 构造函数注入被包装的Protocol
    
    public ProtocolFilterWrapper(Protocol protocol) { // 这个构造函数签名被Dubbo识别为Wrapper
        this.protocol = protocol;
    }
    
    @Override
    public Exporter<?> export(Invoker<?> invoker) throws RpcException {
        // 前置逻辑（Filter链构建等）
        Invoker<?> wrappedInvoker = buildInvokerChain(invoker);
        // 委托给真实Protocol
        return protocol.export(wrappedInvoker);
    }
}

当通过ExtensionLoader获取Protocol实现时，Dubbo会自动把所有Wrapper套在外面，形成装饰器链，从而实现AOP效果。

三、标准答案 + 代码验证

3.1 完整的Dubbo SPI示例

// 1. 定义扩展点接口
@SPI("default") // 默认扩展名是"default"
public interface Greeting {
    String greet(String name);
}

// 2. 实现类
public class ChineseGreeting implements Greeting {
    @Override
    public String greet(String name) {
        return "你好，" + name;
    }
}

public class EnglishGreeting implements Greeting {
    @Override
    public String greet(String name) {
        return "Hello, " + name;
    }
}

// 3. 配置文件：META-INF/dubbo/com.example.Greeting
// chinese=com.example.impl.ChineseGreeting
// english=com.example.impl.EnglishGreeting
// default=com.example.impl.ChineseGreeting

// 4. 使用
public class SpiDemo {
    public static void main(String[] args) {
        ExtensionLoader<Greeting> loader = ExtensionLoader.getExtensionLoader(Greeting.class);
        
        // 按名称获取（只加载这一个）
        Greeting chinese = loader.getExtension("chinese");
        System.out.println(chinese.greet("张三")); // 你好，张三
        
        Greeting english = loader.getExtension("english");
        System.out.println(english.greet("Tom")); // Hello, Tom
        
        // 获取默认扩展
        Greeting defaultGreeting = loader.getDefaultExtension();
        System.out.println(defaultGreeting.greet("World")); // 你好，World
    }
}

3.2 Java SPI的完整演示

import java.util.ServiceLoader;

// 接口
public interface DataParser {
    String parse(String data);
}

// 实现1：JSON解析
public class JsonParser implements DataParser {
    @Override
    public String parse(String data) {
        return "JSON解析结果：" + data;
    }
}

// 实现2：XML解析
public class XmlParser implements DataParser {
    @Override
    public String parse(String data) {
        return "XML解析结果：" + data;
    }
}

// META-INF/services/com.example.DataParser 文件内容：
// com.example.JsonParser
// com.example.XmlParser

public class JavaSpiDemo {
    public static void main(String[] args) {
        ServiceLoader<DataParser> loader = ServiceLoader.load(DataParser.class);
        
        // 迭代所有实现（全部被实例化了！）
        for (DataParser parser : loader) {
            System.out.println(parser.parse("test data"));
        }
        
        // 输出：
        // JSON解析结果：test data
        // XML解析结果：test data
    }
}

四、面试官追问

追问1：Dubbo SPI中@SPI和@Adaptive的区别是什么？

我的回答：@SPI用于接口级别，声明这是一个Dubbo扩展点接口，参数指定默认扩展名。@Adaptive有两种用法：用在类上，表示这个类是手写的自适应扩展实现，不需要Dubbo动态生成；用在方法上，表示这个方法的实现需要在运行时根据URL参数动态选择，Dubbo会为整个接口动态生成一个适配器类，对标了@Adaptive的方法生成动态路由逻辑，未标注@Adaptive的方法在适配器中直接抛出异常。

追问2：Spring的SPI和Dubbo SPI有什么关系？

我的回答：Spring有自己的SPI机制，通过META-INF/spring.factories（Spring Boot 2.x）或META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports（Spring Boot 3.x）文件，注册自动配置类（AutoConfiguration）。Spring SPI本质上是Spring自动配置机制的基础，允许第三方框架在jar包中注册自己的AutoConfiguration，Spring Boot启动时自动发现并加载。这和Dubbo SPI解决的不是同一个问题：Dubbo SPI是在框架内部做扩展点的按需加载和动态路由，Spring SPI是在Spring容器启动时自动注册Bean配置。

追问3：在实际项目中，你有没有用过SPI机制做功能扩展？

我的回答：用过，主要是两个场景。第一，给Dubbo添加自定义的Filter，通过Dubbo SPI注册一个Filter扩展，用来做全局的请求日志和链路追踪。第二，给日志框架添加自定义的Appender，通过Java SPI（Log4j2用的是类似机制的插件系统）注册一个自定义Appender，把日志实时推送到消息队列做集中式日志分析。SPI机制的核心价值是：让主框架和扩展实现完全解耦，扩展方只需要按照接口规范实现并注册，主框架发现并加载，双方不需要互相引用代码。

五、同类题目举一反三

Dubbo的Filter机制是如何实现的，和Servlet的Filter有什么区别？

Dubbo的Filter基于SPI和Wrapper链实现，是RPC调用链的拦截器，在Provider端和Consumer端各自形成一条Filter链（ProtocolFilterWrapper负责构建）。可以做鉴权、限流、日志、链路追踪等。Servlet Filter是Web层的过滤器，基于Servlet规范，在HTTP请求到达Servlet之前处理，不涉及RPC层。两者都是责任链模式，但作用层次不同：Servlet Filter处理HTTP层，Dubbo Filter处理RPC调用层。

六、踩坑实录

坑一：Java SPI加载顺序不确定

有次用Java SPI注册了两个DataSource的Provider，测试时发现加载顺序在不同环境不一样（取决于classpath中jar的顺序），导致用了不期望的默认Provider。Java SPI没有优先级机制，顺序依赖文件系统扫描顺序，不可靠。如果需要确定性的顺序，用Dubbo SPI按名称获取，或者自己实现带优先级的SPI加载器。

坑二：Dubbo SPI的自适应扩展URL参数名搞错

自定义了一个Dubbo扩展，@Adaptive注解里写的参数名是myParam，但在服务调用URL里设置的是my-param（有连字符），结果自适应扩展找不到指定的实现，fallback到了默认实现，业务上出现了预料之外的行为。Dubbo的URL参数名是区分大小写且严格匹配的，@Adaptive里的参数名必须和URL里的key完全一致。

坑三：自定义Dubbo Filter没有正确透传异常

实现了一个Dubbo Filter做全局异常捕获，但忘记了在catch块里把异常重新封装成RpcException抛出，而是直接吞掉了，导致Consumer端拿到了一个空的Result，以为调用成功了，实际上Provider端已经出错。Dubbo的异常处理有一套约定，Filter里处理异常要遵守这套约定。

七、总结

Java SPI和Dubbo SPI的核心差异：

特性	Java SPI	Dubbo SPI
加载方式	全量加载	按需加载
获取方式	遍历	按名称
依赖注入	不支持	支持（set注入）
AOP	不支持	Wrapper机制
自适应扩展	不支持	@Adaptive动态生成

Dubbo SPI的自适应扩展是最精妙的设计：让接口在编译时不绑定任何具体实现，在运行时根据URL参数动态路由，实现了极高的灵活性和可扩展性。整个Dubbo框架的Protocol、Cluster、LoadBalance、Filter等核心组件都基于这套机制构建。