分布式系统的基石序列化与反序列化

序列化的意义

Java 平台允许我们在内存中创建可复用的Java对象，但一般情况下， 只有当 JVM 处于运行时，这些对象才可能存在，即，这些对象的生命周 期不会比 JVM 的生命周期更长。但在现实应用中，就可能要求在 JVM 停止运行之后能够保存(持久化)指定的对象，并在将来重新读取被保存 的对象。Java 对象序列化就能够帮助我们实现该功能
简单来说
序列化是把对象的状态信息转化为可存储或传输的形式过程，也就是把对象转化为字节序列的过程称为对象的序列化
反序列化是序列化的逆向过程，把字节数组反序列化为对象，把字节序列恢复为对象的过程成为对象的反序列化

如何实现一个序列化操作

JDK提供了Java对象的序列化方式 ，主要通过输出流 java.io.ObjectOutputStream 和对象输入流 java.io.ObjectInputStream 来实现。其中，被序列化的对象需要实现 java.io.Serializable 接口,所以在 Java 中，只要一个类实现了java.io.Serializable 接口，那么它就可以被序列化.

serialVersionUID 的作用

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

如果没有为指定的 class 配置 serialVersionUID，那么 java 编译器会自动给这个 class 进行一个摘要算法，类似于指纹算法，只要这个文件有任何改动，得到的UUID就会截然不同的,可以保证在这么多类中，这个编号是唯一的.
serialVersionUID 有两种显示的生成方式：
一是默认的 1L，比如：private static final long serialVersionUID = 1L;
二是根据类名、接口名、成员方法及属性等来生成一个 64 位的哈希字段当实现java.io.Serializable 接 口的类没有显式地定义一 个 serialVersionUID 变量时候，Java 序列化机制会根据编译的 Class 自动 生成一个 serialVersionUID 作序列化版本比较用，这种情况下，如果 Class 文件(类名，方法名等)没有发生变化(增加空格，换行，增加注释等 等)，就算再编译多次，serialVersionUID 也不会变化的。

静态变量序列化

如下图,在User中添加一个全局的静态变量 num ，在执行序列化以后修改num的值为 10， 然后通过反序列化以后得到的对象去输出 num 的值

最后的输出是10，理论上打印的 num 是从读取的对象里获得的，应该是保存时的状态才对。之所以打印10的原因在于序列化时，并不保存 静态变量，这其实比较容易理解，序列化保存的是对象的状态，静态变量属于类的状态，因此序列化并不保存静态变量。

父类的序列化

一个子类实现了 Serializable 接口，它的父类都没有实现 Serializable接口，在子类中设置父类的成员变量的值，接着序列化该子类对象,再反序列化出来以后输出父类属性的值。父类属性的值为 null。也就是父类没有实现序列化

可以得出以下结论：

1. 当一个父类没有实现序列化时，子类继承该父类并且实现了序列化。 在反序列化该子类后，是没办法获取到父类的属性值的
2. 当一个父类实现序列化，子类自动实现序列化，不需要再显示实现 Serializable 接口
3. 当一个对象的实例变量引用了其他对象，序列化该对象时也会把引用对象进行序列化，但是前提是该引用对象必须实现序列化接口

Transient 关键字

Transient关键字的作用是控制变量的序列化，在申明变量的时，变量前加上Transient关键字，对象序列化之后可以阻止反序列化之后变量值的显示，该变量会以默认值进行显示，如int是0，string是null。

比如在新建User对象的时候给hobby赋了值“看书”，那么User序列化之后，反序列化的时候hobby变量的值显示为null。
绕开 transient 机制的办法
值得注意的是，writeObject和readObject这两个私有的方法，既不属于 Object、也不是Serializable， 为什么能够在序列化的时候被调用呢？
原因是，ObjectOutputStream 使用了反射来寻找是否声明了这两个方法。因为 ObjectOutputStream 使用 getPrivateMethod，所以这些方法必须声明为 priate 以至于供 ObjectOutputStream 来使用

序列化实现深克隆

在Java中存在一个Cloneable接口，通过实现这个接口的类都会有clone的能力，clone在内存中进行，在性能方面比直接new对象要高一些，特别是一些大的对象的生成性能提升相对比较明显一些。在Java领域中克隆分为浅克隆和深克隆
浅克隆
被复制的对象所有变量都含有与原来对象变量相同的值，而所有其他对象的引用任然指向原来的对象。
实现一个邮件通知功能告诉每个人今天晚上的上课时间，通过浅克隆，实现如下



