这段时间在公司搞序列化相关的优化，这里做下笔记吧。
项目背景
项目采用dubbo（版本不自带protostuff序列化），接口参数为byte[]，这里的byte[]是由应用先用protobuf工具序列化然后再传。传输的数据再几十k到几百k都有
优化过程
pb字段优化及精简
因为我们传输数据较大，所以要考虑pb字段优化及精简。字段精简主要从业务上考虑，有没有哪些字段是冗余的，比如项目中就有repeated字段中有不少字段，其中一个string字段大概10-30个字节，repeated数组在1000以上，这要光这个字段大小至少在10K以上了（实际平均值超过20K）。但对于这个业务，无论repeated多大，每次这个string字段最多只有三个取值（每次三个取值可能是不一样的，因此不能用枚举），完全可以提到更高一层，这样就节省了不少空间。至于pb字段优化，主要是字段编码的选取。序列化方向优化
这里主要看了protobuf作者的capnproto，测试发现要比protobuf快不少，但空间占用也比较大，而对服务瓶颈cpu没什么明显提高，在加上比较小众，最终没有采用。官网：https://capnproto.org/pb对象复用
pb对象每个请求用一次，序列化完就结束了，对我们来说，这个对象也不小，百K级别，如果复用了会不会有些提高呢？
说起复用，第一时间想到对象池。但对象池更适合的场景应该是主要属性不变，如连接池（资源昂贵，构建后连接信息不变，可以复用），大对象池（构建困难，但构建后基本不会），对pb来说，每个请求都是不一样的，而且项目中pb类占用空间最大的是对象数组，即有很多小对象。复用起来比较麻烦，首先protobuf自带的jar包生成的pb类是不能复用的（对象是builder模式，且不可变），因此我采用的是protostuff，protostuff的类是自己定义的，因此怎么复用都行。但反序列化的对象是在protostuff内部源码中实现的，不好复用，我是利用protostuff-compiler(protostuff项目中的compiler只支持proto2，我使用的是这个独立项目https://github.com/protostuff/protostuff-compiler)生成静态的protostuff类（这里生成的也是builder模式的类，通过修改相关配置文本可以去掉builder模式），这样new的时机就在代码中，而不需要修改protostuff相关源代码。但又有个问题，因为我们项目中是大量小对象，是不适合存在对象池的（否则从对象池取和归还对象都是很大的开销），因此反序列化的pb对象虽然new的实现不在源码中，但复用没有实现价值了。正序列化pb对象还是可以复用的，最终采用的是ThreadLocal存储，直接存pb对象中的对象数组，用Object[]存在ThreadLocal中。用的时候直接取Object[]，然后按顺序取数组中的对象进行使用，对象不够直接new，支持动态增长。值得注意的是，对象中的包装类型需要改成基本类型。复用后，ygc次数减少10%，cpu相对提升5%。dubbo序列化
我们项目中dubbo序列化方式是默认的hessian，参数是pb后的byte[]，但hessian在大对象场景下性能较差。以正序列化为例，hessian在本地存了个固定大小为4k的buffer，然后将接口中的byte[]逐步拷贝到buffer，假设一次拷贝4k（实际上有点差别），那么100k的数据需要拷贝25次。单纯拷贝多次问题不大，但这里的拷贝是从堆内内存拷贝到堆外内存，这里就涉及到内核态切换了，很影响性能。在测试环境测试，同样的cpu使用率情况下，300k的序列化protobuf(byte[])比hessian(byte[])快30%，tps高50%。当然这里不是严格的基准测试，不过也能说明一些问题。
