常见Serialize技术探秘（ObjectXXStream、XML、JSON、JDBC byte编码、Protobuf）

目前业界有各种各样的网络输出传输时的序列化和反序列化方案，它们在技术上的实现的初衷和背景有较大的区别，因此在设计的架构也会有很大的区别，最终在落地后的：解析速度、对系统的影响、传输数据的大小、可维护性及可阅读性等方面有着较大的区别，本文分享一些我在一些常见序列化技术的分析和理解：

文章分成3个部分：

1、列举常见的序列化和反序列化方案（ObjectXXStream、XML、JSON）

2、MySQL JDBC结果集的处理方案

3、Google Protocol Buffer处理方案

【一、常见的在API及消息通信调的用中Serialize方案】：

方案1、基于Java原生的ObjectOutputStream.write()和ObjectInputStream.read()来进行对象序列化和反序列化。

方案2、基于JSON进行序列化和反序列化。

方案3、基于XML进行序列化和反序列化。

【方案1浅析，ObjectXXXStream】：

优点：

（1）、由Java自带API序列化，简单、方便、无第三方依赖。

（2）、不用担心其中的数据解析会丢失精度、丢失字段、Object的反序列化类型不确定等问题。

缺点：

（1）、双方调试麻烦，发送方和接收方最好是同版本的对象描述，否则会有奇怪的问题，调试周期相对长，跨团队合作升级问题很多。

（2）、传递的对象中包含了元数据信息，占用空间较大。

【方案2浅析，JSON序列化】：

优点：

（1）、简单、方便，无需关注要序列化的对象格式。

（2）、开源界有较多的组件可以支持，例如FastJSON性能非常好。

（3）、在现在很多RPC的框架中，基本都支持这样的方案。

缺点：

（1）、对象属性中如果包含Object类型，在反序列化的时候如果业务也本身也不明确数据类型，处理起来会很麻烦。

（2）、由于文本类型，所以一定会占用较大的数据空间，例如下图。

（3）、比较比较依赖于JSON的解析包的兼容性和性能，在JSON的一些细节处理上（例如一些非标的JSON），各自处理方式可能不一样。

（4）、序列化无论任何数据类型先要转换为String，转成byte[]，会增加内存拷贝的次数。

（5）、反序列化的时候，必须将整个JSON反序列化成对象后才能进行读取，大家应该知道，Java对象尤其是层次嵌套较多的对象，占用的内存空间将会远远大于数据本身的空间。

数据放大的极端案例1：

传递数据描述信息为:

class PP {

    long userId                       = 102333320132133L;

    int    passportNumber      = 123456;

}

此时传递JSON的格式为：

{

     "userId":102333320132133,

     "passportNumber":123456

}

我们要传递的数据是1个long、1个int，也就是12个字节的数据，这个JSON的字符串长度将是实际的字节数（不包含回车、空格，这里只是为了可读性，同时注意，这里的long在JSON里面是字符串了），这个字符串有：51个字节，也就是数据放到了4.25倍左右。

数据放大极端案例2：

当你的对象内部有数据是byte[]类型，JSON是文本格式的数据，是无法存储byte[]的，那么要序列化这样的数据，只有一个办法就是把byte转成字符，通常的做法有两种：

（1）使用BASE64编码，目前JSON中比较常用的做法。

（2）按照字节进行16进制字符编码，例如字符串：“FF”代表的是0xFF这个字节。

不论上面两种做法的那一种，1个字节都会变成2个字符来传递，也就是byte[]数据会被放大2倍以上。为什么不用ISO-8859-1的字符来编码呢？因为这样编码后，在最终序列化成网络byte[]数据后，对应的byte[]虽然没变大，但是在反序列化成文本的时候，接收方并不知道是ISO-8859-1，还会用例如GBK、UTF-8这样比较常见的字符集解析成String，才能进一步解析JSON对象，这样这个byte[]可能在编码的过程中被改变了，要处理这个问题会非常麻烦。

【方案2浅析，XML序列化】：

优点：

（1）、使用简单、方便，无需关注要序列化的对象格式

（2）、可读性较好，XML在业界比较通用，大家也习惯性在配置文件中看到XML的样子

（3）、大量RPC框架都支持，通过XML可以直接形成文档进行传阅

