我们应该在什么时候实现Serializable接口？
public class Contact implements Serializable {
private String name;
private String email;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getEmail() {
return email;
}
public void setEmail(String email) {
this.email = email;
}
}- 我应该在什么时候实现
Serializable接口？ - 我们为什么要这样做？
- 是否提供了任何优势或安全性？
回答 3
Stack Overflow用户
发布于 2010-12-29 03:33:06
来自What's this "serialization" thing all about?的
- ：
它允许您获取一个或一组对象，将它们放在磁盘上或通过有线或无线传输机制发送它们，然后稍后，可能在另一台计算机上，逆转这一过程:复活原始对象。基本机制是将对象展平为一维比特流，并将该比特流转换回原始对象。
就像“星际迷航”中的传送器一样，这一切都是关于把一些复杂的东西变成一个由1和0组成的扁平序列，然后把这个由1和0组成的序列(可能是在另一个地方，也可能是在另一个时间)，然后重建原来复杂的“东西”。
因此，当您需要存储对象的副本时，实现Serializable接口，将它们发送到运行在同一系统或网络上的另一个进程。
- ，因为您想要存储或发送对象。
- 它使存储和发送对象变得容易。这与安全无关。
Stack Overflow用户
发布于 2018-12-22 03:10:05
这个问题的答案是，也许令人惊讶的是，从不，或者更现实地说，只有为了与遗留代码的互操作性而被迫使用。这是Joshua Bloch在上的推荐：
在您编写的任何新系统中，都没有理由使用
序列化
Oracle's chief architect, Mark Reinhold, is on record 说，消除当前的Java序列化机制是一个长期目标。
为什么Java序列化有缺陷
作为语言的一部分，Java提供了一种序列化方案，您可以选择使用Serializable接口。但是，该方案有几个难以处理的缺陷，Java语言设计人员应该将其视为一次失败的实验。
，
- ，它从根本上假装可以谈论对象的序列化形式。但是有无限多的序列化方案，导致产生无限多的序列化形式。通过强加一种方案而不改变方案，应用程序不能使用最适合它们的方案。
- 它被实现为构造对象的另一种方法，它绕过了构造函数或工厂方法执行的任何前提条件检查。除非编写了棘手的、容易出错的和难以测试的额外的反序列化代码，否则您的代码可能有一个很大的安全漏洞，因为不同版本的序列化形式的互操作性是非常麻烦的，difficult.
- Handling的不可变对象是非常麻烦的。
该怎么做？
相反，应使用可以显式控制的序列化方案。例如Protocol Buffers、JSON、XML或您自己的自定义方案。
Stack Overflow用户
发布于 2010-12-29 03:38:30
当您希望能够将类的实例转换为一系列字节时，或者当您认为对象可能引用class.
Serializable类的实例时，当您希望持久化它们的实例或通过类的wire.- Instances发送它们时，
SerializableSerializable实现Serializable接口很有用。然而，序列化确实有一些安全后果。阅读Joshua Bloch的Effective Java.
https://stackoverflow.com/questions/4548816
复制相似问题