我相信只有两种使用Hibernate加载对象的方式，那就是延迟加载，一种是急切加载。延迟加载有其自身的优势，它不会加载大量对象，而只会在您需要它们时加载。我也了解到，如果你想强制加载一个对象的所有孩子，你可以简单地调用parent.getChildren().size()。所以我们可以说，我们有以下对象什么时候在休眠时使用Lazy加载/ Eager加载？
@Entity
public class Customer{
public Set<Order> order;
}
@Entity
public class Order{
}
假设我们有谁在我们的系统中有订单的客户，它可能是多个甚至可以为null。所以我的问题是，在这种情况下总是使用急切加载不是更好吗？我们需要与客户相关的订单的大小或一些信息。在这种情况下使用延迟加载有什么好处，有什么好处吗？
我想了解在哪里使用延迟加载和在哪里使用急切加载，非常感谢您的洞察力。
我想了解在哪里使用延迟加载和在哪里使用 渴望加载，非常感谢您的洞察力。
这里有几个想法：
1）如果你要经常使用的东西（肯定的），你可以贪婪加载它。
2）与1相关，如果你几乎永远不会使用某些东西，可以懒加载它。
3）当涉及大型集合时，延迟加载往往更有用。
4）急切地加载东西会减少与会话有关的错误，而这可能会导致性能下降。
5）对于复杂的数据模型和/或大型数据库，您将看到您的应用在加载时如何调整策略。
6）第一次很难让它正确。做正确的事情，如果有必要，不要害怕改变。
7）对于大型数据集，您可能最终会编写自定义的hql /查询，其中默认映射可以被覆盖，所以懒惰vs渴望无关紧要。
如果你相信＃6，那么不要被卡住，试图计划太远，如果你必须改变它。
WRT您的具体的例子，我可能会写一堆查询访问的数据（通过适当的业务需求驱动的，当然）
1）加载客户的查询，并留下订单在db（懒惰加载），当我需要获取客户信息时我会打电话
2）加载客户和所有订单信息的查询，用于需要的情况。所以这种情况下，我会忽略默认映射。
有了这两个查询，在我的服务层中，我有我需要的工具来根据情境的上下文来做正确的事情。
This link完美回答你的问题。
延迟加载在相关实体尺寸是巨大的情况下使用，它不是必须每次都被拿来另一方面
EAGER应与适当的分析可以作为它的每一个主时加载的关系实体被加载。
因此，如果一个关系对于业务逻辑计算是绝对必要的，您应该考虑使用EAGER加载; LAZY的加载将为大多数情况提供服务，并且提供较少的性能问题。
我完全同意，编写两个单独的查询比使用lazy/eager loading要好得多。感谢您的澄清。 –
@hvgotcodes你能解释如何实现点＃7吗？ –