如何检查Hibernate是否从L1缓存获取对象？

一、优先解决核心性能问题：批量预加载 #

你的思路完全正确——用findByIdIn批量预加载是解决这类N+1查询的最优方案，而且不需要额外判断缓存来源就能直接生效：

• 在循环执行前，调用repository.findByIdIn(idsList)把所有需要的实体一次性加载到当前Session的L1缓存里。只要后续的findById调用和这次批量查询处于同一个事务/同一个Session，Hibernate就会直接从缓存取数据，不会触发新的SQL。
• 验证起来很简单：开启Hibernate的SQL日志（配置hibernate.show_sql=true），执行后只会看到一条select ... where id in (...)的语句，循环里的findById不会输出新SQL，这就说明缓存命中生效了。

二、如果确实需要区分实体来源（缓存/数据库） #

如果业务逻辑必须判断数据是从缓存还是数据库获取的，可以用这几种方法：

• 直接查询Session缓存状态：
  通过Hibernate的Session API直接检查实体是否在L1缓存中，代码示例：

  @Autowired
  private EntityManager entityManager;
  
  // 判断指定ID的实体是否在当前Session的L1缓存中
  public boolean isEntityInL1Cache(Class<?> entityClass, Serializable id) {
      Session session = entityManager.unwrap(Session.class);
      return session.getCache().containsEntity(entityClass, id);
  }
  

  调用这个方法，如果返回true，后续的findById就会从缓存取；返回false则会触发数据库查询。
• 查看SQL日志：这是调试阶段最直观的方式，只要findById没有输出新的SQL语句，就说明是从缓存返回的。
• 利用Hibernate统计功能：
  开启统计配置（hibernate.generate_statistics=true），然后通过SessionFactory.getStatistics()获取统计数据，对比调用findById前后的getEntityLoadCount数值变化——如果数值没变，就是缓存命中；如果增加了，就是从数据库加载的。

三、额外注意事项 #

• 确保批量预加载和循环调用在同一个事务里，L1缓存是和Session绑定的，事务结束Session关闭后缓存就失效了。
• 如果需要跨Session共享缓存，可以配置Hibernate的L2缓存，不过要注意实体的缓存策略（比如只读、读写等），避免数据一致性问题。

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