第23章 JPA / Hibernate 异常

LazyInitializationException：最经典的 JPA 陷阱

@Entity
public class Order {
@OneToMany
private List items;}

// Service 层 @Transactional public Order getOrder { return orderRepository.findById.orElseThrow;} // 事务在这里结束，Session 被关闭

// Controller 层 Order order = orderService.getOrder;order.getItems.size;// LazyInitializationException: could not initialize proxy - no Session }

根本原因： 懒加载时才会向数据库发起查询——但这个“延迟查询”依赖 Hibernate 的Session<\/span> 仍然处于打开状态。一旦事务方法执行结束<\/span> 注解的方法返回后Session<\/span> 会被关闭。此时如果在事务边界之外才第一次访问懒加载字段，就会因为“Session 已关闭、无法发起新查询”而报错。

User Pain Point：

• “The list is empty instead of throwing an exception?怎么说呢，”
• “I can’t debug because an exception appears after my controller has finished processing.”
• “The service returns an entity directly to controller causing lazy load errors on front‑end.”
• “I keep getting NPEs or unexpected nulls when accessing collections.”
• “I’m unsure wher I should fetch lazily or eagerly without affecting performance.”

Avoiding LazyInitializationException ： Solution 1:

• // 在服务层内部提前触发懒加载 @Transactional public Order getOrder { Order order = orderRepository.findById.orElseThrow; // 强制初始化集合，让 Session 在开启状态下完成所有数据库访问 order.getItems.size;return order;} --- This keeps lazy loading within a single transaction. --- \t\t\t\t\t \t\t\t\t\t \t
• // 使用 JOIN FETCH 一次性拉取所有相关联的数据 @Query Optional findByIdWithItems Long id);--- Avoids lazy proxies entirely. --- \t\t\t\t\t \t
• // 改为 EAGER and careful consideration of performance overhead. but beware of N+1 queries if you don’t use fetch joins. best practice is to avoid EAGER unless absolutely necessary. best practice is to avoid EAGER unless absolutely necessary. best practice is to avoid EAGER unless absolutely necessary. best practice is to avoid EAGER unless absolutely necessary. best practice is to avoid EAGER unless absolutely necessary. caution!\t ---\t \t \t
\r

A proper architectural approach:

OptimisticLockException

@Entity
public class Product {
@Version
private Integer version;// JPA 标准乐观锁字段
} 

// 两个并行事务读取相同记录并尝试更新 // Transaction A 提交成功后版本号变为 2 // Transaction B 提交时报错。因为预期版本已被修改 OPTIMISTICLOCKEXCEPTION

请注意，这种冲突是由 JPA 自动抛出的真实异常，与 MyBatis‑Plus 那种仅返回受影响行数不同。若你想要统一错误处理，请捕获这类异常并转换成业务错误码。``

EntityNotFoundException vs Optional 的选型

/* Spring Data JPA findById 返回 Optional，需要显式处理“不存在”的情况 */
Order found = repository.findById
.orElseThrow -> new BusinessExc);

/* getReferenceById 返回一个惰性代理，不立即执行 SQL */ Order proxy = repository.getReferenceById;// 如果 ID 不存在此处不会报错 proxy.getName;// 真正访问属性时才检查是否存在并可能抛出 EntityNotFoundException

END OF ARTICLE