先说一个我在实际项目里栽过的跟头。当时做一个后台订单明细页面需要展示订单关联的用户昵称。代码看起来一切正常Service 层加了TransactionalController 层把订单实体直接返回给前端结果请求一打进来直接爆了org.hibernate.LazyInitializationException: could not initialize proxy [com.example.User#3] - no Session我第一反应是订单对象明明是从数据库里查出来的为什么order.getUser()一访问就报错后来开着 SQL 日志一步步看才算彻底明白——Hibernate 查订单的时候并没有把用户表一起查出来而是等到我访问order.getUser().getNickName()的那一刻才准备补发 SQL但这时候事务已经提交、Session 已经关了查询没地方发只能抛异常。这个事故引出的两个概念就是标题里的延迟加载Lazy Loading和急加载Eager Loading。Hibernate 之所以搞出这两种加载策略本质上是在回答同一个问题当你加载一个实体的时候它关联的那些对象到底要不要一起查出来这篇文章我不打算只背定义而是把这两个东西从底层机制、默认策略、常见报错到 SQL 性能逐层讲透看完你不仅能答面试题回到项目里也知道该怎么下手。1. 先用一次线上报错把两个概念摆明1.1 事故是怎么发生的先看实体结构。订单和用户是多对一关系Entity Table(name orders) public class Order { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; ManyToOne(fetch FetchType.LAZY) JoinColumn(name user_id) private User user; private BigDecimal amount; }Service 层代码很常规Service public class OrderService { Transactional public Order getOrderById(Long id) { return orderRepository.findById(id).orElse(null); } }Controller 层直接把实体丢给前端GetMapping(/order/{id}) public Order getOrder(PathVariable Long id) { return orderService.getOrderById(id); }前端要展示用户昵称JSON 序列化的时候 Jackson 会去调用order.getUser().getNickName()。这一步发生在 Controller 返回之后、事务已经提交、Session 已经关闭的时机所以 Hibernate 感觉自己被背叛了当初你说先不查 User现在 Session 都没了又来找我要我给不了。于是抛LazyInitializationException。当时我犯的最大的错误是把实体对象直接返回到了 Web 层。实体在数据库事务里是“托管状态”事务结束就变成了“游离状态”游离实体的未加载关联属性根本不应该再被访问。这个设计问题才是事故的根不是LAZY本身的锅。1.2 好多人第一反应把注解改成 EAGER网上搜这个问题大量回答会说“把fetch FetchType.LAZY改成FetchType.EAGER”。当时我也这么干了ManyToOne(fetch FetchType.EAGER) JoinColumn(name user_id) private User user;改成 EAGER 之后查订单的时候 User 会跟着一起查出来不再存在“用到的时候才去查”的代理对象页面立刻不报错了。但没过两周新的问题冒出来了。订单列表接口开始变慢。每次查订单即使页面上只需要显示订单号和金额Hibernate 也要强制把 User 表 join 进来后来 User 又关联了 DepartmentDepartment 又关联了一堆角色权限层层 EAGER 直接把一条简单查询变成了一个多表大 join。再往后列表接口频繁出现重复数据、查询延迟、数据库连接被拖住跟当初的LazyInitializationException比起来更难受。所以遇到这个问题先把错误信息读懂比急着改注解重要得多。1.3 一句话解释两种加载策略用大白话讲延迟加载查订单时只查订单User 先记一个“欠条”放那儿等真的要用.getUser()的时候再补发 SQL 去查用户。省资源但依赖数据库会话还活着。急加载查订单时不管后面用不用先把 User 一起查出来全部塞到内存里。省心但什么时候、查多少、会不会浪费全由不得你控制。两者的核心差异就两个字时机。下面用表格把差异列一下对比项延迟加载Lazy急加载Eager加载时机第一次访问关联属性时主实体加载时立刻加载SQL 表现先一条主查询后续按需补查可能 JOIN也可能立即补发多条 SQL资源占用开始时少后续不确定开始时多浪费概率高典型问题会话关闭后访问报异常N1、笛卡尔积、加载大量无用数据适合场景一对多、多对多、列表查询单对象必用关联、关联数据量小且固定2. 默认加载策略并非巧合为什么 Hibernate“能懒则懒”2.1 一张表记清 JPA 的默认值JPA 规范对不同关联关系给了不同的默认加载策略Hibernate 作为 JPA 的实现大部分情况下遵循这套默认值关联关系默认 fetch直观理解ManyToOneEAGER多个订单对应一个用户查订单时把用户带出来成本低OneToOneEAGER主对象和副对象基本一一对应查一个带一个很自然OneToManyLAZY一个用户可能有一万条订单查用户时把订单全查出来是灾难ManyToManyLAZY多对多往往伴随大量中间表数据默认急加载很容易爆这套默认值不是拍脑袋定的。多对一和一对一关联目标往往是“父级信息”、“归属信息”像订单属于哪个用户、这个用户属于哪个部门大部分业务场景里你迟早要用用一条 SQL 带出来成本可控。但一对多和多对多完全相反一个用户关联的订单数量是未知的可能几十条也可能几千条如果查用户都急着把订单全查出来很多根本用不上白白浪费数据库和内存。所以 Hibernate 的设计哲学可以概括为能确定要用的就急加载不能确定要用的就延迟加载。后面你会看到真正的问题往往出在“你以为确定但其实不是所有场景都确定”。2.2 底层机制代理对象和持久化集合延迟加载能成立靠的不是魔法而是两个底层机制。单值关联靠代理对象Proxy。当你查到一个 Order 并希望关联的 User 是懒加载时Hibernate 并不会真的往user字段里塞一个null而是塞一个 User 类的动态子类代理对象。这个代理对象和真正的 User 长得几乎一样但它内部只是个壳真正数据还没加载。等你调用user.getNickName()这类业务方法时代理会拦截调用先检查当前有没有可用的 Session有就立刻发 SQL 加载真身然后把结果返回给你。User user em.getReference(User.class, 1L); // 不立即查库返回代理 System.out.println(user.getClass().getName()); // 输出类似 com.example.User$HibernateProxy$xxx Long id user.getId(); // 主键在代理创建时就已知不会触发加载 String nick user.getNickName(); // 这一行才真正触发 SQL注意一个小细节代理对象是 Hibernate 通过生成实体类的子类来实现的所以实体类和 getter 方法不能是final否则 Hibernate 无法生成子类去拦截方法调用。你如果踩到过“延迟加载不生效”的坑先看一眼实体类是不是被谁加了final。集合关联靠 PersistentCollection。ListOrder、SetRole这种集合属性懒加载的时候Hibernate 往字段里塞的是一个它自己实现的集合容器比如PersistentBag、PersistentSet。这个容器只是个空壳真正从数据库装数据是在你第一次调用size()、iterator()、contains()这些方法的时候它才意识到“哦该加载了”。理解代理和持久化集合这两个概念是理解后续所有坑的基础。你访问一个懒加载属性本质上是在触发一次延迟 SQL。2.3 级联Cascade和加载策略是两码事很多初学者会把cascade和fetch弄混因为它们在注解里经常同时出现OneToMany(fetch FetchType.EAGER, cascade CascadeType.ALL) private ListOrder orders;这俩完全不沾边。cascade控制的是“操作传播”。比如cascade CascadeType.ALL表示保存 User 时会连带保存 orders 里的 Order删除 User 时会连带删除订单。fetch控制的是“加载时机”。它只回答“查 User 的时候查不查 orders”这个问题。把级联操作设置得再丰富也不会影响懒加载是否生效反之改了fetch也不会让删除操作自动传播到关联对象。这两个维度是正交的排查问题的时候别把它们混为一谈。3. 急加载不只有一种写法三种实现方式与取舍3.1 映射注解直接改成 EAGER尽量少用最直接的急加载方式是在实体映射上写OneToMany(mappedBy user, fetch FetchType.EAGER) private ListOrder orders;这样一旦查询 UserHibernate 会立刻加载它的 orders 集合。这么做最大的问题在于这个急加载策略是全局的所有查询 User 的地方都会受影响。你可能只是在后台管理页想查一个用户的基本信息Hibernate 也得把这个用户所有订单全查出来。更麻烦的是如果实体上同时有两个一对多集合都设置成 EAGER比如 User 同时有 orders 和 addressesHibernate 为了把两个集合都带出来往往会产生笛卡尔积用户有 100 个订单又有 2 个地址结果数据行数可能变成 200 行中间还夹着大量重复数据内存直接吃紧。所以我现在看到项目里有人写fetch FetchType.EAGER第一反应不是夸他“考虑周全”而是去查这个大集合。要急加载优先考虑下文更局部、更可控的方式。3.2 用 JPQL join fetch 做定点急加载我在项目里最推荐的急加载方式是查询方法上的join fetch。它只影响当前这次查询不会污染实体全局映射。Query(select o from Order o left join fetch o.user where o.id :id) Order findWithUserById(Param(id) Long id);这段 JPQL 的意思是查订单的同时用一条 SQL 把关联的 User 一起查出来。查询返回之后order.getUser()不再是代理对象已经带着真实数据了后面即使离开事务也不会报LazyInitializationException。如果是一对多集合注意去重Query(select distinct u from User u left join fetch u.orders where u.id :id) User findWithOrdersById(Param(id) Long id);distinct是为了消除一对多 join 导致的重复 User 记录。有人会问Java 对象不是有引用比较吗Hibernate 结果集转换时会把同一行的同一个实体重复塞进 List所以需要 distinct。还有一个 JPA 标准的替代方案是EntityGraph在 Spring Data JPA 里维护起来更灵活EntityGraph(attributePaths {user}) Query(select o from Order o where o.id :id) Order findWithUserByGraph(Param(id) Long id);两种方式本质是一样的在当前查询范围内把某个关联路径改成急加载。映射实体保持默认策略不变别的查询方法不受影响。3.3 DTO 投影不用纠结急不急的务实方案还有一种绕开加载策略纷争的解法查询直接返回 DTO根本不加载完整实体。Query( select new com.example.dto.OrderBriefDTO(o.id, u.nickName, o.amount) from Order o join o.user u where o.id :id ) OrderBriefDTO findBriefDtoById(Param(id) Long id);这种方式对 SQL 的形状有完全的控制权只需要订单号和用户昵称就只查这两个字段不加载整个 Order、整个 User更不用纠结它们是懒还是急。DTO 构造器表达式在 Hibernate 里执行效率并不低因为省掉了一大堆实体状态管理开销。从架构层面看DTO 投影也倒逼你不在 Service 层往外丢实体自然就规避了事务边界上的大量问题。我在实际项目里列表页和详情页大部分查询都是优先走 DTO 投影少部分确实要拿到完整实体做复杂业务处理的才会用 join fetch。下面把三种方式的差异摆一起方式SQL 可控性影响范围典型场景主要风险映射注解 EAGER不可控全局小字典型数据、关联必然要用笛卡尔积、无用数据加载join fetch / EntityGraph可控当前查询某个业务要用关联、单条主对象详情一对多集合并发分页时内存分页DTO 投影完全可控当前查询列表展示、部分字段拼装写 JPQL 构造器表达式稍繁琐4. 延迟加载最常见的炸法从 LazyInitializationException 排查到修复4.1 异常的本质持久化上下文关了代理还欠着一笔查询接触 Hibernate 的人几乎都会遇到LazyInitializationException看到那段报错后第一反应基本都是懵的。它的本质其实很简单你在 Session 打开的时候查了一个 UserHibernate 返回的 User 里有一个关联集合还没加载等到 Session 关闭之后你再访问这个集合Hibernate 想帮你补发 SQL却发现没有可用连接只能抛异常。用代码还原一下public User getUserOutsideTx(Long id) { try (Session session sessionFactory.openSession()) { Transaction tx session.beginTransaction(); User user session.get(User.class, id); tx.commit(); // Session 还没关但已经 commit return user; // 返回给外面 } // Session 关闭 } // 外部调用 User user getUserOutsideTx(1L); System.out.println(user.getOrders().size()); // 这里报 LazyInitializationException注意一个细节很多框架下 Session 的关闭时机不等于事务提交时机尤其是在 Spring 的Transactional管理下Service 方法返回时事务提交然后 EntityManager 才关。Controller 或视图层拿到的是游离实体再访问懒加载属性就报错。4.2 我当时是怎么一步步排查的那次线上出问题我按下面顺序排查第一步先看异常栈。栈里明确指向Order.getUser()调用链问题是no Session。第二步打开 Hibernate SQL 日志spring.jpa.show-sqltrue spring.jpa.properties.hibernate.format_sqltrue发现查询 Order 的时候只有一条 SQLHibernate: select o1_0.id,u1_0.id,o1_0.amount from orders o1_0 left join users u1_0 on u1_0.ido1_0.user_id where o1_0.id?等等如果这一条已经 join 了 users为什么还会报错这里要仔细想。我看到这条日志时也愣了一秒后来才意识到我的Order.user映射里已经改成了 EAGER所以确实 join 了真正出问题的实际上是另一个懒加载属性是 User 内部的角色列表。说明线上环境里实体关系已经比最初复杂多了一层套一层地懒加载任何一层没加载在事务外访问都会炸。第三步把 Controller 返回类型改为 DTO在 Service 事务内完成所有数据转换然后观察异常是否消失。第四步排查还存在哪些“List 嵌套 List”的懒加载访问点对确实需要的数据用 join fetch 显式加载。那次修完最大的体会是LazyInitializationException 不是一个“把注解改成 EAGER”就能解决的孤立问题它是设计问题传到你面前的信号。谁在事务外访问了不该访问的实体关联谁就应该在事务内把数据准备好。4.3 五种应对方案横评不同项目阶段、不同耦合度下处理手段不一样。下面五种我都用过利弊很清楚方案做法优点缺点DTO 在事务内转换Service 查完后立刻转 DTO 返回治本、不暴露实体、SQL 可控要写 DTO代码变多join fetch / EntityGraph查询时把需要的关联一起捞出来局部生效、SQL 可控可能遇到集合分页问题Hibernate.initialize()在事务内手动加载Hibernate.initialize(user.getOrders());| 简单直接 | 手动维护漏一个就炸 | | 延长事务边界 | 把 Transactional 扩大到 Controller | 改动小 | Web 层拿数据库连接长事务风险大 | | Open Session in ViewOSIV | Spring Boot 默认开启 | 视图层能访问懒属性 | 连接占用时间变长高并发下容易拖垮连接池 |这里重点说下 OSIV。Spring Boot 从 2.0 开始默认开启spring.jpa.open-in-viewtrue日志里还会打一行警告大致意思是“open-in-view 是默认开启的你可能在视图渲染期间执行数据库查询”。很多人图省事就一直开着页面确实不报LazyInitializationException了但代价是数据库连接从请求进来到视图渲染完都一直被占着。在高并发场景下连接池很容易被打满。我的习惯是能不开就不开尽量不要让视图层具备触发 SQL 的能力。5. 藏在 SQL 背后的性能账N1、批量抓取与大小查询取舍5.1 N1 查询是怎么被延迟加载放大的延迟加载本身不是性能问题的根源真正可怕的是“懒加载 循环访问”组合出来的 N1 查询。看这段典型代码ListUser users userRepository.findAll(); for (User user : users) { System.out.println(user.getOrders().size()); }表面上看你只调用了一次查询用户的方法。但如果user.orders是懒加载程序执行时会变成这样Hibernate: select ... from users Hibernate: select ... from orders where user_id 1 Hibernate: select ... from orders where user_id 2 Hibernate: select ... from orders where user_id 3 ...查出 1000 个用户就会再执行 1000 条订单查询总共 1001 条 SQL这就是 N1。数据库连接往返成本被放大了无数倍。很多 N1 发生在你完全没意识到的地方遍历用户时访问user.getProfile()渲染页面时访问order.getItems()导出报表时访问order.getUser().getAddress()。一层套一层SQL 数量爆炸式增长而日志里每一条单独看都正常。5.2 BatchSize 是个实用救兵但别把它神化解决 N1 最常见的手法之一是用BatchSize做批量初始化Entity public class User { OneToMany(mappedBy user) BatchSize(size 50) private ListOrder orders; }它的效果是当程序访问第一个 User 的 orders 时Hibernate 会检查当前持久化上下文里还有哪些 User 对象最多把 50 个 User 的 orders 一起查出来后面 49 个 User 再访问 orders 时就不用再发 SQL 了。假设一次查询出 100 个 User循环里每个人都访问 ordersSQL 的执行次数会从 100 次降到 2 次左右效果立竿见影。也可以全局配置默认批大小spring.jpa.properties.hibernate.default_batch_fetch_size50但要注意BatchSize不是银弹。它适合“已知父实体列表接下来要批量访问某个懒加载集合”的场景如果你的业务只是单个 User、单个 Order访问一次关联就结束了批处理几乎没意义。而且批处理的 SQL 用的是in条件当批大小设置得过大时in后面的参数列表也会很长数据库同样有压力。5.3 一条大 join 和多条小查询的取舍边界聊到急加载很多人会走向另一个极端“既然懒加载会 N1那我干脆把关联全部 join 出来一条 SQL 搞定。”这个思路在单对象详情场景成立但在集合场景会翻车。Query(select distinct u from User u left join fetch u.orders where u.id :id) User findWithOrdersById(Param(id) Long id);假如一个 User 有两万条订单这条 join fetch 会把两万行数据全部加载到内存只为了拼一个 User 对象。如果你还天真地加上分页repository.findWithOrdersById(id, PageRequest.of(0, 10));Hibernate 对带集合 fetch 的查询做物理分页非常痛苦因为它必须先执行完整 join拿到全部结果后再在内存里过滤、去重、切页。日志里可能出现经典的HHH000104: firstResult/maxResults specified with collection fetch; applying in memory警告一旦数据量大内存直接爆。所以正确的姿势是区分场景场景推荐方式单个主对象详情需要关联数据join fetch 没问题但要评估关联数据量级