Hibernate dirtyProperties数组未包含所有修改属性及@Version相关疑问

1. 为何Hibernate的dirtyProperties数组未包含实体的所有修改属性？ #

Hibernate的dirtyProperties基于实体快照对比机制生成，以下场景会导致部分修改属性不被纳入：

• 属性值改回原值：加载实体时Hibernate会生成属性快照，若修改属性后又恢复为初始值，快照对比会判定属性无变化，不会加入dirtyProperties。
• 对象内部状态修改但引用未变：如果修改的是实体中自定义对象、集合的内部状态（比如修改List元素值而非替换整个List引用），Hibernate默认仅对比对象引用，不做深度检查，该属性不会被标记为脏。
• 自定义类型equals实现错误：若使用自定义属性类型，其equals()方法未正确实现值对比逻辑，会导致Hibernate误判属性未修改，从而不加入dirtyProperties。
• 访问策略与操作方式不匹配：若实体采用字段访问（注解直接标注在字段上），但通过getter/setter修改属性时，少数场景下Hibernate可能无法及时感知变化（该情况出现概率较低）。

2. Hibernate未将标注@javax.persistence.Version的属性纳入PostUpdateEvent的dirtyProperties列表，是否为默认行为？能否配置排除属性黑名单？ #

• 属于默认行为：@Version标记的是乐观锁字段，它的更新由Hibernate自动触发（用于处理并发冲突），不属于业务代码主动修改的"脏属性"范畴，因此默认会被排除在dirtyProperties之外。
• 无直接配置项设置排除黑名单：Hibernate没有现成配置项用于指定需要排除的属性黑名单，但可通过以下方式实现类似需求：
  • 自定义Interceptor：重写findDirty()方法，在脏属性检查阶段手动移除目标属性。
  • 自定义PostUpdateEventListener：在事件触发后，对dirtyProperties列表进行二次过滤，移除需要排除的属性。
  • 结合@DynamicUpdate：该注解主要控制生成的UPDATE SQL仅包含脏字段，虽不直接修改dirtyProperties列表，但可间接满足部分业务场景需求。

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