序列化与反序列化
1 Java领域的对象如何传输
1.1 基于socket进行对象传输
1 | |
运行结果:这段代码运行后,会报错:

对User对象实现一个Serializable接口,再次运行就可以看到对象能够正常传输
1 | |
1.2 序列化的意义
发现对User这个类增加一个Serializable,就可以解决Java对象的网络传输问题。这就是序列化。
Java平台允许在内存中创建可复用的java对象,但一般情况下,只有当JVM出于运行时,这些对象才可能存在,即这些对象的生命周期不会比JVM的生命周期长。但在现实应用中,就可能要求在JVM停止运行后能够保存(持久化)指定的对象,并在将来重新读取被保存的对象。Java对象序列化就能够实现该功能。
简单来说:序列化是把对象的状态信息转化为可存储或传输的形式过程,也就是把对象转化为字节序列的过程称为对象的序列化。反序列化是序列化的逆向过程,把字节数组反序列化为对象,把字节序列恢复为对象的过程称为对象的反序列化。
2 序列化的高阶认识
2.1 简单认识以下java原生序列化
前面的代码中演示了,如何通过JDK提供了java对象的序列化方式实现对象序列化传输,主要通过输出流java.io.ObjectOutputStream和对象输入流java.io.ObjectInputStream来实现。
OutputStream:表示对象输出流,它的writeObect(Object obj)方法可以对参数指定的obj对象进行序列化,把得到的字节序列写到一个目标输出流中。
InputStream:表示对象输入流,它的readObject()方法从输入流中读取字节序列,再把他们反序列化为一个对象,并将其返回。
注意,被序列化的对象需要实现java.io.Serializable接口
2.2 序列化的高阶认识
serialVersionUID的作用,在IDEA中通过如下设置可以生成serializeid,字面上的意思是序列化的版本号,凡是实现Serializable接口的类都有一个表示序列化版本标识符的静态变量。
java的序列化机制是通过判断类的serialVersionUID来验证版本一致性的。在进行反序列化时,JVM会把传来的字节流中的serialVersionUID与本地相应实体类的serialVersionUID进行比较,如果相同就认为一致的,可以进行反序列化,否则就会出现序列化版本不一致的异常,即是InvalidCastException。
从结果可以看出,文件流的class和classpath中的class,也就是修改过后的class,不兼容了,出于安全机制考虑,程序抛出了错误,并且拒绝载入。从错误结果来看,如果没有为指定的class配置serialVersionUID,那么java编译器会自动给这个class进行一个摘要算法,类似于指纹算法,只要这个文件有任何改动,得到的UID就会截然不同的,可以保证在这么多类中,这个编号是唯一的。所以,由于没有显示指定serialVersionUID,编译器又生成了一个UID,当然和前面保存在文件中的不一样了,于是出现了2个序列化版本号不一致的错误。因此,只要指定了serialVersionUID,就可以在序列化后,去添加一个字段,或者方法,而不会影响到后期的还原,还原后的对象照样可以使用,而且还多了方法或者属性可以用。
serialVersionUID有两种显示的生成方式:
1、是默认的1L,比如private static final long serialVersionUID = 1L
2、是根据类名,接口名,成员方法及属性等来生成要给64位的哈希字段
当实现java.io.Serializable接口的类没有显示的定义一个serialVersionUID变量的时候,Java序列化机制会根据编译的class自动生成一个serialVersionUID作序列化版本比较用,这种情况下,如果Class文件(类名,方法名等)没有发生变化(增加空格,换行,增加注释等),就算再编译多次,serialVersionUID也不会变化的。
2.3 Transient关键字
transient关键字的作用是控制变量的序列化,在变量声明前加上该关键字,可以阻止该变量被序列化到文件中,在被反序列后,transient变量的值被设为初始值,如int型的是0,对象型的是null。
虽然name被transient修饰,但是通过写的这两个方法依然能够使得name字段正确被序列化和反序列化。
writeObject和readObject是两个私有的方法,他们是什么时候被调用的呢?从运行结果来看,它确实被调用。而且他们并不存在于java.lang.Object,也没有再Serializable中去声明。唯一的猜想应该还是和ObjectInputStream和ObjectOutputStream有关系,所以基于这个入口去看看在哪个地方有调用。从源码层面来分析可以看到,readObject是通过反射来调用的。其实可以在很多地方看到readObject和writeObject的使用,比如HashMap。
2.4 java序列化的一些简单总结
1、java序列化只是针对对象的状态进行保存,至于对象中的方法,序列化不关心
2、当一个父类实现了序列化,那么子类会自动实现序列化,不需要显示实现序列化接口
3、当一个对象的实例变量引用了其他对象,序列化这个对象的时候会自动把引用的对象也进行序列化(实现深度克隆)
4、当某个字段被声明位transient后,默认的序列化机制会忽略这个字段
5、被声明为transient的字段,如果需要序列化,可以添加两个私有方法:writeObject和readObject
3 分布式架构下常见的序列化技术
3.1 了解序列化的发展
随着分布式架构、微服务架构的普及。服务与服务之间的通信成了最基本的需求。这个时候,不仅需要考虑通信的性能,也需要考虑到语言多元化的问题。所以,对于序列化来说如何去提升序列化性能以及解决跨语言问题,就成了一个重点考虑的问题。
由于java本身提供的序列化机制存在两个问题:
1、序列化的数据比较大,传输效率低
2、其他语言无法识别和对接
以致于在后来的很长一段时间,基于XML格式编码的对象序列化机制成为了主流,一方面解决了多语言兼容问题,另一方面比二进制的序列化方式更容易理解。以至于基于XML的SOAP协议及对应的WebService框架在很长一段时间内成为各个主流开发语言的必备的技术。
再到后来,基于json的简单文本格式编码的HTTP REST接口又基本上取代了复杂的Web Servcice接口,成为分布式架构中远程通信的首要选择。但是json序列化存储占用的空间大,性能低等问题,同时移动客户端应用需要更高效的传输数据来提升用户体验。在这种情况下与语言无关并且高效的二进制编码协议就成为了大家追求的热点技术之一,首先诞生的一个开源的二进制序列化框架-MessagePack。它比google的Prorocol Buffers出现的还要早。
3.2 简单了解各种序列化技术
3.2.1 Xml序列化框架介绍
xml序列化在于可读性好,方便阅读和调试。但是序列化以后的字节码文件比较大,而且效率不高,适用于对性能不高,而且QPS较低的企业级内部系统之间的数据交换的场景,同时XML又具有语言无关性,所以还可以用于异构系统之间的数据交换和协议。比如熟知的webservice,就是采用xml格式对数据进行序列化的。xml序列化/反序列化的实现方式有很多,熟知的方式有Xstream和java自带的xml序列化和反序列化两种。
3.2.2 JSON序列化框架
JSON(JavaScript Object Notation)是一种轻量级的数据交换格式,相对于XML来说,json的字节流更小,而且可读性也非常好,现在json数据格式在企业运用是最普遍的,json序列化常用的开源工具有很多:
1、Jackson https://github.com/FasterXML/jackson
2、阿里开源的fastJSON https://github.com/alibaba/fastjson
3、Google的GSON https://github.com/google/gson
这几种json序列化工具中,Jackson和FastJson要比GSON的性能要好,但是jackson、GSON的稳定性要比fastjson好。而fastjson的优势在于提供的api非常容易使用。
3.2.3 Hessian序列化框架
Hessian是一个支持跨语言传输的二进制序列化协议,相对于java默认的序列化机制来说,Hessian具有更好的性能和易用性,而且支持多种不同的语言,实际上Dubbo采用的就是Hessian序列化来实现,只不过Dubbo对Hessian进行了重构,性能更高。
3.2.4 Avro序列化
Avro是一个数据序列化系统,设计用于支持大批量数据交换的应用。它的主要特点有:支持二进制序列化方式,可以便捷,快速地处理大量数据;动态语言友好,Avro提供地机制使得动态语言可以方便地处理Avro数据。
3.2.5 kyro序列化框架
Kyro是一种非常成熟地序列化实现,已经在Hive,Storm中使用的比较广泛,不过它不能跨语言,目前dubbo已经在2.6版本中支持kyro的序列化机制。它的性能要优于之前的hessian2
3.2.6 Protobuf序列化框架
Protobuf是Google的一种数据交换格式,它独立于语言,独立于平台。Google提供了多种语言来实现,比如java,C,Go,Python,每一种实现都包含了相应语言的编译器和库文件,Protobuf是一个纯粹的表示层协议,可以和各种传输层协议一起使用。
Protobuf使用比较广泛,主要是空间开销小和性能比较好,非常适合用于公司内部对性能要求高的RPC调用。另外由于解析性能比较高,序列化以后数据量相对较少,所以也可以应用在对象的持久化场景中。但是要使用Protobuf会相对来说麻烦些,因为他有自己的语法,有自己的编译器,如果需要用到的话必须要投入成本在这个技术的学习中。Protobuf有个缺点就是要传输的每一个类的结构都要生成相应的proto文件,如果某个类发生修改,还得重新生成类对应的proto文件。
4 序列化技术的选型
4.1 技术层面
1、序列化空间开销,也就是序列化产生的结果大小,这个影响到传输的性能
2、序列化过程中消耗的时长,序列化消耗时间过长影响到业务的响应时间
3、序列化协议是否支持跨平台,跨语言。因为现在的架构更加灵活,如果存在异构系统通信需求,那么这个是必须要考虑的。
4、可扩展性/兼容性,在实际业务开发中,系统往往需要随着需求的快速迭代来实现快速更新,这就要求采用的序列化协议基于良好的可扩展性/兼容性,比如在现有的序列化数据结构中新增一个业务字段,不会影响到现有的服务
5、技术的流行程度,越流行的技术意味着使用的公司多,那么很多坑都已经淌过并且得到了解决,技术解决方案也相对成熟
6、学习难度和易用性
4.2 选型建议
1、对性能要求不高的场景,可以采用基于XML的SOAP协议
2、对性能和间接性有比较高要求的场景,那么Hessian,Protobuf,Thrift,Avro都可以
3、基于前后端分离,或者独立的对外的api服务,选用json是比较好的,对于调试,可读性都很不错
4、Avro设计理念偏于动态类型语言,那么这类的场景使用Avro是可以的
这个地址有针对不同系列化技术进行性能比较: https://github.com/eishay/jvm-serializers/wiki