缺点：

（1）、在序列化和反序列化的性能上一直不是太好。

（2）、也有与JSON同样的数据类型问题，和数据放大的问题，同时数据放大的问题更为严重，同时内存拷贝次数也和JSON类型，不可避免。

XML数据放大说明：

XML的数据放大通常比JSON更为严重，以上面的JSON案例来讲，XML传递这份数据通常会这样传：

<Msg>

     <userId>102333320132133</userId>

     <passportNumber>123456<passportNumber>

<Msg>

这个消息就有80+以上的字节了，如果XML里面再搞一些Property属性，对象再嵌套嵌套，那么这个放大的比例有可能会达到10倍都是有可能的，因此它的放大比JSON更为严重，这也是为什么现在越来越多的API更加喜欢用JSON，而不是XML的原因。

【放大的问题是什么】：

（1）、花费更多的时间去拼接字符串和拷贝内存，占用更多的Java内存，产生更多的碎片。

（2）、产生的JSON对象要转为byte[]需要先转成String文本再进行byte[]编码，因为这本身是文本协议，那么自然再多一次内存全量的拷贝。

（3）、传输过程由于数据被放大，占用更大的网络流量。

（4）、由于网络的package变多了，所以TCP的ACK也会变多，自然系统也会更大，同等丢包率的情况下丢包数量会增加，整体传输时间会更长，如果这个数据传送的网络延迟很大且丢包率很高，我们要尽量降低大小；压缩是一条途径，但是压缩会带来巨大的CPU负载提高，在压缩前尽量降低数据的放大是我们所期望的，然后传送数据时根据RT和数据大小再判定是否压缩，有必要的时候，压缩前如果数据过大还可以进行部分采样数据压缩测试压缩率。

（5）、接收方要处理数据也会花费更多的时间来处理。

（6）、由于是文本协议，在处理过程中会增加开销，例如数字转字符串，字符串转数字；byte[]转字符串，字符串转byte[]都会增加额外的内存和计算开销。

不过由于在平时大量的应用程序中，这个开销相对业务逻辑来讲简直微不足道，所以优化方面，这并不是我们关注的重点，但面临一些特定的数据处理较多的场景，即核心业务在数据序列化和反序列化的时候，就要考虑这个问题了，那么下面我继续讨论问题。

此时提出点问题：

（1）、网络传递是不是有更好的方案，如果有，为什么现在没有大面积采用？

（2）、相对底层的数据通信，例如JDBC是如何做的，如果它像上面3种方案传递结果集，会怎么样？

【二、MySQL JDBC数据传递方案】：

在前文中提到数据在序列化过程被放大数倍的问题，我们是否想看看一些相对底层的通信是否也是如此呢？那么我们以MySQL JDBC为例子来看看它与JDBC之间进行通信是否也是如此。

JDBC驱动程序根据数据库不同有很多实现，每一种数据库实现细节上都有巨大的区别，本文以MySQL JDBC的数据解析为例（MySQL 8.0以前），给大家说明它是如何传递数据的，而传递数据的过程中，相信大家最为关注的就是ResultSet的数据是如何传递的。

抛开结果集中的MetaData等基本信息，单看数据本身：

（1）JDBC会读取数据行的时候，首先会从缓冲区读取一个row packege，row package就是从网络package中拿到的，根据协议中传递过来的package的头部判定package大小，然后从网络缓冲中读取对应大小的内容，下图想表达网络传递的package和业务数据中的package之间可能并不是完全对应的。另外，网络中的package如果都到了本地缓冲区，逻辑上讲它们是连续的（图中故意分开是让大家了解到网络中传递是分不同的package传递到本地的），JDBC从本地buffer读取row package这个过程就是内核package到JVM的package拷贝过程，对于我们Java来讲，我们主要关注row package（JDBC中可能存在一些特殊情况读取过来的package并不是行级别的，这种特殊情况请有兴趣的同学自行查阅源码）。

（2）、单行数据除头部外，就是body了，body部分包含各种各样不同的数据类型，此时在body上放数据类型显然是占空间的，所以数据类型是从metadata中提取的，body中数据列的顺序将会和metdata中的列的顺序保持一致。

