Java原生序列化默认能正确处理循环引用，其核心是内置对象句柄表机制：首次写入对象时完整序列化并分配ID，再次遇到同一实例则仅写TC_REFERENCE标记指向原位置，反序列化时重建句柄表确保循环关系准确还原；失效场景包括类未实现Serializable、自定义writeObject未调用defaultWriteObject、使用writeObjectUnshared、serialVersionUID不匹配或循环路径经过transient/static字段。
Java 原生序列化（ObjectOutputStream / ObjectInputStream）默认能正确处理循环引用，不会导致栈溢出或数据错乱，这是它区别于多数 JSON 库的关键能力。
它的核心机制是内置的对象句柄表（Handle Table），在序列化过程中自动记录每个已写入对象的唯一 ID。当再次遇到同一个对象实例（包括循环引用中的回边），就不再重复序列化字段，而是写入一个轻量级的引用标记（如 TC_REFERENCE + ID）。
例如：
-
User持有Department引用 -
Department又持有User引用
序列化时：先完整写出User→ 再完整写出Department→ 当再遇到那个User实例时，只写一个引用指令，指向第一次的位置。
反序列化时，句柄表同步重建，确保两个对象间仍保持原始的循环关系，且是同一份实例（内存地址一致）。
立即学习“Java免费学习笔记（深入）”；
哪些情况会破坏这个机制？
以下操作会让循环引用处理失效或出错：
- 某个类没实现 Serializable 接口，抛
NotSerializableException - 自定义了
writeObject但没调用defaultWriteObject()，跳过了句柄管理逻辑 - 用了
writeObjectUnshared()—— 它强制每次都写新副本，绕过句柄表，循环引用会变多次独立对象 - 反序列化时类结构变更且 serialVersionUID 不匹配，可能提前失败，根本走不到引用解析阶段
和 JSON 库的根本区别在哪？
像 Jackson、Gson、Fastjson 这类库默认把对象当“树”遍历，没有句柄表概念。遇到循环就无限深入，很快触发 StackOverflowError。它们需要显式开启引用支持（如 Jackson 的 @JsonIdentityInfo 或 Gson 的 GraphAdapterBuilder），而 Java 原生序列化无需任何注解或配置。
什么时候不能依赖这个机制？
虽然机制可靠，但要注意实际限制：
- transient 字段不参与引用跟踪：如果循环路径经过 transient 字段，该链路会被截断，反序列化后这部分为 null
- static 字段不被序列化：循环若依赖 static 引用，原语义无法还原
-
不可序列化资源会中断流程：比如对象内含
Thread、Socket等，直接抛异常，句柄表也救不了
不复杂但容易忽略。
