Java中上界通配符在 `Class-java教程-PHP中文网

serviceloader本身不支持上界通配符

java中上界通配符在 `class<? extends service>` 动态加载与 spi 中的应用

上界通配符 extends Service> 本身**不直接参与 Java SPI 的标准加载流程**，它和 SPI 的核心机制（ServiceLoader.load(Service.class)）没有绑定关系。SPI 的设计目标是**发现并实例化所有实现类**，而 extends Service> 表达的是“**只读、不可写入**”的泛型约束，二者语义和用途不同。但在实际工程中，尤其在封装 SPI 调用或构建类型安全的扩展点时，上界通配符会以间接但关键的方式提升代码健壮性。

为什么不能用 `ServiceLoader extends Service>`？

因为 ServiceLoader 是一个具体类型加载器，它的泛型参数必须是**确定的接口类型**（如 Service），而非通配符类型。Java 不允许将通配符作为泛型构造器的实际类型参数：

ServiceLoader extends Service> loader = ServiceLoader.load(...); —— 编译报错
正确写法只能是：ServiceLoader<service> loader = ServiceLoader.load(Service.class);</service>

通配符无法被 ServiceLoader 用于反射实例化——它需要明确的 Class 对象来调用无参构造器，而 ? extends Service 没有运行时类型信息，也无法确定具体加载哪个子类。

上界通配符真正起作用的地方：SPI 结果的消费与封装

当通过 ServiceLoader<service></service> 加载出一批实现类后，在对这些服务对象做统一处理（比如缓存、路由、包装、校验）时，上界通配符能提供更精确的安全保障：

Java Maven Code Review

审查Java Maven项目（ZIP压缩包或GitLab仓库URL），检查代码规范、命名、模块边界、可维护性问题以及重复代码。

下载

方法接收多个服务实例，但只读取其公共行为（如 getName()、getType()），不调用任何可能因子类差异而失败的方法
避免把 List<service></service> 强转为 List<mysqlservice></mysqlservice> 这类不安全操作
对外暴露只读视图，防止调用方误向集合中添加不兼容类型

例如：

public void registerServices(List extends Service> services) {
  services.forEach(s -> System.out.println("Registered: " + s.getClass().getSimpleName()));
  // ✅ 安全：可调用 Service 声明的所有 public 方法
  // ❌ 禁止：services.add(new OtherServiceImpl()); // 编译错误，保护类型安全
}

与 SPI 配合的典型模式：工厂 + 上界泛型返回

有些框架不直接暴露 ServiceLoader，而是封装成泛型工厂方法，此时上界通配符可用于声明更灵活的返回契约：

<t extends service> Optional<t> findFirst(Class<t> type)</t></t></t> —— 明确限定返回子类型
List extends Service> getAllAvailable() —— 返回只读列表，隐藏具体实现类名，增强封装性
配合 @SuppressWarnings("unchecked") 的安全转换（需确保 Class 对象与实际实例一致）

这种设计常见于 Dubbo 的 ExtensionLoader 或 Spring 的 SpringFactoriesLoader 封装层，它们在底层用 SPI 查找，对外用泛型+上界控制使用边界。

注意：别和 SPI 配置文件内容混淆

META-INF/services/com.example.Service 文件里写的永远是具体实现类的**全限定名**（如 com.example.mysql.MySQLService），不是泛型表达式。JVM 和 ServiceLoader 只认字符串类名，完全不感知泛型。上界通配符仅存在于编译期类型检查阶段，运行时已擦除。