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 等格式进行持久化和数据传输。
以上就是实施序列化时要小心的详细内容，更多请关注【创想鸟】其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至253000106@qq.com举报，一经查实，本站将立刻删除。
发布者：PHP中文网，转转请注明出处：https://www.chuangxiangniao.com/p/3038347.html
