java中序列化与反序列化



1 概述

序列化与反序列化

为什么需要序列化与反序列化

几种常见的序列化和反序列化协议

2 序列化实现

Serializable 接口的基本使用

Serializable 接口的特点

3 序列化ID

如何生成这个 serialVersionUID呢？

serialVersionUID 的兼容性问题是什么？

默认的序列化ID

4 Externalizable 接口

5 Java 的序列化步骤与数据结构分析

writeObject 原理分析

readObject 原理分析

---

 Java序列化是指把Java对象转换为字节序列的过程；而Java反序列化是指把字节序列恢复为Java对象的过程。

序列化分为两大部分：序列化和反序列化。序列化是这个过程的第一部分，将数据分解成字节流，以便存储在文件中或在网络上传输。反序列化就是打开字节流并重构对象。对象序列化不仅要将基本数据类型转换成字节表示，有时还要恢复数据。恢复数据要求有恢复数据的对象实例。

 我们知道，当两个进程进行远程通信时，可以相互发送各种类型的数据，包括文本、图片、音频、视频等， 而这些数据都会以二进制序列的形式在网络上传送。那么当两个Java进程进行通信时，能否实现进程间的对象传送呢？答案是可以的。如何做到呢？这就需要Java序列化与反序列化了。换句话说，一方面，发送方需要把这个Java对象转换为字节序列，然后在网络上传送；另一方面，接收方需要从字节序列中恢复出Java对象。

 当我们明晰了为什么需要Java序列化和反序列化后，我们很自然地会想Java序列化的好处。其好处一是实现了数据的持久化，通过序列化可以把数据永久地保存到硬盘上（通常存放在文件里），二是，利用序列化实现远程通信，即在网络上传送对象的字节序列。

① 想把内存中的对象保存到一个文件中或者数据库中时候；
② 想用套接字在网络上传送对象的时候；
③ 想通过RMI传输对象的时候

• XML&SOAP

XML 是一种常用的序列化和反序列化协议，具有跨机器，跨语言等优点，SOAP（Simple Object Access protocol） 是一种被广泛应用的，基于 XML 为序列化和反序列化协议的结构化消息传递协议

• JSON（Javascript Object Notation）
• Protobuf
   
  

 只有实现了Serializable或者Externalizable接口的类的对象才能被序列化为字节序列。（不是则会抛出异常） 

Serializable 接口

是 Java 提供的序列化接口，它是一个空接口

Serializable 用来标识当前类可以被 ObjectOutputStream 序列化，以及被 ObjectInputStream 反序列化。

通过 ObjectOutputStream 将需要序列化数据写入到流中，因为 Java IO 是一种装饰者模式，因此可以通过 ObjectOutStream 包装 FileOutStream 将数据写入到文件中或者包装 ByteArrayOutStream 将数据写入到内存中。同理，可以通过 ObjectInputStream 将数据从磁盘 FileInputStream 或者内存 ByteArrayInputStream 读取出来然后转化为指定的对象即可。

1. 序列化类的属性没有实现 Serializable 那么在序列化就会报错

具体可以跟进 ObjectOutputStream#writeObject() 源码查看具体原因：

2. 在反序列化过程中，它的父类如果没有实现序列化接口，那么将需要提供无参构造函数来重新创建对象。

Animal 是父类，它没有实现 Serilizable 接口

BlackCat 是 Animal 的子类

SuperMain 测试类

输出结果

对上面的2个操作文件流的类的简单说明

ObjectOutputStream代表对象输出流：

它的writeObject(Object obj)方法可对参数指定的obj对象进行序列化，把得到的字节序列写到一个目标输出流中。

ObjectInputStream代表对象输入流：

4. 静态成员变量是不能被序列化

序列化是针对对象属性的，而静态成员变量是属于类的。

从这两个方法的名字就可以看出分别是序列化写入数据和反序列化读取数据用的，那么这两个方法是在哪里使用呢？其实在序列化和反序列化过程中会通过调用的，具体下面会分析这个过程哦。

现在来看看这个 transient 应用:

测试

测试输出结果

6.Serializable 在序列化和反序列化过程中大量使用了反射，因此其过程会产生的大量的内存碎片

serialVersionUID与兼容性问题

可以看到，我们在进行序列化时，加了一个serialVersionUID字段，这便是序列化ID

这个序列化ID起着关键的作用，它决定着是否能够成功反序列化！java的序列化机制是通过判断运行时类的serialVersionUID来验证版本一致性的，在进行反序列化时，JVM会把传进来的字节流中的serialVersionUID与本地实体类中的serialVersionUID进行比较，如果相同则认为是一致的，便可以进行反序列化，否则就会报序列化版本不一致的异常。

即序列化ID是为了保证成功进行反序列化

1. 使用 AS plugin 插件就可以生成
2. 在JDK中，可以利用 JDK 的 bin 目录下的 serialver 工具产生这个serialVersionUID，对于 Student.class，执行命令：serialver com.example.seriable.Student

使用 AS plugin 的方式应该底层也是使用到这个 JDK 工具去生成的 SerialVersionUID 值，测试结果来看这两个生成的值是一样的。

具体的兼容性问题如下：

关于这个异常，它是属于兼容问题异常，是发生在反序列化阶段，检测到 serialVersionUID 不一致导致的。具体的分析如下：

