
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 等格式进行持久化和数据传输。
以上就是实施序列化时要小心的详细内容,更多请关注php中文网其它相关文章!