本文介绍在 Spring 中如何为泛型接口 ApiService<T extends BasicDevice> 的多种具体实现（如 ImouService、DahuaService）实现运行时按实际设备子类类型自动路由调用，避免 Bean 注入歧义，并确保 getDeviceSnap() 被正确分发到匹配的实现类。
本文介绍在 spring 中如何为泛型接口 `apiservice
在 Spring 应用中，当多个 @Service 类实现同一个泛型接口（如 ApiService<ImouDevice> 和 ApiService<DahuaDevice>）时，直接按接口类型 ApiService 注入会导致 Spring 无法确定应选择哪一个 Bean，从而抛出 NoUniqueBeanDefinitionException（“2 beans found”）。根本原因在于：Spring 的依赖注入是静态的、编译期绑定的，它不感知泛型的实际类型参数（即 T 的具体运行时类），也无法自动根据 basicDevice.getClass() 去匹配对应的服务实现。
✅ 正确解法不是「按类型注入单个 Bean」，而是注入所有实现的集合，再结合运行时类型判断进行动态分发：
@Service
public class ScheduleTask {
private final DeviceVehicleRepository deviceVehicleRepository;
private final UrlDeviceBeanRepository urlDeviceBeanRepository;
private final Collection<ApiService<?>> apiServices; // ✅ 注入所有 ApiService 实现
private final S3Service service;
private final CacheManager cacheManager;
public ScheduleTask(DeviceVehicleRepository deviceVehicleRepository,
UrlDeviceBeanRepository urlDeviceBeanRepository,
Collection<ApiService<?>> apiServices, // 注意：此处是 Collection，非单个
S3Service service,
CacheManager cacheManager) {
this.deviceVehicleRepository = deviceVehicleRepository;
this.urlDeviceBeanRepository = urlDeviceBeanRepository;
this.apiServices = apiServices;
this.service = service;
this.cacheManager = cacheManager;
}
@Scheduled(cron = "0 0/1 * * * ?")
public void getSnaps() {
Long timestamp = Instant.now().getEpochSecond();
log.info("Started scheduled task to get snapshots");
List<BasicDevice> allVehiclesWithDevices = (List<BasicDevice>) deviceVehicleRepository.findAll();
allVehiclesWithDevices.parallelStream().forEach(basicDevice -> {
byte[] contentBytes = dispatchToMatchingService(basicDevice);
if (contentBytes != null && contentBytes.length > 0) {
urlDeviceBeanRepository.save(new UrlDeviceBean(contentBytes,
basicDevice.getVehicleId(), timestamp));
}
});
}
// 核心逻辑：根据 basicDevice 的实际运行时类型，查找匹配的 ApiService 实现
private byte[] dispatchToMatchingService(BasicDevice device) {
Class<?> deviceClass = device.getClass();
return apiServices.stream()
.filter(service -> {
// 获取 ApiService<T> 中 T 的实际类型（需在实现类中保留泛型信息）
Type genericInterface = Arrays.stream(service.getClass().getInterfaces())
.filter(t -> t instanceof ParameterizedType &&
((ParameterizedType) t).getRawType().equals(ApiService.class))
.findFirst()
.orElse(null);
if (genericInterface instanceof ParameterizedType) {
Type actualTypeArg = ((ParameterizedType) genericInterface).getActualTypeArguments()[0];
if (actualTypeArg instanceof Class) {
return ((Class<?>) actualTypeArg).isAssignableFrom(deviceClass);
}
}
return false;
})
.findFirst()
.map(service -> {
try {
// 利用反射安全调用泛型方法（因编译期擦除，需强制转型）
Method method = service.getClass().getMethod("getDeviceSnap", device.getClass());
return (byte[]) method.invoke(service, device);
} catch (Exception e) {
log.error("Failed to invoke getDeviceSnap for device: {}", device.getClass().getSimpleName(), e);
return new byte[0];
}
})
.orElse(new byte[0]);
}
}⚠️ 关键注意事项：
- Collection<ApiService<?>> 是 Spring 自动注入所有 ApiService 子类型的 Bean（无论泛型参数为何），前提是它们被正确标记为 @Service 且在组件扫描路径下。
- 上述 dispatchToMatchingService 使用了反射获取泛型实参并做 isAssignableFrom 匹配，这是保障类型安全路由的核心。若追求更高性能与可维护性，建议为每个 ApiService 实现添加一个 supports(Class<?> deviceType) 方法，由实现类显式声明支持的设备类型（例如 return ImouDevice.class.isAssignableFrom(deviceType);），从而避免反射开销。
- 所有 BasicDevice 子类（如 ImouDevice、DahuaDevice）必须被 JPA 正确识别（已通过 @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS) 配置），确保从数据库查询时能返回具体子类实例，而非仅 BasicDevice 父类代理对象。
? 进阶建议：可进一步封装为 ApiServiceRegistry 组件，内置缓存映射（Class<? extends BasicDevice> → ApiService），提升高频调用下的性能与可测试性。
通过该方案，你无需修改现有服务实现，即可实现「一个设备实例，自动命中唯一适配的服务实现」，真正达成策略模式 + 泛型 + Spring 容器的优雅协同。
