Spring 默认以单例模式管理 Bean，当多个服务注入同一泛型类型 PostgresDAO 时，若未显式配置作用域或独立 Bean 实例，所有服务将共享同一个 PostgresDAOImpl 实例，导致 @PostConstruct 中设置的 typeParameterClass 被后续调用覆盖，引发类型参数错乱。
spring 默认以单例模式管理 bean，当多个服务注入同一泛型类型 `postgresdao
这个问题的本质并非 @PostConstruct 失效，而是 Spring 的 Bean 生命周期与泛型擦除机制共同导致的单例共享误用。
? 根本原因分析
Java 泛型在运行时被擦除（Type Erasure），PostgresDAO<parameterone></parameterone> 和 PostgresDAO<parametertwo></parametertwo> 在 JVM 层面均为 PostgresDAO 原始类型。Spring 容器在依赖注入时，若未明确声明多个独立 Bean，会将 PostgresDAOImpl 视为单一原型类（raw type），并默认创建一个单例实例（scope="singleton"）。因此：
- 三个
@Service类注入的dao字段，实际指向同一个PostgresDAOImpl对象； -
ClassOneServiceImpl.enrichDao()先执行 →typeParameterClass = ParameterOne.class； -
ClassTwoServiceImpl.enrichDao()随后执行 → 覆盖为ParameterTwo.class； -
ClassThreeServiceImpl.enrichDao()最后执行 → 覆盖为ParameterThree.class； -
但若初始化顺序不确定（如 Bean 创建/PostConstruct 执行顺序受依赖关系、条件注解等影响），则可能出现
ClassThreeServiceImpl.getParameter()返回ParameterOne.class的“错乱”现象 —— 这正是你观察到的非确定性行为。
✅ 本地 JDK 17 正常 ≠ 逻辑正确：JDK 版本差异可能影响 Bean 初始化顺序（如
@PostConstruct调用时序、类加载器行为），掩盖了本质问题，属于侥幸通过，不可靠。
✅ 正确解决方案：显式声明独立 Bean 实例
避免依赖泛型类型推断，改用 @Configuration 显式定义三个不同参数化的 PostgresDAO Bean，并确保它们互不共享状态：
@Configuration
public class DaoConfiguration {
@Bean
public PostgresDAO<parameterone> parameterOneDao() {
PostgresDAOImpl<parameterone> dao = new PostgresDAOImpl();
dao.setTypeParameterClass(ParameterOne.class);
return dao;
}
@Bean
public PostgresDAO<parametertwo> parameterTwoDao() {
PostgresDAOImpl<parametertwo> dao = new PostgresDAOImpl();
dao.setTypeParameterClass(ParameterTwo.class);
return dao;
}
@Bean
public PostgresDAO<parameterthree> parameterThreeDao() {
PostgresDAOImpl<parameterthree> dao = new PostgresDAOImpl();
dao.setTypeParameterClass(ParameterThree.class);
return dao;
}
}</parameterthree></parameterthree></parametertwo></parametertwo></parameterone></parameterone>
对应的服务类需使用 @Qualifier 或按类型+名称精准注入（推荐后者，更安全）：
@Service
@RequiredArgsConstructor
public class ClassOneServiceImpl implements ClassOneService {
private final PostgresDAO<parameterone> dao; // Spring 自动匹配 @Bean 名称 "parameterOneDao"
public Class> getParameter() {
return dao.getTypeParameterClass(); // 始终返回 ParameterOne.class
}
}</parameterone>
⚠️ 注意事项：
- 移除所有
@PostConstruct中对dao.setTypeParameterClass(...)的调用 —— 此逻辑已移至配置类中，且在 Bean 构建阶段完成，线程安全、无竞态；PostgresDAOImpl不再需要@Repository或@Scope("prototype")：因为每个 Bean 都是独立构造、独立注册的实例；- 若 DAO 内部持有
EntityManager等有状态资源，请确认其线程安全性（EntityManager本身由 Spring 管理代理，通常无需额外处理）；- Lombok 的
@NoArgsConstructor可保留，但@Getter需确保typeParameterClass字段可安全暴露（建议设为private final并在构造时赋值，见下文优化）。
? 进阶优化：构造时注入类型参数（更健壮）
为彻底规避运行时状态污染风险，可改造 PostgresDAOImpl，将类型参数作为构造参数强制传入：
@Repository
public class PostgresDAOImpl<t> implements PostgresDAO<t> {
private final Class<t> typeParameterClass;
private final EntityManager em;
public PostgresDAOImpl(Class<t> typeParameterClass, EntityManager em) {
this.typeParameterClass = Objects.requireNonNull(typeParameterClass);
this.em = em;
}
// 移除 setTypeParameterClass() 方法 —— 不可变设计
@Override
public Class<t> getTypeParameterClass() {
return typeParameterClass;
}
// ... 其他业务方法
}</t></t></t></t></t>
此时配置类变为：
@Bean
public PostgresDAO<parameterone> parameterOneDao(EntityManager em) {
return new PostgresDAOImpl(ParameterOne.class, em);
}</parameterone>
该方式实现不可变性（Immutability），从设计上杜绝类型参数被意外修改，是最推荐的生产实践。
✅ 总结
| 问题现象 | 单例 Bean 共享 + 运行时泛型擦除 → typeParameterClass 被覆盖 |
|---|---|
| 根本原因 | Spring 未区分泛型参数，误将多个逻辑 DAO 绑定到同一实例 |
| 关键误区 | 误以为 @PostConstruct 可“隔离”泛型实例状态 |
| 正确做法 | 使用 @Configuration + @Bean 显式声明独立参数化 Bean |
| 最佳实践 | 构造注入类型参数，使 DAO 实例不可变，消除状态竞争风险 |
遵循此方案，即可在任意 JDK 版本和 Spring Boot 环境中稳定运行，彻底解决类型参数错乱问题。
