Java 实体管理器。Flush（）是否将数据库中的数据保存为Commit（）？

我已经浏览了许多关于entityManager.flush（）方法的主题。 在我的实践中，我总是使用persist（）和commit（）方法

我还发现，有时候flush（）会在对数据库的select请求期间自动执行，此时它会检查数据库的示例约束，因此，如果在select期间由于约束而导致持久化对象错误，则会引发异常

其实我想了解：

当您使用flush（）方法时，持久化数据是否会保存在数据库中？所以在flush（）之后不需要执行commit（）

在某些具体情况下，使用flush（）而不是commit（）的优点是什么

---

多亏了JB Nizet，现在对flush（）有了一些清晰的认识

以下是几点：

为了在数据库中永久保存数据，JPA需要使用 插入/更新/删除语句，然后提交此数据。 提交事务总是必要的

Flush（）方法只执行insert/update/delete语句，而不提交数据，因此可以回滚事务和数据

当您执行commit（）时，JPA会在执行commit（即flush（）方法）之前刷新数据

在flush（）期间，在数据库执行sql语句并将数据放入数据库时，会检查数据库中的约束

当在执行flush（）后读取提交的数据时设置的隔离级别在其他事务中看不到，因为flush（）不提交数据

---

persist（）只是告诉实体管理器：必须在事务结束之前节省一些时间。flush（）执行将内存中的更改复制到数据库中所需的insert/update/delete语句。提交提交事务，使所有这些更改永久化，并对其他事务可见。flush（）只执行SQL语句。就像使用JDBC一样，您不执行任何语句，因为JPA为您执行它们。当您通过em.get（）加载实体时，它会为您执行一条SQL语句，以便从数据库加载数据，对吗？它返回一个托管实体（比如用户）。现在，如果您执行

user.setName（“Kirill”）

，那么您可以修改内存中的对象，但是JPA还必须修改数据库中相应的行，对吗？这就是JPA的全部要点。它不能在每次调用setter时都执行update语句：这将导致糟糕的性能。所以它能记住记忆中的变化。flush（）告诉JPA在数据库中执行必要的更改。使用insert/update/delete语句将内存中的所有更改写入数据库。但在提交事务之前，这些更改仍然可以回滚。您几乎不必显式地使用flush（）。默认情况下，JPA在提交之前为您刷新。提交事务始终是必要的，无论您使用何种API在事务数据库中进行更改。这就是事务处理的全部原理。flush（）只执行insert、update和delete语句。隔离级别适用于这些语句，就像适用于任何其他执行的语句一样。因此，例如，如果隔离级别为READ_COMMITTED，那么其他事务将只看到提交的数据。flush（）不提交。它执行insert、delete和update语句。