Hibernate ORM 中文操作指南

这不是 Hibernate 的缺陷或限制；这个问题甚至影响了在 DAO 背后的典型的手写 JDBC 代码。只有你能作为开发者解决这个问题，因为只有你知道在给定的工作单元中你事先需要什么数据。但这没关系。Hibernate 会为你提供你需要的所有工具。

默认情况下已禁用高速缓存。为了最大限度降低数据丢失的风险，我们强制你暂停并思考，然后再将任何实体放入高速缓存。

@Cache 注释总是指定一个 CacheConcurrencyStrategy ，即管理并发事务对二级缓存访问的策略。

表格 47。缓存并发

哪些策略有意义也可能取决于基础二级缓存实现。

它提供的指定缓存实体性质及管理其缓存的方式的信息，且

可能不能用于注释关联，因此我们甚至无法使用它将集合角色标记为有资格存储在二级缓存中。

=== 7.8. Caching by natural id

如果我们的实体有一个 natural id，我们可以通过注释实体 @NaturalIdCache 来启用一个附加缓存，该缓存保存从自然 ID 到主键 ID 的交叉引用。默认情况下，自然 ID 缓存存储在二级缓存的专用区域中，单独于缓存的实体数据。

当使用执行 lookup by natural id 的 Session 的操作之一来检索实体时，将使用此缓存。

值得注意的是，与实体的主标识符不同，自然 ID 可能可变。

现在我们必须考虑一个精细之处，在处理所谓的“参考数据”时经常会出现，即能轻松装入内存且不太会发生变化的数据。

=== 7.9. Caching and association fetching

让我们再次考虑我们的 @{9} 类：

关于出版商的数据不会经常发生变化，而且数量也不多。假设我们已做好一切设置，以便出版商几乎 @{10} 可以在二级缓存中使用。

那么在这种情况下，我们需要仔细考虑类型 @{11} 的关联。

这个关联不需要延迟获取，因为我们希望它可以在内存中使用，因此我们不会设置它为 @{12}。但另一方面，如果我们将其标记为立即获取，则默认情况下，Hibernate 通常会使用连接来获取它。这会给数据库带来完全不必要的负载。

解决方案是 @Fetch 注释：

通过对关联 @{14} 进行注解，我们压制连接获取，给 Hibernate 一个机会在缓存中找到关联的 @{15}。

因此，我们得出了以下经验法则：

其他关联，如我们 already made clear ，应为 LAZY 。

一旦我们将实体或集合标记为符合存储在二级缓存中的条件，我们仍然需要设置一个实际的缓存。

=== 7.10. Configuring the second-level cache provider

配置二级缓存提供程序是一个相当复杂的话题，并且超出了本文档的范围。但是，如果它有帮助，我们经常使用以下配置来测试 Hibernate，其中使用 EHCache 作为缓存实现，如上所示 Optional dependencies：

表格 48. EHCache 配置

如果你正在使用 EHCache，你还需要包含一个 ehcache.xml 文件，该文件明确配置属于你的实体和集合的每个缓存区域的行为。有关配置 EHCache 的更多信息，请参阅 here。

我们可能使用 JCache 的任何其他实现，例如 Caffeine。JCache 会自动选择它在类路径中找到的任何实现。如果类路径上有多个实现，我们必须使用以下内容消除歧义：

表格 49. 消除 JCache 实现歧义

或者，要使用 Infinispan 作为缓存实现，需要以下设置：

表格 50. Infinispan 提供程序配置

当需要分布式缓存时，通常使用 Infinispan。有关将 Infinispan 与 Hibernate 配合使用的更多信息，请参阅 here。

最后，有一种方法可以全局禁用二级缓存：

表格 51. 禁用缓存的设置

设置 hibernate.cache.region.factory_class 时，此属性默认为 true。

您可以在 User Guide 中找到有关二级缓存的更多信息。

=== 7.11. Caching query result sets

