Java序列化内置句柄表机制，自动用TC_REFERENCE标记处理循环引用，避免栈溢出；而JSON库如Jackson默认不启用引用跟踪，易因深度遍历导致StackOverflowError。
java序列化本身已内置循环引用防护机制，不会因对象图中存在a→b→b→a这类结构而栈溢出。真正导致栈溢出的，通常是反序列化端（尤其是json类库）未启用引用跟踪，或手动实现序列化逻辑时忽略了句柄表机制。
理解Java原生序列化的循环引用保护
Java标准序列化（java.io.Serializable）通过内部“对象句柄表”自动记录已写入对象的ID。当遇到第二次出现的同一对象（包括循环引用中的回边），它不重复序列化字段，而是写入一个轻量级的“引用标记”。这个机制天然防止无限递归和栈溢出。
- 对象A持有一个对B的引用，B又持有一个对A的引用：序列化时只完整写出A和B各一次，第二次出现的A用
TC_REFERENCE标记指向首次位置 - 该机制对开发者透明，无需额外注解或配置，只要类实现
Serializable即可生效 - 反序列化时，句柄表同样被重建，确保引用关系准确还原，包括原始的循环结构
JSON序列化才是循环引用高发区
像Jackson、Fastjson、Gson等JSON库默认不开启引用解析，它们把对象当树形结构遍历，一旦遇到循环就会反复深入，最终触发StackOverflowError。这不是Java序列化的问题，而是JSON序列化策略的选择问题。
- Jackson需显式启用：
objectMapper.configure(SerializationFeature.FAIL_ON_EMPTY_BEANS, false); objectMapper.enableDefaultTyping();或使用@JsonIdentityInfo注解标记主键字段 - Fastjson 1.2.83+ 默认开启
$ref支持；旧版本可设置SerializerFeature.DisableCircularReferenceDetect为false（即开启检测） - Gson需搭配
GsonBuilder.setExclusionStrategies()或自定义TypeAdapter跳过循环路径
规避栈溢出的关键操作点
不要试图在业务对象里“删掉引用”来治标，应从序列化入口统一管控。重点不在“怎么绕过”，而在“怎么让框架识别并处理”。
- 明确区分场景：跨JVM通信优先用Java原生序列化或Protobuf；面向前端/开放API必须用JSON时，强制统一使用支持引用的库版本与配置
- 对无法修改的遗留类（如含双向导航属性的JPA Entity），在DTO层做裁剪，用
@JsonIgnore或@JsonBackReference切断遍历链 - 禁用全局
FAIL_ON_SELF_REFERENCES类开关——它只是抛异常，并不解决问题；应启用WRITE_DATES_AS_TIMESTAMPS等配套特性保障类型兼容性 - 日志或调试时临时序列化，可用
ObjectMapper.writerFor(YourClass).without(SerializationFeature.FAIL_ON_EMPTY_BEANS)快速绕过校验，但不可用于生产响应
替代思路：绕开序列化本身
如果循环结构复杂且稳定，与其在序列化环节打补丁，不如换数据形态。
- 将对象图转为扁平ID映射表 + 关系列表，前端或下游服务自行组装，彻底规避嵌套深度问题
- 对读多写少场景，直接缓存JSON字符串（而非每次实时序列化），由构建阶段预处理好引用关系
- 微服务间通信改用gRPC + Protobuf，其IDL契约天然禁止隐式循环，编译期即报错
