DEV Community
·
第86条：实现Serializable时需谨慎
💡
原文约300字/词，阅读约需1分钟。
📝
内容提要
序列化实现简单但后果复杂。添加Serializable后，类的序列化形式成为公共API，可能导致兼容性问题。每个序列化类有唯一标识符，变更可能引发InvalidClassException。序列化存在安全风险，可能创建无效对象，且测试复杂性增加。适用于特定框架和类，但继承设计的类通常不应序列化，内部类和静态成员类的序列化需谨慎。可考虑使用JSON或XML替代。
🎯
关键要点
-
序列化实现简单，但后果复杂。
-
一旦类被标记为可序列化，其序列化形式成为公共API，可能导致兼容性问题。
-
每个序列化类都有唯一标识符，变更可能导致InvalidClassException。
-
序列化存在安全风险，可能创建无效对象或导致未授权访问。
-
可序列化类的测试复杂性增加，需在不同版本间进行测试。
-
序列化在特定框架和类中是必要的，但不适用于所有类。
-
设计用于继承的类通常不应被序列化，接口也不应扩展Serializable。
-
内部类不应序列化，静态成员类可以实现Serializable。
-
可以考虑使用JSON或XML作为序列化的替代方案。
❓
延伸问答
为什么实现Serializable会导致兼容性问题？
一旦类被标记为可序列化，其序列化形式成为公共API，内部的变更可能会破坏与旧版本的兼容性。
序列化的安全风险有哪些？
序列化可能创建无效对象，忽略构造函数，导致未授权访问，增加安全漏洞的风险。
如何避免InvalidClassException？
确保每个序列化类都有手动指定的serialVersionUID，避免因类的变更而导致的兼容性问题。
哪些类不应该实现Serializable？
设计用于继承的类和内部类通常不应实现Serializable，接口也不应扩展Serializable。
序列化的测试复杂性如何增加？
可序列化类需要在不同版本间进行测试，随着可序列化类数量的增加，测试矩阵也会变得更加复杂。
有哪些替代序列化的方法？
可以考虑使用JSON或XML作为序列化的替代方案，或使用代理模式以获得更好的控制。
➡️
