当我java.persistence.EntityManger.find（）和@Entity时，EntityManager检查Transaction以查找其关联的持久化上下文的现有实例。如果存在，那么
如果事务不包含管理器关联的持久化上下文的现有实例，则管理创建一个，将其与事务关联，在数据源中查找实体，并将其添加到该上下文以进行管理，然后将该实体返回给find的调用者。
- ＆GT;结果是相同的，因为调用者现在有一个存在于持久化上下文中的管理实体。 （重要的是：持久化上下文附加到事务中，因此如果事务在客户端获取“托管”实体的位置结束，那么持久性上下文就不再存在，并且实体是“已分离”的不再管理）。
现在，当我在@entity实例上使用setter或其他内部状态更改方法进行状态更改时，会跟踪这些更改，因为我的实体是持久性上下文的一部分，当事务最终提交时，它将被刷新到数据源。我的问题是如何跟踪状态变化以及通过什么？如果我通过某个中间对象进行更改，那么该中间对象可以相应地更新持久化上下文，但我不是（或者我？）。我正在使用我的@entity带注释的对象直接进行更改。那么如何跟踪这些变化。
也许有些事件正在被收听？听了什么？我正在阅读关于这个主题的书籍和文章，但我无法将这一点归结为此。
答案 0 :(得分：3)
在实体的生命周期中，jpa供应商的内部实施会跟踪状态变化。
脏检查策略是特定于供应商的。可以通过字段比较或字节码增强功能完成，例如在JPA dirty checking中发布。
虽然它是特定于供应商的，但PersistentContext将在状态同步，刷新或提交时了解状态更改。
记住可以完成冲洗的所有要点非常重要：