serialVersionUID 发生改变有三种情况：

1. 手动去修改导致当前的 serialVersionUID 与序列化前的不一样。
2. 我们根本就没有手动去写这个 serialVersionUID 常量，那么 JVM 内部会根据类结构去计算得到这个 serialVersionUID 值，在类结构发生改变时(属性增加，删除或者类型修改了)这种也是会导致 serialVersionUID 发生变化。
3. 假如类结构没有发生改变，并且没有定义 serialVersionUID ，但是反序列和序列化操作的虚拟机不一样也可能导致计算出来的 serialVersionUID 不一样。

JVM 规范强烈建议我们手动声明一个版本号，这个数字可以是随机的，只要固定不变就可以。同时最好是 private 和 final 的，尽量保证不变。

当我们一个实体类中没有显式的定义一个名为“serialVersionUID”、类型为long的变量时，Java序列化机制会根据编译时的class自动生成一个serialVersionUID作为序列化版本比较，这种情况下，只有同一次编译生成的class才会生成相同的serialVersionUID。譬如，当我们编写一个类时，随着时间的推移，我们因为需求改动，需要在本地类中添加其他的字段，这个时候再反序列化时便会出现serialVersionUID不一致，导致反序列化失败。那么如何解决呢？便是在本地类中添加一个“serialVersionUID”变量，值保持不变，便可以进行序列化和反序列化。

Serializable 接口内部序列化是 JVM 自动实现的，如果我们想自定义序列化过程，就可以使用以上这个接口来实现，它内部提供两个接口方法：

Externalizable 的使用

测试 Person 对象的序列化和反序列化

测试输出结果：

序列化算法一般会按步骤做如下事情：

将对象实例相关的类元数据输出。
递归地输出类的超类描述直到不再有超类。
类元数据完了以后，开始从最顶层的超类开始输出对象实例的实际数据值。
从上至下递归输出实例的数据
也许你看上面这几个步骤会有点懵逼，不过实际的序列化过程就是按照上面的步骤进行的，看完这个就开始 writeObject 和 readObject 源码解读，而 writeObejct 的过程就是上面的4个步骤。

• readObject/writeObject原理分析

ObjectOutputStream 构造函数

①bout：用于写入一些类元数据还有对象中基本数据类型的值，在下面会分析。

②enableOverride ：false 表示不支持重写序列化过程，如果为 true ，那么需要重写 writeObjectOverride 方法。这个一般不用管它。

③writeStreamHeader() 写入头信息，具体看下面分析。

ObjectOutputStream#writeStreamHeader()

①STREAM_MAGIC 声明使用了序列化协议，bout 就是一个流，将对应的头数据写入该流中

②STREAM_VERSION 指定序列化协议版本

ObjectOUtStream#writeObject(obj);
上面是 ObjectOutStream 构造中做的事，下面来看看具体 writeObject 方法内部做了什么事？
 

ObjectOutStream#writeObject0()

② 根据 obj 的类型去执行序列化操作，如果不符合序列化要求，那么会③位置抛出  异常。

在上面描述过，如果一个需要序列化的对象的某个属性没有实现序列化接口，那么就会此处抛出异常。读者可以自行验证。

ObjectOutputStream#writeOrdinaryObject

①写入类的元数据，TC_OBJECT. 声明这是一个新的对象，如果写入的是一个 String 类型的数据，那么就需要 TC_STRING 这个标识。

②writeClassDesc 方法主要作用就是自上而下(从父类写到子类，注意只会遍历那些实现了序列化接口的类)写入描述信息。该方法内部会不断的递归调用，我们只需要关系这个方法是写入描述信息就好了，读者可以查阅一下源码。

从这里可以知道，序列化过程需要额外的写入很多数据，例如描述信息，类数据等，因此序列化后占用的空间肯定会更大。

③ desc.isExternalizable() 判断需要序列化的对象是否实现了 Externalizable 接口，这个在上面已经演示过怎么使用的，在序列化过程就是在这个地方进行判断的。如果有，那么序列化的过程就会由程序员自己控制了哦，writeExternalData 方法会回调，在这里就可以愉快地编写需要序列化的数据拉。

④ writeSerialData 在没有实现 Externalizable 接口时，就执行这个方法

ObjectOutputstream#writeSerialData

 

③ defaultWriteFields 这个方法就是 JVM 自动帮我们序列化了，

这个方法主要分为以下两步

• ① 写入基本数据类型的数据
• ②写入引用数据类型的数据，这里最终又调用到了 writeObject0() 方法，读者可以返回到上面去看看具体的实现。

好了，Serialzable 序列化的源码分析就完成了。

从流中读取类的描述信息 ObjectStreamClass 实例，通过这个对象就可以创建出序列化的对象。

读取该对象及其对象的父类的 ObjectStreamClass信息

然后遍历得到每一个 ObjectStreamClass 对象，将对应的属性值赋值给需要反序列化的对象。

好了，以上就是基本的反序列化 readObject 的过程，这个过程基本是跟 writeObject 差不多，因此简单的列举了关键步骤而已

 

 

 

版权声明：

本文来源网络，所有图片文章版权属于原作者，如有侵权，联系删除。

本文网址：https://www.mushiming.com/mjsbk/10954.html