（3）、MySQL详细解析数据类型：

      3.1、如果Metadata对应数据发现是int、longint、tinyint、year、float、double等数据类型会按照定长字节数读取，例如int自然按照4字节读取，long会按照8字节读取。

      3.2、如果发现是其它的类型，例如varchar、binary、text等等会按照变长读取。

      3.3、变长字符串首先读取1个字节标志位。

      3.4、如果这个标志位的值小于等于250，则直接代表后续字节的长度（注意字符串在这里是算转换为字节的长度），这样确保大部分业务中存放的变长字符串，在网络传递过程中只需要1个字节的放大。

      3.5、如果这个标志位是：251，代表这个字段为NULL

      3.6、如果标志位是：252，代表需要2个字节代表字段的长度，此时加上标志位就是3个字节，在65536以内的长度的数据（64KB），注意，这里会在转成long的时候高位补0，所以2个字节可以填满到65536，只需要放大3个字节来表示这个数据。

      3.7、如果标志位是：253，代表需要4个自己大表字段的长度，可以表示4GB（同上高位补0），这样的数据几乎不会出现在数据库里面，即使出现，只会出现5个字节的放大。

      3.8、如果标志位是：254，8个字节代表长度，此时没有高位补0，最多可以读取Long.MAX_VALUE的长度，但是这个空间目前不可能有内存放得下，所以无需担心使用问题，此时9个字节的放大，源码如下图：

（4）、我们先按照这个理解，MySQL在传递数据的过程中，对数据的放大是很小很小的，是不是真的这样呢？请下面第5点说明。

补充说明：

a、在MySQL JDBC中对于ResultSetRow数据的解析（除对MySQL 8.0以上JDBC版本）有2个实现类：BufferRow、ByteArrayRow，这两种方式在读取单行数据在解析这个阶段是一样的逻辑，只不过解析存放数据的方式有所不同，BufferRow一个会解析成数据行的byte[]，ByteArrayRow会解析成byte[][]二维数组，第二维就是每1个列的信息，这都是客户端行为，与网络传递数据的格式无关。（两者在不同场景下使用，例如其中一种场景是：ByteArrayRow在游标开启UPDATE模式的时候会启用，但这不是本文的重点，这里提到主要告知大家，无论哪一种方式，读取数据的方式是一致的）

b、在MySQL JDBC中的RowData是ResultSet里面数据处理的入口，其实现类有3个：RowStatStatic、RowDataCursor、RowDataDynamic，这虽然有3个实现类，但是同样不会影响数据的格式，它们只是从缓冲区读取数据的方式有所不同：RowStatStatic、RowDataCursor会每次将缓冲区的数据全部读取到JDBC当中形成数组，RowDataCursor在处理上有一个区别在于数据库每次返回的是FetchSize大小的数据内容（实现的细节在上一篇文章中有提到）；RowDataDynamic是需要行的时候再从pakcege中去读，package读取完成后就尝试读取下一个package。这些都不会影响数据本身在网络上的传递格式，所以文本提到的解析是目前MySQL JDBC比较通用的解析，与它内部的执行路径无关。

（5）、以BufferRow为例，当你发起getString('xxx')、getDate(int)的时候，首先它需要在内部找到是第几个列（传数字省略该动作），然后其内部会有一个lastRequestedIndex、lastRequestedPos分别记录最后读取的第几个字段和所在字节的位置，如果你传入的index比这个index大，则从当前位置开始，向后扫描，扫描规则和上面的数据库宽度一致，找到对应位置，拷贝出对应的byte[]数组，转换你要的对象类型。

PS：lastRequestedIndex、lastRequestedPos这种其实就是JDBC认为你绝大部分情况是从前向后读取的，因此这样读取对JDBC程序也是最友好的方案，否则指针向前移动，需要从0开始，理由很简单（数据的长度不是在尾部，而是在头部），因此指针来回来回移动的时候，这样会产生很多开销，同时会产生更多的内存拷贝出来的碎片。ByteArrayRow虽然可以解决这个问题，但是其本身会占用相对较大的空间另外，其内部的二维数组返回的byte[]字节是可以被外部所修改的（因为没有拷贝）。

