我将解释为什么这种情况不应该发生，为什么我们需要分离的实体。
考虑您正在进行JTA事务（JPA需要对此事务进行支持）和访存
a。现在，您可以
a.getB()在此事务中调用（1）（即实体受
a管理），或者在
a分离时调用（2）。
方案1
：现在，根据您的事务隔离级别，您可能会看到或可能不会看到其他事务在做什么。例如，如果您具有SERIALIZABLE隔离级别，那么
a.getB()即使该行在并发事务中被删除，您也将成功获取。如果该行已被删除并且您的事务看到该行，则意味着您的数据库不一致（没有外键）或您使用了错误的事务隔离级别。
方案2
：实体
a已分离。当
LazyInitializationException抛出a时，对我来说，您
a.getB()为确保应用程序中的一致性而调用得太晚了（因为
a不再管理）。为了解决该问题，您只需在仍然管理实体时就更早地调用它。不会发生NPE。
为什么我们需要DETACHED STATE？好吧，我们需要一个不跟踪对实体实例的更改的状态。为什么？
示例1
：假设您在EJB层中收到一个实体（具有持久身份），并且没有分离状态（意味着应该管理所有实体）。但是我们需要在持久化实体之前进行验证。如果该实体将被自动管理，则其更改将自动保存到DB。因此，引入了这种新状态。
示例2
：您在EJB层中收到一个实体，您只需要从该实体更新10个字段中的5个即可。如果该实体自动进入托管状态，则所有10个字段都将保留。在这种情况下，解决方案是获取一个受管实体，并仅更新该实体中的5个字段。
