Java 实体分散多长时间？

我试图了解JPA是如何工作的。据我所知，如果持久化一个实体，该对象将保留在内存中，直到应用程序关闭。这意味着，当我查找以前持久化的实体时，不会对数据库进行查询。假设没有进行插入、更新或删除，如果应用程序运行足够长的时间，则其中的所有信息都可能成为持久信息。这是否意味着在某个时候，我将不再需要数据库

编辑

---

我的问题不在于数据库。我确信不能从应用程序外部修改数据库。我自己管理事务，所以一旦提交，数据就会存储在数据库中。我的问题是：在我提交之后，实体会发生什么？它们是否保存在内存中并像缓存一样工作？如果是的话，他们在那里呆多久？提交

持久化

后，我进行

选择

查询。这个选择应该返回我之前保存的对象。该对象是从内存中获取的，还是应用程序将查询数据库？

不太可能。想想看

您的应用程序可能不是唯一使用数据库的东西。如果一个实体被持久化一次并存储在内存中，那么您如何确保，比方说，一小时后，它不会被其他方式更改？如果发生这种情况，您将有可能损害应用程序逻辑的陈旧数据

---

将数据存储在内存中并希望一切正常不会带来任何好处。这就是为什么存储在数据库中的数据是您的主要信息源，您应该每次都查询它，除非您绝对确定数据子集不会更改。

持久性简而言之就是：您可以关闭应用程序，并且数据不会丢失

---

要实现这一点，您需要一个数据库或某种类型的保存数据的方式，以便在关闭应用程序时不会丢失数据。

当您持久化一个实体时，该实体将添加到持久化上下文中，其作用类似于一级缓存（在内存中）。实际持久化发生的时间取决于您是使用容器管理的事务还是自己处理事务。只要事务未提交，实体实例就将驻留在内存中，当事务提交时，它将被持久化到数据库或XML等中。

要“持久化”实体，意味着将其实际保存在数据库中。当然，JPA在持久性上下文中在内存中维护一些实体信息（这在很大程度上取决于配置和编程实践），但在某些时候信息将存储在数据库中-例如，当事务提交时，或者可能（但不一定）在

flush（）或
merge（）之后
操作。
JPA不能仅使用持久性上下文（一级缓存）或显式缓存（二级缓存）。它总是需要与一个数据源相结合，这个数据源通常指向一个持久化到稳定存储的数据库

因此，只有当事务（JPA持久化操作所需）未提交时，实体才在内存中。之后，它被发送到数据源

如果事务管理器是事务范围的（“正常”情况），则一级缓存（持久性上下文）关闭，实体不再存在。如果一级缓存以某种方式困扰您，您可以显式地对其进行管理。有一些操作可以清除它，您可以将读操作（不需要事务）与写操作分开。如果在读取时没有事务处于活动状态，那么就没有持久性上下文，一个实体将永远不会被连接，因此永远不会被放入这个一级缓存

但是，当事务提交时，二级缓存不会被清除，并且其中的实体对于整个应用程序仍然可用。必须显式配置此二级缓存，并且作为应用程序开发人员，您必须指示应在其中缓存哪些实体。通过特定于供应商的机制（例如JBoss Cache、Infinispan），您可以设置被缓存实体的最大数量，并设置/定义所谓的逐出策略

当然，没有什么可以阻止您让数据源指向内存中嵌入的DB，但这超出了JPA的知识范围。
如果您希望在提交后保留实体，并且对于select查询，您需要使用查询缓存。只要用谷歌搜索一下这个术语，你就会明白。
那么，在一次交易之后，所有对象都会被删除，只剩下数据库中的数据？是的，这几乎是正确的。但是，如果您仍然获得了对entitymanager中持久化的实体对象的引用，那么它仍将保留在内存中。但是，当事务结束时，状态的进一步同步将不会反映在数据库中。我不是要删除数据库。我试图理解在提交之后，是否所有这些实体都将保留在内存中，并像缓存一样工作。我经常需要一些信息。这就是为什么我不想每次都对数据库进行查询。列表是否会在应用程序本身中创建冗余？如果不希望每次都进行查询，可以配置二级缓存，也可以配置查询缓存。在极少数情况下，您也可以选择利用扩展持久性上下文，它使一级缓存在应用程序指定的持续时间内保持打开状态，但这很棘手，因此请先尝试二级缓存；）