Hibernate调试中实体带_$$_jst3f5_前缀及空值问题排查

一、_$$_jst3f5_ 是什么？ #

_$$_jst3f5_是Hibernate为实体类动态生成的代理类后缀标识。Hibernate为实现懒加载、延迟初始化等ORM特性，会在运行时为实体类创建动态代理子类，jst3f5是Hibernate生成的唯一字符串，用于区分不同的代理类实例，最终的代理类名称格式为原实体类名_$$_唯一标识_序号。

二、问题根因 #

核心原因是脱管状态的原始实体对象与事务内的代理对象在Hibernate一级缓存中发生类型冲突：

• 非事务方法（如Vaadin的enter方法）调用getServiceById时，Hibernate的Session在查询完成后立即关闭，加载的实体是脱管状态（Detached）的原始ServiceEntity实例，未被代理。
• 当后续在@Transactional方法中再次查询同一ID的实体时，Hibernate会优先从当前Session的一级缓存中查找。此时缓存中存在的是脱管的原始实体对象，而Hibernate在事务上下文默认会尝试返回代理类实例，二者类型不匹配引发内部处理异常，最终导致Hibernate返回空的代理对象（所有字段为空）。
• 执行顺序的影响逻辑：
  • 先通过非事务方法加载ID=594的原始实体后，事务内查询594时触发类型冲突，返回空代理；
  • 先在事务内加载ID=595的代理实体，后续查询594时，缓存中594的原始实体与595的代理类型冲突，同样导致594加载失败。

三、解决方法 #

1. 统一事务边界，避免脱管对象产生 #

将所有涉及实体加载的操作纳入事务上下文：

• 给Vaadin的enter方法调用的服务层方法添加@Transactional注解，确保实体加载始终在Session（事务）管理下，生成的都是代理类实例，避免原始实体进入缓存。

2. 事务内强制刷新实体，绕过缓存冲突 #

在@Transactional的getProviderService方法中，查询时强制刷新实体，忽略缓存中的脱管对象：

public ServiceEntity getServiceById(Long id) {
    ServiceEntity entity = entityManager.find(ServiceEntity.class, id);
    if (entity != null) {
        entityManager.refresh(entity); // 强制从数据库重新加载，覆盖缓存中的异常实例
    }
    return entity;
}

3. 调整实体关联的加载策略 #

检查ServiceEntity中provider和category字段的关联注解（如@ManyToOne），若不需要懒加载，可设置fetch = FetchType.EAGER，减少代理类生成的场景：

@ManyToOne(fetch = FetchType.EAGER)
@JoinColumn(name = "provider_id")
private ProviderEntity provider;

4. 清除冲突的缓存实例（临时应急方案） #

若无法修改事务边界，可在事务内查询前清除缓存中冲突的实体：

public ServiceEntity getServiceById(Long id) {
    ServiceEntity cachedEntity = entityManager.find(ServiceEntity.class, id);
    if (cachedEntity != null && !cachedEntity.getClass().getName().contains("_$$_")) {
        entityManager.detach(cachedEntity); // 移除缓存中的原始实体
    }
    return entityManager.find(ServiceEntity.class, id);
}

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