写在前面

两个月前，我们写过一篇关于fury和protostuff的性能对比的文章：谁才是真正的协议之王？fastjson2 vs fury，那时，两个协议框架各有千秋，不分伯仲，今天，看到fury推出了全新的0.2.0版本，fastjson2推出了新2.0.41版本，据说都有很多性能的提升，今天打算再一测，希望这两家伙再接再厉，能带给我们更多惊喜！
我们这次的侧重点，主要关注在序列化，反序列化，数据包压缩率大小。
上次的结论我们再回顾下：

序列化对比
fastjson2在BeanToArray（将对象序列化成数组）情况下，是protostuff 的26.996倍。
fury在 引用解析（RefTracking）关闭，类注册（ClassRegistration）打开，整数压缩（NumberCompressed）打开的情况下 ，是protostuff 的28.160倍。
fury 胜出！
反序列化对比
fastjson2在SupportArrayToBean（将数组反序列化成对象）情况下，是protostuff 的25.002倍。
fury在 引用解析（RefTracking）关闭，类注册（ClassRegistration）打开，整数压缩（NumberCompressed）打开的情况下 ，是protostuff 的22.598倍。
fastjson2 胜出！
包体压缩比上
选取各自表现最优的情况下，fury , protostuff,fastjson 比较 20.45%> 17.90%>16.34% ，fastjson2 胜出！
@ 2023/08/19

官网和引入

fastjson2
官网:无
开源地址:https://github.com/alibaba/fastjson2
使用引入:

implementation 'com.alibaba.fastjson2:fastjson2:2.0.41'

fury
官网:https://furyio.org
开源地址:https://github.com/alipay/fury
使用引入:

implementation 'org.furyio:fury-core:0.2.0'

设备，环境及样本

设备

测试设备: win11, 8core,16g memory，

JDK

openjdk version "11.0.16.1" 2022-08-16
OpenJDK Runtime Environment TencentKonaJDK (build 11.0.16.1+2)
OpenJDK 64-Bit Server VM TencentKonaJDK (build 11.0.16.1+2, mixed mode)

样本

用游戏中高频调用的技能回包做样本，字节大小 为704 bytes，

SkillFire_S2C_Msg[attackerId=2013850838,harmList={HarmDTO[curHp=1061639.1,dead=true,maxHp=972081.06,real=36249,targetId=1711281434,type=84,value=18168.72],HarmDTO[curHp=836323.44,dead=true,maxHp=8546706.0,real=91675,targetId=1527336063,type=22,value=30714.76],HarmDTO[curHp=2022717.6,dead=true,maxHp=8923567.0,real=74008,targetId=1684460215,type=67,value=93250.83]},index=37,param1={7153337,1918282,5243103,1985757,7515730},skillCategory=ATTACK_PASSIVE]

放一张使用的游戏场景，让大家感性认识一下，你所看到的绚丽的技能效果背后是无数个SkillFire_S2C_Msg协议在来回游荡：

测评数据

性能测评的项目下载路径如下：
https://github.com/jiangguilong2000/gamioo-sandbox.git

包体大小

对序列化后传输包体压缩率的各种比较如下：

协议	设置	压缩率	前值
fastjson2	BeanToArray=false	41.48%	一样
fastjson2	BeanToArray=true	16.34%	一样
fury	NumberCompressed=false	24.01%	35.94%
fury	NumberCompressed=true	18.61%	27.84%
fury	NumberCompressed=true,ClassRegistration	18.61%	20.45%
Protostuff		17.90%	一样

序列化

Benchmark                                                                       Mode  Cnt         Score        Error  Units
ProtoSerializeBenchMark.furySerialize                                          thrpt   10   8008220.631 ± 187910.778  ops/s
ProtoSerializeBenchMark.furySerializeWithClassRegistrationAndNumberCompressed  thrpt   10  13614652.032 ± 514327.393  ops/s
ProtoSerializeBenchMark.jsonSerialize                                          thrpt   10   3076330.832 ±  76810.104  ops/s
ProtoSerializeBenchMark.jsonSerializeWithBeanToArray                           thrpt   10   8459437.606 ± 263671.263  ops/s
ProtoSerializeBenchMark.jsonSerializeWithBeanToArrayAndFieldBase               thrpt   10   7289778.892 ± 179821.080  ops/s
ProtoSerializeBenchMark.protostuffSerialize                                    thrpt   10    237222.753 ±  15051.667  ops/s

反序列化

Benchmark                                                                           Mode  Cnt        Score        Error  Units
ProtoDeserializeBenchMark.furyDeserialize                                          thrpt   10  5139942.244 ± 134681.750  ops/s
ProtoDeserializeBenchMark.furyDeserializeWithClassRegistrationAndNumberCompressed  thrpt   10  7929230.323 ± 143908.696  ops/s
ProtoDeserializeBenchMark.jsonDeserialize                                          thrpt   10  3166615.576 ± 142094.220  ops/s
ProtoDeserializeBenchMark.jsonDeserializeWithArrayToBean                           thrpt   10  5894992.128 ± 174962.357  ops/s
ProtoDeserializeBenchMark.jsonDeserializeWithArrayToBeanAndFieldBase               thrpt   10  5846732.053 ± 183195.377  ops/s
ProtoDeserializeBenchMark.protostuffDeserialize                                    thrpt   10   245674.644 ±   7632.013  ops/s

结论

序列化对比

fastjson2在BeanToArray（将对象序列化成数组）情况下，是protostuff 的30.73倍，比上次26.996提升了13.83%。
fury在 引用解析（RefTracking）关闭，类注册（ClassRegistration）打开，整数压缩（NumberCompressed）打开的情况下 ，是protostuff 的57.39，比上次测试的28.160性能提升了103.8%。
fury 胜出！并且，两者性能差距断崖式拉大。

反序列化对比

fastjson2在SupportArrayToBean（将数组反序列化成对象）情况下，是protostuff 的23.99倍。
fury在 引用解析（RefTracking）关闭，类注册（ClassRegistration）打开，整数压缩（NumberCompressed）打开的情况下 ，是protostuff 的32.275倍，比上次测试的22.598提升了42.82%
fury 反败为胜,并且，两者性能差距大幅拉大。

包体压缩比上

选取各自表现最优的情况下，fury , protostuff,fastjson 比较
18.61%>17.90%> 16.34%，前值是20.45%> 17.90%>16.34%，依旧是fastjson2 胜出！

综述

总之，经过一个大版本的迭代，fury在核心指标序列化，反序列化上已经迎头赶上，并大幅拉开和fastjson2的差距，压缩比上，也大大的缩小了和fastjson2的差距，这是让笔者感到令人惊喜的成果，如果能在多语言生态特别是C#，和接口的易用性上更上一层，谁会笑到最后，让我们拭目以待。

附言：本人认知有限，如本文中有错误的使用或者见解，请联系我纠正，谢谢！

Q&A
Q.当前版本，提前显式注册类不再需要了？
A:对的，带来的影响，简化了框架的使用复杂度，提升了性能。
Q.对long类型的数据有没有优化算法？
A:有的，ong的范围都是在int范围内，其实你可以换成int来序列化，fury压缩率比jsonb要高的，有个高压缩率的long编码算法，在你这个场景开启后压缩效果也更好一点，但是也会导致你数据里面的List跟着一起压缩，而jsonb没有压缩，所以我们默认没开,要开的话，withLongCompressed(LongEncoding.PVL)，压缩率更高，不过有性能损失，一般不打开,发现开启后，包体是能进一步压缩，但性能影响还挺大，暂时不用。