DEV Community
·
第86条：实现Serializable时需谨慎
内容提要
序列化实现简单但后果复杂。添加Serializable后，类的序列化形式成为公共API，可能导致兼容性问题。每个序列化类有唯一标识符，变更可能引发InvalidClassException。序列化存在安全风险，可能创建无效对象，且测试复杂性增加。适用于特定框架和类，但继承设计的类通常不应序列化，内部类和静态成员类的序列化需谨慎。可考虑使用JSON或XML替代。
关键要点
-
序列化实现简单，但后果复杂。
-
一旦类被标记为可序列化，其序列化形式成为公共API，可能导致兼容性问题。
-
每个序列化类都有唯一标识符，变更可能导致InvalidClassException。
-
序列化存在安全风险，可能创建无效对象或导致未授权访问。
-
可序列化类的测试复杂性增加，需在不同版本间进行测试。
-
序列化在特定框架和类中是必要的，但不适用于所有类。
-
设计用于继承的类通常不应被序列化，接口也不应扩展Serializable。
-
内部类不应序列化，静态成员类可以实现Serializable。
-
可以考虑使用JSON或XML作为序列化的替代方案。
延伸解读
序列化的兼容性风险
一旦类实现了Serializable接口，其序列化形式就成为公共API，任何内部结构的变化都可能导致兼容性问题。开发者需要谨慎管理类的版本，确保在修改时不会破坏已有的序列化数据，这可能需要手动维护兼容性，增加了开发和维护的复杂性。
安全隐患与测试复杂性
序列化过程可能忽略构造函数，导致创建无效对象或引发安全漏洞。此外，序列化类的测试复杂性显著增加，开发者需要在不同版本间进行充分测试，以确保序列化和反序列化过程的安全性和有效性。
何时选择序列化
序列化在某些框架和特定类中是必要的，例如用于存储和传输数据的类。然而，对于设计用于继承的类或表示活动进程的类，通常不应实现Serializable。开发者应根据具体需求谨慎选择是否使用序列化。
序列化的替代方案
考虑使用JSON或XML等格式作为序列化的替代方案，这些格式在数据传输和持久化方面提供了更大的灵活性和控制力。使用这些替代方案可以减少序列化带来的兼容性和安全风险。
延伸问答
为什么实现Serializable会导致兼容性问题？
一旦类被标记为可序列化，其序列化形式成为公共API，内部的变更可能会破坏与旧版本的兼容性。
序列化的安全风险有哪些？
序列化可能创建无效对象，忽略构造函数，导致未授权访问，增加安全漏洞的风险。
如何避免InvalidClassException？
确保每个序列化类都有手动指定的serialVersionUID，避免因类的变更而导致的兼容性问题。
哪些类不应该实现Serializable？
设计用于继承的类和内部类通常不应实现Serializable，接口也不应扩展Serializable。
序列化的测试复杂性如何增加？
可序列化类需要在不同版本间进行测试，随着可序列化类数量的增加，测试矩阵也会变得更加复杂。
有哪些替代序列化的方法？
可以考虑使用JSON或XML作为序列化的替代方案，或使用代理模式以获得更好的控制。