我们上面介绍的缓存仅用于通过 ID 或自然 ID 优化查找。Hibernate 还可以缓存查询的结果集，尽管这通常不是有效的方法。

必须显式启用查询缓存：

表格 52. 启用查询缓存的设置

要缓存查询结果，请调用 SelectionQuery.setCacheable(true)：

默认情况下，查询结果集存储在名为 default-query-results-region 的缓存区域中。由于不同的查询应具有不同的缓存策略，因此通常明确指定区域名称：

结果集与 logical timestamp 一起缓存。所谓“逻辑”，即它实际上不会随着时间线性增加，它特别不是系统时间。

当 Product 更新时，Hibernate does not 遍历查询缓存，使受变更影响的每个已缓存结果集失效。而缓存有一个特殊区域存储每个表的最近更新的逻辑时间戳，称为 update timestamps cache，并且保留在区域 default-update-timestamps-region 中。

当从缓存中读取查询结果集时，Hibernate 会将时间戳与影响查询结果的每个表的时间戳进行比较，并且 only 在结果集不是过时的情况下返回结果集。如果结果集 is 过时，Hibernate 将继续执行针对数据库的查询并更新缓存的结果集。

通常情况下，二级缓存与任何二级缓存一样，都会破坏事务的 ACID 规则。

=== 7.12. Second-level cache management

二级缓存大多数是透明的。与 Hibernate 会话交互的程序逻辑不知道该缓存，并且不受缓存策略变更的影响。

最差情况下，可以通过指定显式 CacheMode 来控制与缓存的交互：

或者，使用 JPA-standard API：

JPA 定义的缓存模式分为两种：CacheRetrieveMode 和 CacheStoreMode。

表 53. JPA 定义的缓存检索模式

如果我们担心从缓存读取陈旧数据，则可以选择 CacheRetrieveMode.BYPASS。

表 54. JPA 定义的缓存存储模式

如果我们查询不需要缓存的数据，则应该选择 CacheStoreMode.BYPASS。

在 JPA 中，我们将使用此惯用语：

但是 Hibernate 有更好的方法：

Hibernate CacheMode 使用 CacheStoreMode 打包 CacheRetrieveMode。

表 55. Hibernate 缓存模式和 JPA 等效项

没有特别的理由选择 Hibernate 的 CacheMode 而不是 JPA 等效项。这种枚举只存在于 Hibernate 拥有缓存模式的时候，远早于将其添加到 JPA 的时候。

SessionFactory sessionFactory = setupHibernate(new Configuration()) .buildSessionFactory(); sessionFactory.inSession(session → { session.createSelectionQuery("from Country")) .setReadOnly(true) .getResultList(); session.createSelectionQuery("from Product where discontinued = false")) .setReadOnly(true) .getResultList(); }); SessionFactory sessionFactory = setupHibernate(new Configuration()) .buildSessionFactory(); sessionFactory.inSession(session → { session.createSelectionQuery("from Country")) .setReadOnly(true) .getResultList(); session.createSelectionQuery("from Product where discontinued = false")) .setReadOnly(true) .getResultList(); });

极少情况下，需要或可控明确地控制缓存，例如，清除我们知道已过时的某些数据。Cache 接口允许以编程方式清除缓存的项目。

但是，通常在修改后，Hibernate 会自动逐出或更新缓存的数据，此外，未使用的缓存数据最终会根据配置的策略过期。

这与一级缓存中发生的情况完全不同。

=== 7.13. Session cache management

当不再需要实体实例时，它们不会自动从会话缓存中清除。相反，它们在程序丢弃它们所在的会话之前一直固定在内存中。

方法 detach() 和 clear() 允许你从会话缓存中删除实体，使其可供垃圾回收。由于大多数会话的持续时间都很短，因此你不太需要进行这些操作。而且如果你发现自己在想自己在某种情况下需要 do，则应该认真考虑替代解决方案：一个 stateless session。

=== 7.14. Stateless sessions

