讨论了为什么Optional不可序列化以及如何处理（即将推出）之后，让我们仔细看看序列化。

总览

这篇文章介绍了序列化的一些关键概念。 它尝试精简地执行此操作，而不会涉及太多细节，包括将建议降至最低。 它没有叙述，更类似于Wiki文章。 主要信息来源是约书亚·布洛赫（Joshua Bloch）的优秀著作《 有效的Java》 ，其中涉及覆盖序列化的多个项目（第一版：54-57；第二版： 74-78 ）。 在官方序列化规范中可以找到更多信息的方式

定义

通过序列化，实例可以被编码为字节流（称为序列化 ），并且这样的字节流可以被转换回实例（称为反序列化 ）。

关键功能是两个进程不必由同一JVM执行。 这使得序列化成为一种在系统运行之间将对象存储在磁盘上或在不同系统之间传输它们以进行远程通信的机制。

语言外特征

序列化是一种有点奇怪的机制。 它将实例转换为字节流，反之亦然，与类的交互很少。 它既不调用访问器来获取值，也不使用构造函数创建实例。 为此，该类的所有开发人员所要做的就是实现一个没有方法的接口。

Bloch将其描述为一种语言学特征 ，它是序列化中许多问题的根源。

方法

可以通过实现以下某些方法来自定义序列化过程。 它们可以是私有的，JVM将根据其签名找到它们。 这些描述摘自Serializable的类注释 。

• private void writeObject(java.io.ObjectOutputStream out) throws IOException
  负责为其特定类编写对象的状态，以便相应的readObject方法可以还原它。
• private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException
  负责从流中读取并还原类字段。
• private void readObjectNoData() throws ObjectStreamException
  在序列化流未将给定类列出为要反序列化的对象的超类的情况下，负责为其特定类初始化对象的状态。
• ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException
  指定将此类的对象写入流时要使用的替代对象。
• ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException;
  从流中读取此类的实例时，指定一个替换对象。

处理反序列化的语言外特性的一个好方法是将所有涉及的方法视为该类的附加构造函数。

（反）序列化涉及的对象流提供了以下有用的默认（反）序列化方法：

• java.io.ObjectOutputStream.defaultWriteObject() throws IOException
  将当前类的非静态和非瞬态字段写入此流。
• java.io.ObjectInputStream.defaultReadObject() throws IOException, ClassNotFoundException
  从此流中读取当前类的非静态和非瞬态字段。

不变量

不使用构造函数创建实例的一种效果是，在反序列化时不会自动建立类的不变式。 因此，尽管类通常会检查所有构造函数参数的有效性，但该机制不会自动应用于字段的反序列化值。

进行反序列化检查是一项额外的工作，很容易导致代码重复及其通常会引起的所有问题。 如果忘记或粗心地做，该类将打开漏洞或安全漏洞。

序列化表格

可序列化类的字节流编码的结构称为其序列化形式 。 它主要由类字段的名称和类型定义。

序列化的表单具有一些不立即可见的属性。 尽管可以通过仔细定义表格来缓解某些问题，但它们通常仍然是班级未来发展的负担。

公开API

序列化表格的最重要属性是：

它是该类的公共API的一部分！

从部署可序列化类的那一刻起，必须假定已存在序列化实例。 通常期望系统支持使用同一系统的较旧版本创建的实例的反序列化。 类的用户不仅依赖于其序列化形式，还依赖于其记录的行为。

减少信息隐藏

信息隐藏的概念允许类在更改其实现方式的同时保留其记录的行为。 该表述包括其状态的表示形式，通常是隐藏的，可以根据需要进行调整。 由于捕获状态表示形式的序列化形式成为公共API的一部分，因此表示形式本身也是如此。

Serializable类只有有效地隐藏其行为的实施，同时暴露出该行为的界定和国家使用它来实现它。

灵活性降低

因此，就像更改类的API（例如，通过更改或删除方法或更改其记录的行为）一样，使用它可能会破坏代码，更改序列化形式也是如此。 不难发现，如果固定领域，提高班级就变得更加困难。 如果需要，这大大降低了更改此类的灵活性。

在JDK可序列化中进行处理会使我们的维护成本急剧增加，因为这意味着该表示将一直冻结。 这限制了我们将来开发实现的能力，而我们无法轻松修复错误或提供增强功能的情况数量非常之多，而这种情况本来就很简单。 因此，尽管对您来说，这看起来像是一个“可序列化的实现”的简单问题，但不仅限于此。 解决早期的选择以使某些东西可序列化所消耗的工作量是惊人的。 布莱恩·格茨

增加测试工作量

