在完全可序列化的层次结构中序列化一个类，与不可序列化祖先的可序列化子类相比，有什么好处/缺点？答案

【问题标题】：What are the benefits/drawbacks to serializing a class in a fully serializable hierarchy, vs. Serializable child of non-serializable ancestry?在完全可序列化的层次结构中序列化一个类，与不可序列化祖先的可序列化子类相比，有什么好处/缺点？
【发布时间】：2015-05-13 15:14:12
【问题描述】：

那是

(1)

A级 B 扩展 A C 扩展 B D 扩展 C E 扩展 D 实现 Serializable

对比

(2)

A 实现可序列化 B 扩展 A C 扩展 B D 扩展 C E 扩展 D

(1)在第一种情况下，序列化 E 将导致 E 的状态被保存，并且通过调用 D 的默认构造函数在反序列化时重构 A 到 D。

(2)在第二种情况下，序列化 E 将导致 A 到 E 的状态都被保存，并且在反序列化时不需要重建（因为由于继承自可序列化的基类，所有东西都将是可序列化的。）

第一种方法有什么危险吗？在某些情况下，通过第一种方式在序列化/反序列化期间传输的数据节省足以使其成为首选方法，还是最好完全序列化类层次结构？

提前致谢。

【问题讨论】：

这里的“重构”是什么意思？您是说 E 中有代码可以明确记住所需的 A-D 状态片段吗？
鉴于 A
所以“第一种方法有什么危险吗”很明显“你正在丢失大量信息”——如果你只调用无参数的构造函数，那么任何信息都只能在超类丢失了，这让我怀疑在大多数情况下，继承层次结构设计不当。哎呀，据我所知，这种方法甚至只有在一直存在无参数构造函数的情况下才有效。（老实说，无论如何我都会避免使用 Java 的二进制序列化方案，但那是另一回事。）
根据所使用的框架，可能无法避免 Serializable。例如，在 Java EE 5+ 中，任何时候对会话 bean 执行方法调用并且该调用可能是远程的，则需要 Serializable。 Serializable 也被编入 JavaBeans 的契约中。了解（并尊重）Serializable 的优点和限制比建议完全避免它更好。

标签： java serialization

【解决方案1】：

在超类中实现Serializable 通常不被认为是最佳实践，特别是如果它打算作为导出 API 层次结构中的基类（但是，您的基类应该旨在预期实现 Serializable 的子类；见下文）。原因是它会强制 API 的客户端使他们的子类可序列化，无论这样做是否有用（Essential Java，第 2 版）。

此规则的例外情况是当基类本身参与需要Serializable 的框架时。

无论如何，如果子类可序列化而其父类不可序列化，则可能会出现问题。在这种情况下，子类负责序列化和反序列化其父类的状态。缺点是：

父字段不能是final
如果子类无法访问父字段，则可能无法正确序列化表示
本身不实现Serializable 的父类需要无参数构造函数

在 Essential Java，第 2 版中对序列化 Java 实例的陷阱和推荐做法进行了精彩的讨论。

【讨论】：