Hibernate 3代理类生成异常：懒加载属性代理不一致问题求助

这确实是Hibernate 3里一个常见的“非Bug类行为”，和它的Session缓存机制以及懒加载代理的创建逻辑直接相关，我来帮你拆解下原因和解决方案：

为什么会出现一个是代理、一个是真实对象的情况？ #

核心原因在于Session一级缓存的存在：

• 当你使用Restrictions.in("documentStatut", statutDocs)时，Hibernate会先将传入的statutDocs集合里的所有DocumentStatut实体纳入到当前Session的一级缓存中。
• 当查询返回第一个Document对象时，如果它关联的DocumentStatut不在Session缓存里（或者说之前没被加载过），Hibernate会创建懒加载代理对象返回。
• 而第二个Document对象关联的DocumentStatut，刚好是已经存在于Session缓存中的实例（来自你传入的statutDocs），Hibernate会直接返回缓存里的真实实体，而不会再创建代理。

简单说：Hibernate对于已经在Session缓存中的关联对象，不会再生成懒加载代理，直接复用缓存实例。

解决方案 #

根据你的业务需求，可以选择以下几种方案：

方案1：清空Session缓存中已存在的DocumentStatut实例 #

如果希望所有返回的Document的documentStatut都是懒加载代理，可以在执行Criteria查询前，把传入的statutDocs从Session缓存中移除：

// 在创建Criteria之前执行
if (statutDocs != null && !statutDocs.isEmpty()) {
    for (DocumentStatut statut : statutDocs) {
        getSession().evict(statut);
    }
}

这样Hibernate在加载Document的关联时，就会为每个关联创建懒加载代理，保持一致性。

方案2：调整FetchMode（按需选择） #

如果业务允许，可以在Criteria查询中显式指定关联的加载方式，强制使用懒加载的SELECT模式：

criteria.setFetchMode("documentStatut", FetchMode.SELECT);

不过这个方案效果可能有限，因为核心还是缓存的影响，但可以作为辅助手段尝试。

方案3：修改关联的FetchType（谨慎使用） #

如果你的业务场景中，每次查询Document都需要立即获取DocumentStatut，可以把@ManyToOne的fetch属性改成FetchType.EAGER：

@ManyToOne(fetch = FetchType.EAGER)
@JoinColumn(name = "ID_STATUT", nullable = false)
public DocumentStatut getDocumentStatut() { return this.documentStatut; }

⚠️ 注意：这个方案会导致每次查询Document都立即加载关联的DocumentStatut，可能带来性能损耗，只适合确实需要立即使用该关联的场景。

方案4：升级Hibernate版本（长期方案） #

Hibernate 3的懒加载代理逻辑确实存在这种不一致的情况，后续的Hibernate 4及以上版本对懒加载和缓存的处理更加严谨，这类问题出现的概率会大大降低。如果项目允许，升级到更高版本是比较彻底的解决方案。

验证方法 #

你可以在查询前验证传入的statutDocs是否已经在Session缓存中：

for (DocumentStatut statut : statutDocs) {
    System.out.println("Statut " + statut.getIdStatut() + " is in session: " + getSession().contains(statut));
}

如果输出true，说明该实体已经在缓存中，对应的Document的documentStatut就会是真实对象而非代理。

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