如果更改了可序列化的类，则必须测试序列化和反序列化是否可以在系统的不同版本中工作。 这不是一件容易的事，并且会产生可衡量的成本。

类表示

from的序列化表示一个类，但并非所有表示都相等。

物理

如果一个类使用引用类型（即非基本类型）定义字段，则其实例包含指向这些类型的实例的指针。 这些实例又可以指向其他实例，依此类推。 这定义了互连实例的有向图。 实例的物理表示形式是从该实例可到达的所有实例的图形。

例如，考虑一个双向链表。 列表中的每个元素都包含在一个节点中，并且每个节点都知道上一个和下一个。 这基本上已经是列表的物理表示形式。 包含一打元素的列表将是13个节点的图形。 列表实例指向第一个和最后一个列表节点，从那里开始，可以在两个方向之间遍历这两个节点之间的十个节点。

序列化类实例的一种方法是简单地遍历图并序列化每个实例。 这有效地将物理表示形式写入字节流，这是默认的序列化机制。

虽然类的物理表示形式通常是一个实现细节，但是这种序列化它的方法会暴露此隐藏的信息。 序列化物理表示有效地将类绑定到该类，这使得将来很难更改它。 还有其他缺点，在有效Java （第2版的第297页）中进行了介绍。

逻辑上

类状态的逻辑表示通常更抽象。 通常从实施细节中将其删除，并且包含的​​信息较少。 在尝试表达此表示形式时，建议将两个方面都推到最大。 它应该尽可能地独立于实现，并且从某种意义上讲应该是最小的，因为遗漏任何信息都使得无法从中重新创建实例。

要继续链接列表的示例，请考虑链接列表的实际含义：仅按特定顺序排列一些元素。 这些是否包含在节点中以及这些假想的节点如何链接都无关紧要。 因此，最小的逻辑表示将仅由那些元素组成。 （为了从流中正确地重新创建实例，有必要添加元素的数量。虽然这是多余的信息，但似乎并没有太大的伤害。）

因此，良好的逻辑表示形式只能捕获状态的抽象结构，而不能捕获表示状态的具体字段。 这意味着尽管改变前者仍然存在问题，但后者可以自由发展。 与序列化物理表示相比，这为类的进一步开发恢复了很大一部分灵活性。

序列化模式

至少有三种方法可以序列化一个类。 调用所有这些模式都有些过分，因此该术语使用得比较宽松。

默认序列化表格

这就像在声明中添加implements Serializable一样简单。 然后，序列化机制会将所有非临时字段写入流中，并在反序列化时将流中存在的所有值分配给它们的匹配字段。

这是序列化类的最直接的方法。 这也是序列化的所有尖锐边缘都变得平淡无奇，等待轮到真正伤害您的地方。 序列化形式捕获物理表示，并且绝对不检查不变量。

自定义序列化表格

通过实现writeObject一个类可以定义将哪些内容写入字节流。 匹配的readObject必须读取相应的流，并使用该信息将值分配给字段。

这种方法比默认形式具有更大的灵活性，可用于序列化类的逻辑表示。 有一些细节需要考虑，我只能建议阅读Effective Java中的相应项目（第1版中的项目55；第2版中的项目75）。

序列化代理模式

在这种情况下，要序列化的实例将替换为代理。 该代理是从字节流而不是原始实例写入和读取的。 这可以通过实现方法writeReplace和readResolve来实现。

在大多数情况下，这是迄今为止最好的序列化方法。 它值得自己的职位 ，它会很快得到它（ 住宿 调整 ）。

杂项

有关序列化的其他一些细节。

人工字节流

反序列化的快乐路径假定一个字节流是通过序列化同一类的实例而创建的。 尽管在大多数情况下这样做是可以的，但是在安全关键代码中必须避免这样做。 这包括任何使用序列化进行远程通信的公共可访问服务。

取而代之的是，必须假设攻击者精心制作了流，以违反类的不变式。 如果不解决此问题，则可能导致系统不稳定，从而可能崩溃，破坏数据或受到攻击。

文献资料

Javadoc具有特殊的注释，用于记录类的序列化形式。 为此，它在文档中创建了一个特殊页面，其中列出了以下信息：

• 标记@serialData可以注释方法，下面的注释应该用来记录字节流中写入的数据。 方法签名和注释显示在“ 序列化方法”下 。
• 标记@serial可以注释字段，下面的注释应该描述该字段。 然后，该字段的类型和名称以及注释会在“ 序列化字段”下列出 。

一个很好的例子是LinkedList的文档 。

翻译自: https://www.javacodegeeks.com/2015/01/concepts-of-serialization.html