当我们只希望修改黑白的上课时间调整为20：30.通过程序运行的结果我们发现mic的上课时间也被修改为了20：30，及所有人的邮件通知内容都发生了改变。这是因为p2克隆的这个对象的Email指向的是同一个引用，当p2改变了Email的内容后其他所有的对象都指向这个修改后的引用，所以所有对象的Email的内容都发生了改变。这就是浅克隆。
深克隆
被复制对象的所有变量都含有与原来的对象相同的值，除去那些引其他对象的变量。那些引用其他对象的变量将指向被复制过的新对象，而不再是原有的那些被引用的对象。换言之，深拷贝把要复制的对象所引用的对象都复制了一遍



这样就能实现深克隆效果，原理是把对象序列化输出到一个流中，然后在把对象从序列化流中读取出来，这个对象就不是原来的对象了

常见的序列化技术

Java本身自带序列化

使用 JAVA 进行序列化有他的优点，也有他的缺点
优点：JAVA 语言本身提供，使用比较方便和简单
缺点：不支持跨语言处理、 性能相对不是很好，序列化以后产生的数据相对较大

XML 序列化框架

XML 序列化的好处在于可读性好，方便阅读和调试。但是序列化以后的 字节码文件比较大，而且效率不高，适用于对性能不高，而且 QPS 较 低的企业级内部系统之间的数据交换的场景，同时 XML 又具有语言无关性，所以还可以用于异构系统之间的数据交换和协议。比如我们熟知 的 Webservice，就是采用 XML 格式对数据进行序列化的

JSON 序列化框架

JSON（JavaScript Object Notation）是一种轻量级的数据交换格式，相 对于 XML 来说，JSON 的字节流更小，而且可读性也非常好。现在 JSON 数据格式在企业运用是最普遍的，JSON 序列化常用的开源工具有很多

1. Jackson （https://github.com/FasterXML/jackson）
2. 阿里开源的 FastJson （https://github.com/alibaba/fastjon）
3. Google 的 GSON (https://github.com/google/gson)
   这几种 json 序列化工具中，Jackson 与 fastjson 要比 GSON 的性能好，但是 Jackson、GSON 的稳定性要比 Fastjson 好。而 fastjson 的优势在于提供的 api 非常容易使用

Hessian 序列化框架

Hessian 是一个支持跨语言传输的二进制序列化协议，相对于 Java 默认 的序列化机制来说，Hessian 具有更好的性能和易用性，而且支持多种 不同的语言。Dubbo 采用的就是 Hessian 序列化来实现，只不过 Dubbo 对 Hessian 进行了重构，性能更高

Protobuf 序列化框架

Google 提供了多种语言来实现，比如 Java、C、Go、Python，每一种实现都包含了相应语言的编译器和库文件。Protobuf 使用比较广泛，主要是空间开销小和性能比较好，非常适合用于公司内部对性能要求高的 RPC 调用。 另外由于解析性能比较高，序 列化以后数据量相对较少，所以也可以应用在对象的持久化场景中 ，但是要使用 Protobuf 会相对来说麻烦些，因为他有自己的语法， 有自己的编译器
序列化工具Protobuf在Idea中的配置和在java中的使用实例

序列化技术的选型

技术层面

1. 序列化空间开销，也就是序列化产生的结果大小，这个影响到传输的性能
2. 序列化过程中消耗的时长，序列化消耗时间过长影响到业务的响应时间
3. 序列化协议是否支持跨平台，跨语言。因为现在的架构更加灵活，如果存在异构系统通信需求，那么这个是必须要考虑的
4. 可扩展性/兼容性，在实际业务开发中，系统往往需要随着需求的快速迭代来实现快速更新，这就要求我们采用的序列化协议基于良好的可扩展性/兼容性，比如在现有的序列化数据结构中新增一个业务 字段，不会影响到现有的服务
5. 技术的流行程度，越流行的技术意味着使用的公司多，那么很多坑都已经淌过并且得到了解决，技术解决方案也相对成熟
6. 学习难度和易用性

选型建议

1. 对性能要求不高的场景，可以采用基于 XML 的 SOAP 协议
2. 对性能和间接性有比较高要求的场景，那么 Hessian、Protobuf、Thrift、 Avro 都可以。
3. 基于前后端分离，或者独立的对外的 api 服务，选用 JSON 是比较好的，对于调试、可读性都很不错
4. Avro 设计理念偏于动态类型语言，那么这类的场景使用 Avro 是可以的