首先，让我们谈谈进程级缓存（或在Hibernate中称为二级缓存）。要使其正常工作，您应该

1. 配置缓存提供程序
2. 告诉hibernate要缓存哪些实体（如果使用这种映射，则在hbm.xml文件中）。

您告诉缓存提供程序应存储多少个对象以及何时/为什么使它们无效。因此，假设您有一个Book和Author实体，每次从数据库中获取它们时，只会从实际的DB中选择那些不在缓存中的实体。这样可以显着提高性能。在以下情况下很有用：

• 您仅通过Hibernate写入数据库（因为它需要一种方法来知道何时更改或使高速缓存中的实体无效）
• 你经常阅读物体
• 您只有一个节点，并且没有复制。否则，您将需要复制缓存本身（使用JGroups之类的分布式缓存），这会增加更多的复杂性，并且扩展性不及无共享应用程序。

那么什么时候缓存起作用？

• 当您session.get()或session.load()先前选择并驻留在缓存中的对象时。缓存是一种存储，其中ID是键，属性是值。因此，只有在有可能通过ID搜索时，您才可以消除命中数据库的麻烦。
• 当您的关联被延迟加载（或使用selects而不是joins加载时）

但是在以下情况下不起作用：

• 如果您未按ID选择。再说一遍-2级缓存将实体ID映射到其他属性（它实际上并不存储对象，但存储数据本身），因此，如果您的查找如下所示：from Authors where name = :name，则不要命中缓存。
• 使用HQL时（即使使用where id = ?）。
• 如果在映射中设置fetch="join"，这意味着要加载关联，联接将在各处使用，而不是单独的select语句。进程级缓存仅在fetch="select"使用子对象时才起作用。
• 即使您有，fetch="select"但随后在HQL中，您也可以使用联接来选择关联-这些联接将立即发出，并且它们将覆盖您在hbm.xml或注释中指定的内容。

现在，关于查询缓存。您应该注意，它不是一个单独的缓存，它是对进程级缓存的补充。假设您有一个Country实体。它是静态的，所以您知道每次说时都会有相同的结果集from Country。这是查询缓存的理想选择，它将自身存储一个 ID
列表，当您下次选择所有国家/地区时，它将把此列表返回到流程级缓存，而后者又将为每个ID返回对象。因为这些对象已经存储在二级缓存中。每当与实体相关的任何更改时，查询缓存都会失效。因此，假设您已配置from Authors为放置在查询缓存中。由于作者经常更改，因此无效。