Hibernate 一个可以说未被充分重视的特性是 StatelessSession 接口，它提供了一种面向命令、更底层的与数据库交互的方法。

你可以从 SessionFactory 获取无状态会话：

一个无状态会话：

对于无状态会话，我们始终使用分离的对象。因此，编程模型有点不同：

表 56. StatelessSession 的重要方法

特别是，没有持久性上下文意味着我们可以安全地执行批量处理任务，而无需分配大量内存。使用 StatelessSession 减轻了调用它的需求：

=== 7.15. Optimistic and pessimistic locking

最后，我们没有在上面提到的受载期间行为的一个方面是行级别数据争用。当许多事务尝试读取和更新相同数据时，程序可能会因锁升级、死锁和锁获取超时错误而失去响应。

Hibernate 中有两种基本的数据并发方法：

在 Hibernate 社区中，使用乐观锁定更常见，而 Hibernate 让这件事变得非常容易。

也就是说，那里 is 也有悲观锁，它有时可以降低事务回滚的可能性。

因此，响应会话的 find() 、 lock() 和 refresh() 方法接受一个可选的 LockMode 。我们还可以为查询指定一个 LockMode 。锁定模式可用于请求悲观锁定或自定乐观锁定的行为：

表 57. 乐观和悲观锁模式

请注意，即使实体未经修改，OPTIMISTIC 锁也会始终在事务结束时进行验证。这与大多数人谈论“乐观锁”时的意思略有不同。从不必要在已修改实体上请求 OPTIMISTIC 锁，因为版本号总是在执行 SQL update 时进行验证。

=== 7.16. Collecting statistics

我们可以通过设置此配置属性来让 Hibernate 收集其活动相关统计信息：

这些统计数据由 Statistics 对象公开：

Hibernate 的统计信息支持可观察性。 Micrometer 和 SmallRye Metrics 都能够公开这些指标。

=== 7.17. Tracking down slow queries

当在生产环境中发现某个 SQL 查询性能欠佳时，有时很难准确地跟踪到查询的 Java 代码位于何处。Hibernate 提供了两个可以使识别缓慢查询及其来源变得更简单的配置属性。

表 58. 跟踪慢查询的设置

当 hibernate.use_sql_comments 启用时，HQL 查询的文本会作为注释添加到生成的 SQL 前面，这通常可以让用户轻松地在 Java 代码中找到 HQL。

可以自定义注释文本：

一个专业定义的索引可能是修复慢查询所需的一切。

=== 7.18. Adding indexes

@Index 注释可用于向表格添加索引：

甚至可以为编制索引的列指定排序，或者指定索引应该不区分大小写：

这使我们可以为特定查询创建自定义索引。

请注意，诸如 lower(title) 的 SQL 表达式必须用括号括起来放在索引定义的 columnList 中。

=== 7.19. Dealing with denormalized data

一个规范化架构中的典型关系数据库表只包含少数列，因此，有选择地查询列并只填充实体类的某些字段几乎没有好处。

但是偶尔，我们听到有人询问如何映射有数百列或更多列的表！这种情况可能在以下情况下出现：

我们假设我们正在_not_处理最后的可能性。那么我们希望能够查询该巨型表，而不返回其所有列。乍一看，Hibernate 并不能为该问题提供完美的瓶装解决方案。这种第一印象是误导。实际上，Hibernate 提供了多种应对这种情况的方法，而真正的问题在于如何在这些方法之间进行选择。我们可以：

其他一些 ORM 解决方案将第三个选项作为处理巨型表的推荐方法，但这一直不是 Hibernate 团队或 Hibernate 社区的偏好。使用前两个选项中的一个更加类型安全。

=== 7.20. Reactive programming with Hibernate

最后，现在许多需要高可扩展性的系统都会使用反应式编程和反应式流。 Hibernate Reactive 将 O/R 映射引入反应式编程的世界。你可以从其 Reference Documentation 了解更多有关 Hibernate Reactive 的信息。