另外，按照这种读取数据的方式，如果单行数据过大（例如有大字段100MB+），读取到Java内存里面来，即使使用CursorFetch和Stream读取，读取几十条数据，就能把JVM内存干挂掉。到目前为止，我还没看到MySQL里面可以“设置限制单行数据长度”的参数，后续估计官方支持这类特殊需求的可能性很小，大多也只能自己改源码来实现。

【回到话题本身：MySQL和JDBC之间的通信似乎放大很小？】

其实不然，MySQL传递数据给JDBC默认是走文本协议的，而不是Binary协议，虽然说它的byte[]数组不会像JSON那样放大，并不算真正意义上的文本协议，但是它很多种数据类型默认情况下，都是文本传输，例如一个上面提到的账号：102333320132133在数据库中是8个自己，但是网络传递的时候如果有文本格式传递将会是：15个字节，如果是DateTime数据在数据库中可以用8个字节存放，但是网络传递如果按照YYYY-MM-DD HH:MI:SS传递，可以达到19个字节，而当他们用String在网络传递的时候，按照我们前面提到的，MySQL会将其当成变长字符，因此会在数据头部加上最少1个自己的标志位。另外，这里增加不仅仅是几个字节，而是你要取到真正的数据，接收方还需要进一步计算处理才能得到，例如102333320132133用文本传送后，接收方是需要将这个字符串转换为long类型才能可以得到long的，大家试想一下你处理500万数据，每一行数据有20个列，有大量的类似的处理不是开销增加了特别多呢？

JDBC和MySQL之间可以通过binary协议来进行通信的，也就是按照实际数字占用的空间大小来进行通信，但是比较坑的时，MySQL目前开启Binary协议的方案是：“开启服务端prepareStatemet”，这个一旦开启，会有一大堆的坑出来，尤其是在互联网的编程中，我会在后续的文章中逐步阐述。

抛开“开启binary协议的坑”，我们认为MySQL JDBC在通信的过程中对数据的编码还是很不错的，非常紧凑的编码（当然，如果你开启了SSL访问，那么数据又会被放大，而且加密后的数据基本很难压缩）。

对比传统的数据序列化优劣势汇总：

优势：

（1）、数据全部按照byte[]编码后，由于紧凑编码，所以对数据本身的放大很小。

（2）、由于编码和解码都没有解析的过程，都是向ByteBuffer的尾部顺序地写，也就是说不用找位置，读取的时候根据设计也可以减少找位置，即使找位置也是移动偏移量，非常高效。

（3）、如果传递多行数据，反序列化的过程不用像XML或JSON那样一次要将整个传递过来的数据全部解析后再处理，试想一下，如果5000行、20列的结果集，会产生多少Java对象，每一个Java对象对数据本身的放大又是多少，采用字节传递后可以按需转变为Java对象，使用完的Java对象可以释放，这样就不用同时占用那样大的JVM内存，而byte[]数组也只是数据本身的大小，也可以按需释放。

（4）、相对前面提到的3种方式，例如JSON，它不需要在序列化和反序列化的时候要经历一次String的转换，这样会减少一次内存拷贝。

（5）、自己写代码用类似的通信方案，可以在网络优化上做到极致。

劣势：

（1）、编码是MySQL和MySQL JDBC之间自定义的，别人没法用（我们可以参考别人的思路）

（2）、byte编码和解码过程程序员自己写，对程序员水平和严谨性要求都很高，前期需要大量的测试，后期在网络问题上考虑稍有偏差就可能出现不可预期的Bug。（所以在公司内部需要把这些内容进行封装，大部分程序员无需关注这个内容）。

（3）、从内存拷贝上来讲，从rowBuffer到应用中的数据，这一层内存拷贝是无法避免的，如果你写自定义程序，在必要的条件下，这个地方可以进一步减少内存拷贝，但无法杜绝；同上文中提到，这点开销，对于整个应用程序的业务处理来讲，简直微不足道。

为什么传统通信协议不选择这样做：

（1）、参考劣势中的3点。

（2）、传统API通信，我们更讲究快速、通用，也就是会经常和不同团队乃至不同公司调试代码，要设计binary协议，开发成本和调试成本非常高。

（3）、可读性，对于业务代码来讲，byte[]的可读性较差，尤其是对象嵌套的时候，byte[]表达的方式是很复杂的。

