Apache Dubbo 序列化异常分析：StackOverflowError 的成因与解决方案

问题背景

在使用 Apache Dubbo 3.3.3 进行服务调用时，开发人员遇到了一个典型的序列化异常问题。当服务端返回包含嵌套对象的复杂数据结构时，客户端在尝试打印日志时抛出 StackOverflowError 异常。这个问题的核心在于对象 toString() 方法的递归调用，而非 Dubbo 框架本身的缺陷。

技术分析

异常现象

在 Dubbo 服务调用场景中，服务端返回的 Squad 对象包含 Member 集合，而 Member 对象又引用了 SquadRole 和 MemberStatus 枚举。当客户端尝试通过日志打印 Squad 对象时，触发了以下调用链：

1. 调用 Squad.toString()
2. 调用 Member.toString()
3. 调用 SquadRole.toString()
4. 再次触发 Member.toString()

这种循环引用导致调用栈不断增长，最终耗尽栈空间抛出 StackOverflowError。

根本原因

问题的根源在于 Lombok 自动生成的 toString() 方法没有处理对象间的循环引用关系。具体表现为：

1. 所有类（包括枚举）都标注了 @ToString 注解
2. 对象间存在双向引用关系
3. 序列化/反序列化过程中需要完整的对象信息
4. 日志打印时触发无限递归

解决方案

方案一：排除特定字段

在 Squad 类中排除可能导致循环的字段：

@ToString(exclude = "members")
public class Squad {
    // 类实现
}

这种方法简单直接，但会丢失部分字段的调试信息。

方案二：手动实现 toString()

更推荐的方式是手动实现 toString() 方法，精确控制输出内容：

@Override
public String toString() {
    return "Squad{" +
           "id=" + id +
           ", members=" + members.stream()
               .map(m -> "Member{userId=" + m.getUserId() + "}")
               .collect(Collectors.toList()) +
           '}';
}

方案三：使用 JSON 序列化

对于复杂对象，可以考虑使用 JSON 序列化代替默认的 toString()：

log.info("Dubbo call result: {}", new ObjectMapper().writeValueAsString(squad));

最佳实践建议

1. 在 Dubbo 服务中，对于包含循环引用的复杂对象：

   • 谨慎使用 Lombok 的 @ToString
   • 考虑实现自定义的序列化逻辑
   • 使用 DTO 对象而非直接暴露领域模型

2. 日志记录建议：

   • 对于核心业务对象，实现有意义的 toString()
   • 避免在 toString() 中包含大集合或复杂对象图
   • 考虑使用调试视图模式

3. Dubbo 特定建议：

   • 检查序列化协议配置（推荐使用 hessian2）
   • 确保服务端和客户端的模型版本一致
   • 对于复杂对象，考虑实现自定义序列化器

总结

这个问题虽然表面上是 Dubbo 服务调用时出现的异常，但本质是对象序列化和日志处理的常见问题。通过合理设计对象的字符串表示形式，既可以避免运行时异常，又能提供有价值的调试信息。在微服务架构中，特别需要注意跨服务边界的数据表示问题。