原文链接:几种Java常用序列化框架的选型与对比
背景介绍
序列化与反序列化是我们日常数据持久化和网络传输中经常使用的技术,但是目前各种序列化框架让人眼花缭乱,不清楚什么场景到底采用哪种序列化框架。本文会将业界开源的序列化框架进行对比测试,分别从通用性、易用性、可扩展性、性能和数据类型与Java语法支持五方面给出对比测试。
通用性:通用性是指序列化框架是否支持跨语言、跨平台。
易用性:易用性是指序列化框架是否便于使用、调试,会影响开发效率。
可扩展性:随着业务的发展,传输实体可能会发生变化,但是旧实体有可能还会被使用。这时候就需要考虑所选择的序列化框架是否具有良好的扩展性。
性能:序列化性能主要包括时间开销和空间开销。序列化的数据通常用于持久化或网络传输,所以其大小是一个重要的指标。而编解码时间同样是影响序列化协议选择的重要指标,因为如今的系统都在追求高性能。
Java数据类型和语法支持:不同序列化框架所能够支持的数据类型以及语法结构是不同的。这里我们要对Java的数据类型和语法特性进行测试,来看看不同序列化框架对Java数据类型和语法结构的支持度。
整体比较
框架 | JDK序列化 | FST | Kryo | Protobuf(注2) | Thift | Hession | Avro |
---|---|---|---|---|---|---|---|
通用性 | 不支持 | 不支持 | 支持但非常复杂 | 非常通用 | 非常通用 | 支持跨语言RPC通信 | 非常通用 |
易用性 | 略复杂 | 语法简洁 | 语法简洁 | 比较简单 | 比较简单 | 非常简单 | 略复杂 |
可扩展性 | 可扩展(注1) | 略复杂 | 支持 | 友好支持 | 友好支持 | 友好支持 | 略复杂 |
性能 | 耗时久,字节多 | 速度快,字节少 | 速度快,字节少 | 略低于前FST,Kryo | 和Protobuf类型 | 速度快,字节少 | 速度快,字节少 |
数据类型和语法支持 | 基本支持 | 基本支持 | 基本支持 | 不支持定义Java方法 | 不支持定义Java方法 | 基本支持 | 不支持定义Java方法 |
详细比较
序列化框架 | 通用性 |
---|---|
JDK Serializer | 使用语法过于生硬 |
FST | 使用简洁,FSTConfiguration提供了序列化与反序列化的方法 |
Kryo | 使用简洁,Input/Output封装了几乎所有能有需要的流方法 |
Protocol buffer | 稍微复杂。需要编写所需序列化类的proto文件,然后编译生成Java代码。但是自动生成Java类,包含了序列化与反序列化方法 |
Thrift | 稍微复杂。需要编写所需的序列化类的thrift文件,然后编译生成Java代码。然后通过TSerializer和TDserializer进行序列化与反序列化 |
Hessian | 使用简单,在跨语言的基础上不需要使用IDL |
Avro | 使用较复杂。相较于Protobuf和Thrift来说,对于一些静态语言无序生成代码。但是对于Java来一般还需要生成代码,并且Avro提供的API不是很友好 |
序列化框架 | 易用性 |
---|---|
JDK Serializer | 使用语法过于生硬 |
FST | 使用简洁,FSTConfiguration提供了序列化与反序列化的方法 |
Kryo | 使用简洁,Input/Output封装了几乎所有能有需要的流方法 |
Protocol buffer | 稍微复杂。需要编写所需序列化类的proto文件,然后编译生成Java代码。但是自动生成Java类,包含了序列化与反序列化方法 |
Thrift | 稍微复杂。需要编写所需的序列化类的thrift文件,然后编译生成Java代码。然后通过TSerializer和TDserializer进行序列化与反序列化 |
Hessian | 使用简单,在跨语言的基础上不需要使用IDL |
Avro | 使用较复杂。相较于Protobuf和Thrift来说,对于一些静态语言无序生成代码。但是对于Java来一般还需要生成代码,并且Avro提供的API不是很友好 |
序列化框架 | 可扩展性 |
---|---|
JDK Serializer | 自定义serialVersionUID,保证序列化前后VUID一致即可 |
FST | 通过@Version控制版本,新增字段需要修改Version版本 |
Kryo | 默认序列化器不支持字段扩展,需要修改默认序列化器或自己实现序列化器 |
Protocol buffer | 支持字段扩展,只要保证新增id标识没有使用过即可 |
Thrift | 支持字段扩展。新增字段为required类型时,需要设置默认值 |
Hessian | 支持字段扩展 |
Avro | 支持字段扩展。注意需要为字段设置默认值 |
序列化大小对比
对比各个序列化框架序列化后的数据大小如下,可以看出kryo preregister(预先注册序列化类)和Avro序列化结果都很不错。所以,如果在序列化大小上有需求,可以选择Kryo或Avro。
序列化时间开销对比
序列化与反序列化的时间开销,kryo preregister和fst preregister都能提供优异的性能,其中fst pre序列化时间就最佳,而kryo pre在序列化和反序列化时间开销上基本一致。所以,如果序列化时间是主要的考虑指标,可以选择Kryo或FST,都能提供不错的性能体验。
注1:JDK序列化 可扩展性描述
JDK Serializable中通过serialVersionUID控制序列化类的版本,如果序列化与反序列化版本不一致,则会抛出java.io.InvalidClassException异常信息,提示序列化与反序列化SUID不一致。
java.io.InvalidClassException: com.yjz.serialization.java.UserInfo; local class incompatible: stream classdesc serialVersionUID = -5548195544707231683, local class serialVersionUID = -5194320341014913710
上面这种情况,是由于我们没有定义serialVersionUID,而是由JDK自动hash生成的,所以序列化与反序列化前后结果不一致。
但是我们可以通过自定义serialVersionUID方式来规避掉这种情况(序列化前后都是使用定义的serialVersionUID),这样JDK Serializable就可以支持字段扩展了。
private static final long serialVersionUID = 1L;
注2 Protocol buffer 介绍
Protocol buffer是一种语言中立、平台无关、可扩展的序列化框架。Protocol buffer相较于前面几种序列化框架而言,它是需要预先定义Schema的。
下面是使用Protobuf的Demo:
(1)编写proto描述文件:
syntax = "proto3";
option java_package = "com.yjz.serialization.protobuf3";
message MessageInfo
{
string username = 1;
string password = 2;
int32 age = 3;
map<string,string> params = 4;
}
(2)生成Java代码:
protoc --java_out=./src/main/java message.proto
(3)生成的Java代码,已经自带了编解码方法:
//编码
byte[] bytes = MessageInfo.toByteArray()
//解码
MessageInfo messageInfo = Message.MessageInfo.parseFrom(bytes);