持久化模式，第 2 部分: 提高代码重用和改进性能

核心提示： @ManyToOne(fetch=FetchType.LAZY)publicvoidgetAddress(){惰性映射和 HBM 格式在使用 Hibernate 的 HBM 格式（而不是注解）来定义映射时，实现惰性映射的方式有所不同，持久化模式，第 2 部分: 提高代码重用和改进性能(7)，从

@ManyToOne(fetch=FetchType.LAZY)　
public　void　getAddress()　{　

惰性映射和 HBM 格式

在使用 Hibernate 的 HBM 格式（而不是注解）来定义映射时，实现惰性映射的方式有所不同。从 3.0 版开始，对于用 HBM 文件定义的任何类型的关联，默认的抓取策略都是惰性抓取。即使对于单一对象关联，也不需要进行配置。

惰性抓取的问题

尽管惰性抓取应该作为大多数应用程序的主要抓取策略，但是它增加了复杂性。最严重的问题是 LazyInitializationException。惰性的关联可能在最初装载它的父对象之后很长时间才被访问（并获取相关联的实体）。但是，为了查询关联的数据，需要 Hibernate 会话可用并与数据库连接池中的一个连接相连。如果在获取对象之后关闭 Hibernate 会话和相关联的数据库连接，在访问关联之前没有恢复，那么就会发生这种错误。如果对惰性关联执行查询，但是没有相关联的数据库连接，Hibernate 就会抛出 LazyInitializationException 异常。有许多处理这个问题的策略，但是这个主题超出了本文的范围。

要考虑的另一个问题是，在访问惰性关联时要执行多少个查询。当第一次访问一个惰性关联的实例时，执行一个查询。这对于单一对象实例不是什么大问题，但是循环遍历对象列表很容易导致执行大量查询。例如，假设一个示例程序要输出与 10 个职员相关联的地址。如果使用惰性抓取，在默认情况下将执行 11 个查询 — 执行一个查询获取职员的列表，然后为获取每个职员的地址各执行一次查询。这显然会导致严重的性能问题。这个问题很常见，Hibernate 把这个问题称为 n+1 选择问题。（Martin Fowler 把它称为 波动装载（ripple loading）。）

即时抓取