处理流之六：对象流

ObjectInputStream和OjbectOutputSteam

用于存储和读取基本数据类型数据或对象的处理流。它的强大之处就是可 以把Java中的对象写入到数据源中，也能把对象从数据源中还原回来。

序列化：用ObjectOutputStream类保存基本类型数据或对象的机制

反序列化：用ObjectInputStream类读取基本类型数据或对象的机制

ObjectOutputStream和ObjectInputStream不能序列化static和transient修 饰的成员变量

对象的序列化

对象序列化机制允许把内存中的Java对象转换成平台无关的二进制流，从而允许把这种二进制流持久地保存在磁盘上，或通过网络将这种二进制流传输到另一个网络节点。当其它程序获取了这种二进制流，就可以恢复成原来的Java对象

序列化的好处在于可将任何实现了Serializable接口的对象转化为字节数据， 使其在保存和传输时可被还原

序列化是 RMI（Remote Method Invoke – 远程方法调用）过程的参数和返回值都必须实现的机制，而 RMI 是 JavaEE 的基础。因此序列化机制是 JavaEE 平台的基础

如果需要让某个对象支持序列化机制，则必须让对象所属的类及其属性是可序列化的，为了让某个类是可序列化的，该类必须实现如下两个接口之一Serializable Externalizable。 否则，会抛出NotSerializableException异常

凡是实现Serializable接口的类都有一个表示序列化版本标识符的静态变量：

  • private static final long serialVersionUID;
  • serialVersionUID用来表明类的不同版本间的兼容性。简言之，其目的是以序列化对象 进行版本控制，有关各版本反序列化时是否兼容。
  • 如果类没有显示定义这个静态常量，它的值是Java运行时环境根据类的内部细节自动生成的。若类的实例变量做了修改，serialVersionUID 可能发生变化。故建议， 显式声明。
  • 简单来说，Java的序列化机制是通过在运行时判断类的serialVersionUID来验证版本一致性的。在进行反序列化时，JVM会把传来的字节流中的 serialVersionUID与本地相应实体类的serialVersionUID进行比较，如果相同就认为是一致的，可以进行反序列化，否则就会出现序列化版本不一致的异常。(InvalidCastException)

使用对象流序列化对象

若某个类实现了 Serializable 接口，该类的对象就是可序列化的：

  • 创建一个 ObjectOutputStream

  • 调用 ObjectOutputStream 对象的 writeObject(对象) 方法输出可序列化对象

  • 注意写出一次，操作flush()一次

反序列化

  • 创建一个 ObjectInputStream

  • 调用 readObject() 方法读取流中的对象

强调：如果某个类的属性不是基本数据类型或 String 类型，而是另一个引用类型，那么这个引用类型必须是可序列化的，否则拥有该类型的 Field 的类也不能序列化

基本数据类型和String

序列化

image-20200516175910591

image-20200516175950254

反序列化

image-20200516180326410

image-20200516180356996

对象类型

创建一个Person对象类

image-20200516180658840

序列化

image-20200516180806860

image-20200516180923622

反序列化

image-20200516181221376

image-20200516181236604

serialVersionUID问题

Java的序列化机制是通过在运行时判断类的serialVersionUID来验证版本一致性的。在进行反序列化时，JVM会把传来的字节流中的 serialVersionUID与本地相应实体类的serialVersionUID进行比较，如果相同就认为是一致的，可以进行反序列化，否则就会出现序列化版本不一致的异常。(InvalidCastException)

如果类没有显示定义这个静态常量，它的值是Java运行时环境根据类的内部细节自动生成的

此时我们的Person类是声明了serialVersionUID常量的。我们将Person对象序列化一下

image-20200516181604053

序列化成功

image-20200516181626606

接着我们把Person类中的serialVersionUID常量给注释掉，此时在对其进行序列化反序列化操作时会自动生成一个隐式的serialVersionUID。

image-20200516181840567

在进行一次反序列化操作

image-20200516181916620

出现序列化版本不一致的异常。(InvalidCastException)

image-20200516182037900

将serialVersionUID注释去掉，再次进行反序列化操作。版本号一致，反序列化成功

image-20200516182216858

类对象可序列化的条件

如果某个类的属性不是基本数据类型或 String 类型，而是另一个引用类型，那么这个引用类型必须是可序列化的，否则拥有该类型的 Field 的类也不能序列化

创建一个Habit对象，没有实现Serializable接口。不可序列化

image-20200516182949501

修改Person对象属性

image-20200516183103315

对Person进行序列化操作

image-20200516183215464

报错该类不能序列化。导致Person类也不能序列化

image-20200516183247621

Habit类实现Serializable接口，变成可序列化

image-20200516183503909

再次进行序列化操作

image-20200516183533261

image-20200516183549718

将其反序列化

image-20200516183728674

image-20200516183745648

成功！

Serializable接口的理解

实现了Serializable接口的对象，可将它们转换成一系列字节，并可在以后 完全恢复回原来的样子。这一过程亦可通过网络进行。这意味着序列化机 制能自动补偿操作系统间的差异。换句话说，可以先在Windows机器上创 建一个对象，对其序列化，然后通过网络发给一台Unix机器，然后在那里 准确无误地重新“装配”。不必关心数据在不同机器上如何表示，也不必 关心字节的顺序或者其他任何细节。

由于大部分作为参数的类如String、Integer等都实现了 java.io.Serializable的接口，也可以利用多态的性质，作为参数使接口更 灵活。