Spring中@OneToMany与@ManyToOne懒加载序列化表现差异解惑

实体模型定义 #

@Data /*用于生成getter和setter*/
@Entity
@Table(name = "customers")
public class Customer {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private long id;

    @OneToMany(mappedBy = "customer", cascade = CascadeType.ALL, fetch = FetchType.LAZY)
    private List<Address> addresses;
}

@Data /*用于生成getter和setter*/
@Entity
@Table(name = "addresses")
public class Address {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private long id;

    private String addressLine;

    @ManyToOne(optional = false, cascade = CascadeType.ALL, fetch = FetchType.LAZY)
    private Customer customer;
}

注意：@OneToMany和@ManyToOne均使用fetch = FetchType.LAZY

现象描述 #

• 访问REST资源http://localhost:8080/customers/1/addresses时，应用可正常返回地址列表。
• 访问REST资源http://localhost:8080/addresses/18814/customer时，应用崩溃并抛出序列化错误，提示org.hibernate.proxy.pojo.bytebuddy.ByteBuddyInterceptor无法序列化。

经排查，错误源于address.getCustomer()返回Customer代理对象而非实体本身，但同样是懒加载的customer.getAddresses()却能正常工作，请问这背后的原因是什么？

原因解析 #

1. 懒加载的实现机制不同 #

• @OneToMany标注的集合属性，Hibernate使用PersistentBag/PersistentList这类自定义集合类实现懒加载。这类集合本身实现了序列化接口，并且在被访问（比如序列化时遍历元素）时，会自动触发Hibernate的懒加载初始化，从数据库加载真实数据，最终序列化的是真实的Address实体集合。
• @ManyToOne标注的单个实体属性，Hibernate通过ByteBuddy生成的动态代理类实现懒加载。这个代理类会持有ByteBuddyInterceptor对象用于延迟加载逻辑，该拦截器并未实现序列化接口。当代理对象未被初始化（会话已关闭无法触发加载）时，序列化框架会尝试序列化整个代理对象，包括这个拦截器，从而抛出序列化错误。

2. 请求处理时的会话状态差异 #

• 访问/customers/1/addresses时，Spring Data REST的处理流程通常会在Hibernate会话打开的状态下处理序列化。当序列化集合时，Hibernate会自动初始化懒加载集合，此时集合中的数据已经被加载，不存在代理序列化问题。
• 访问/addresses/18814/customer时，获取Address实体后，Hibernate会话可能已经关闭（比如事务已提交）。此时customer属性是未初始化的代理对象，无法再触发数据库查询加载真实数据，序列化时只能处理代理对象本身，进而因为拦截器无法序列化报错。

3. Spring Data REST对关联的处理逻辑不同 #

Spring Data REST对集合类型的关联有特殊处理：它会主动触发集合的初始化，确保序列化时是真实的实体集合；但对于单个实体的关联，默认不会主动触发懒加载初始化。如果会话已经关闭，代理对象无法被初始化，就会导致序列化失败。

内容的提问来源于stack exchange，提问作者Claudi