MySQL JDBC如果用binary协议后，数据的紧凑性是不是达到极致了呢？

按照一般的理解，就是达到极致了，所有数据都不会进一步放大，int就只用4个字节传递，long就只用8个字节传递，那么还能继续变小，难道压缩来做？

非也、非也，在二进制的世界里，如果你探究细节，还有更多比较神奇的东西，下面我们来探讨一下：

例如：

long id = 1L;

此时网络传递的时候会使用8个字节来方，大家可以看下8个字节的排布：

我们先不考虑按照bit有31个bit是0，先按照字节来看有7个0，代表字节没有数据，只有1个字节是有值的，大家可以去看一下自己的数据库中大量的自动增长列，在id小于4194303之前，前面5个字节是浪费掉的，在增长到4个字节（2的32次方-1）之前前面4个自己都是0，浪费掉的。另外，即使8个字节中的第一个字节开始使用，也会有大量的数据，中间字节是为：0的概率极高，就像十进制中进入1亿，那么1亿下面最多会有8个0，越高位的0约难补充上去。

如果真的想去尝试，可以用这个办法：用1个字节来做标志，但会占用一定的计算开销，所以是否为了这个空间去做这个事情，由你决定，本文仅仅是技术性探讨：

方法1：表达目前有几个低位被使用的字节数，由于long只有8个字节，所以用3个bit就够了，另外5个bit是浪费掉的，也无所谓了，反序列化的时候按照高位数量补充0x00即可。

方法2：相对方法1，更彻底，但处理起来更复杂，用1这个字节的8个bit的0、1分别代表long的8个字节是被使用，序列化和反序列化过程根据标志位和数据本身进行字节补0x00操作，补充完整8个字节就是long的值了，最坏情况是9个字节代表long，最佳情况0是1个字节，字节中只占用了2个字节的时候，即使数据变得相当大，也会有大量的数据的字节存在空位的情况，在这些情况下，就通常可以用少于8个字节的情况来表达，要用满7个字节才能够与原数字long的占用空间一样，此时的数据已经是比2的48次方-1更大的数据了。

【三、Google Protocol Buffer技术方案】：

这个对于很多人来讲未必用过，也不知道它是用来干什么的，不过我不得不说，它是目前数据序列化和反序列化的一个神器，这个东西是在谷歌内部为了约定好自己内部的数据通信设计出来的，大家都知道谷歌的全球网络非常牛逼，那么自然在数据传输方面做得那是相当极致，在这里我会讲解下它的原理，就本身其使用请大家查阅其它人的博客，本文篇幅所限没法step by step进行讲解。

看到这个名字，应该知道是协议Buffer，或者是协议编码，其目的和上文中提到的用JSON、XML用来进行RPC调用类似，就是系统之间传递消息或调用API。但是谷歌一方面为了达到类似于XML、JSON的可读性和跨语言的通用性，另一方面又希望达到较高的序列化和反序列化性能，数据放大能够进行控制，所以它又希望有一种比底层编码更容易使用，而又可以使用底层编码的方式，又具备文档的可读性能力。

它首先需要定义一个格式文件，如下：

syntax = "proto2";

package com.xxx.proto.buffer.test;

message TestData2 {
   optional int32 id = 2;
   optional int64 longId = 1;
   optional bool  boolValue = 3;
   optional string name = 4;
   optional bytes bytesValue = 5;
   optional int32 id2 = 6;
}

这个文件不是Java文件，也不是C文件，和语言无关，通常把它的后缀命名为proto（文件中1、2、3数字代表序列化的顺序，反序列化也会按照这个顺序来做），然后本地安装了protobuf后（不同OS安装方式不同，在官方有下载和说明），会产生一个protoc运行文件，将其加入环境变量后，运行命令指定一个目标目录:

protoc --java_out=~/temp/ TestData2.proto

此时会在指定的目录下，产生package所描述的目录，在其目录内部有1个Java源文件（其它语言的会产生其它语言），这部分代码是谷歌帮你生成的，你自己写的话太费劲，所以谷歌就帮你干了；本地的Java project里面要引入protobuf包，maven引用（版本自行选择）：

<dependency>

     <groupId>com.google.protobuf</groupId>

    <artifactId>protobuf-java</artifactId>

    <version>3.6.1</version>