使用QueryDsl时如何正确创建JPAQueryFactory？两种实现哪种合规？

核心前提说明 #

首先明确两个底层逻辑，是判断两种方式是否正确的基础：

1. Spring中通过@PersistenceContext注入的EntityManager并非原生实体管理器实例，而是Spring生成的线程安全代理对象。代理会自动将所有操作路由到当前事务/请求绑定的真实EntityManager实例，该代理本身可以作为单例全局使用。
2. JPAQueryFactory是无状态工具类，构造后仅持有传入的EntityManager引用，只要持有的EntityManager是线程安全的，JPAQueryFactory本身也天然线程安全。

两种实现方式的正确性分析 #

第一种：配置类注册全局JPAQueryFactory Bean #

这种方式是否正确完全取决于你注入EntityManager的注解：

• 若配置类中使用@PersistenceContext注入EntityManager，再构造JPAQueryFactory注册为单例Bean，是完全正确的业界标准用法，不存在线程安全问题，效率最高。
  正确的配置示例：

  @Configuration
  public class QuerydslConfig {
      @PersistenceContext
      private EntityManager entityManager;
      
      @Bean
      public JPAQueryFactory jpaQueryFactory() {
          return new JPAQueryFactory(entityManager);
      }
  }
  

  配置完成后直接在业务类中@Autowired注入JPAQueryFactory即可正常使用。
• 若你错误地在配置类中使用@Autowired注入未被代理的原生EntityManager，那么创建的JPAQueryFactory持有非线程安全的原生实例，多线程场景下会出现并发数据异常，这也是很多人误以为第一种方式有问题的核心原因。

第二种：业务类每次新建JPAQueryFactory #

这种方式功能上完全正确，不会出现线程安全问题，但属于冗余实现：

• 每次新建JPAQueryFactory的性能开销极低，不会影响业务运行。
• 缺点是无意义的重复实例创建，JPAQueryFactory本身无状态，单例完全可以满足所有场景需求，重复创建属于不必要的资源浪费。

最终结论 #

优先使用第一种方式，只要确保配置类中用@PersistenceContext注入EntityManager构造全局单例JPAQueryFactory即可，是最优解。第二种方式虽然可用，但不推荐。

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