您描述的问题不是由数据库处理的，根据我的经验，Hibernate也不能完全解决该问题。
您必须采取明确的步骤来避免出现问题。
Hibernate为您完成了一些工作。按照前面的答案，Hibernate确保在单独的刷新中按一定的顺序对插入，删除和更新进行排序，以确保按可实现的顺序应用它们。请参见AbstractFlushingEventListener类中的performExecutions（EventSource会话）：
以特殊顺序执行所有SQL（和二级缓存更新），以免违反外键约束：
- 按执行顺序插入
- 更新
- 删除收集元素
- 插入收集元素
- 按执行顺序删除
当具有唯一性约束时，了解此顺序非常重要，尤其是如果您要替换一对多子代（删除旧的/插入新的）时，新旧子代共享相同的唯一性约束（例如，相同的电子邮件地址）
）。在这种情况下，您可以更新旧条目，而不是删除/插入，或者可以仅在删除后刷新，然后继续插入。有关更详细的示例，请查看本文。
请注意，它没有指定更新顺序。检查Hibernate代码使我认为更新顺序将取决于在实体被添加到持久化上下文中，为了在 不
他们更新的顺序。这在您的代码中可能是可以预见的，但是阅读Hibernate代码并没有让我觉得我会依赖该顺序。
我可以想到三种解决方案：
- 尝试将hibernate.order_updates设置为 true 。当同一张表中的多行被更新时，这应该有助于避免死锁，但对于跨多个表的死锁却无济于事。
- 在进行任何更新之前，使您的事务对一个实体使用PESSIMISTIC_WRITE锁。您使用哪个实体取决于您的具体情况，但是只要确保在存在死锁风险的情况下始终选择一个实体，这将阻塞其余事务，直到获得锁为止。
- 编写代码以在出现死锁时捕获死锁，然后以明智的方式重试。管理死锁重试的组件必须位于当前事务边界之外。这是因为必须关闭失败的会话，并且回退关联的事务。在本文中，您可以找到自动重试AOP方面的示例。
