实施序列化时要小心

1. 实现简单，潜在风险巨大

• 可序列化类只需添加序列化功能即可轻松实现。
• 然而，序列化可能会带来巨大的长期维护成本。

2. 类进化与兼容性

• 序列化格式一旦序列化，就成为公共API的一部分。
• 内部修改可能会破坏与旧版本的兼容性。
• 虽然兼容性可以手动维护，但兼容性可以手动维护（ObjectOutputStream.putFields 和 ObjectInputStream.readFields），但过程复杂，容易出错。

3. SerialVersionUID 的重要性

• 每个可序列化类都需要一个唯一的标志符 (SerialVersionUID)。
• 编译器将在没有手动指定的情况下自动生成。
• 任何类别的变化都可能改变这一点 ID，导致兼容性问题和抛出问题 InvalidClassException 异常。

4. 安全隐患

• 序列化绕过了构造函数，可以避免语言限制。
• 有可能创建无效的对象，或允许未经授权的访问。
• 依赖未经验证的序列化数据可能会导致安全漏洞(见项目88)。

5. 试验的复杂性增加了

• 可序列化类需要在不同版本之间进行测试。
• 可序列化的类别越多，所需的测试矩阵就越大。
• 预期的序列化结构难以演变。

6. 序列化的必要性

• 对于需要持久数据的框架，序列化是必要的。
• 在值类(例如 BigInteger，Instant）和集合非常有用。
• 表示活动过程的类别(如 ThreadPool）一般不应序列化。

7. 序列化和继承

• 为继承而设计的类别通常不应序列化。
• 界面应尽量避免扩展序列化，因为它将对未来的实现施加额外的限制。
• 值得注意的例外：可以抛出异常(用于) RMI 用于异常传播)和组件(用于异常传播) Swing/AWT）。

8. 内部类问题

• 内部类不应该序列化，因为没有指定的合成字段。
• 静态成员类可以实现序列化。

9. 序列化替代方案

• 利用自定义序列化机制(见项目90)获得更好的控制。
• 使用 JSON 或 XML 等格式进行持久化和数据传输。

以上是实施序列化时要注意的详细内容。请多关注图灵教育的其他相关文章！