共计 6670 个字符，预计需要花费 17 分钟才能阅读完成。
本篇内容主要讲解“常见 Serialize 技术有哪些”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让丸趣 TV 小编来带大家学习“常见 Serialize 技术有哪些”吧!
【一、常见的在 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 并不是行级别的，这种特殊情况请有兴趣的同学自行查阅源码）。
我们先不考虑按照 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
/dependency
此时生成的代码会调用这个谷歌包里面提供的方法库来做序列化动作，我们的代码只需要调用生成的这个类里面的 API 就可以做序列化和反序列化操作了，将这些生成的文件放在一个模块里面发布到 maven 仓库别人就可以引用了，关于测试代码本身，大家可以参考目前有很多博客有提供测试代码，还是很好用的。
谷歌编码比较神奇的是，你可以按照对象的方式定义传输数据的格式，可读性极高，甚至于相对 XML 和 JSON 更适合程序员阅读，也可以作为交流文档，不同语言都通用，定义的对象还是可以嵌套的，但是它序列化出来的字节比原始数据只大一点点，这尼玛太厉害了吧。
经过测试不同的数据类型，故意制造数据嵌套的层数，进行二进制数组多层嵌套，发现其数据放大的比例非常非常小，几乎可以等价于二进制传输，于是我把序列化后的数据其二进制进行了输出，发现其编码方式非常接近于上面的 JDBC，虽然有一些细节上的区别，但是非常接近，除此之外，它在序列化的时候有几大特征：
（1）、如果字段为空，它不会产生任何字节，如果整合对象的属性都为 null，产生的字节将是 0
（2）、对 int32、int64 这些数据采用了变长编码，其思路和我们上面描述有一些共通之处，就是一个 int64 值在比较小的时候用比较少的字节就可以表达了，其内部有一套字节的移位和异或算法来处理这个事情。
（3）、它对字符串、byte[] 没有做任何转换，直接放入字节数组，和二进制编码是差不多的道理。
（4）、由于字段为空它都可以不做任何字节，它的做法是有数据的地方会有一个位置编码信息，大家可以尝试通过调整数字顺序看看生成出来的 byte 是否会发生改变；那么此时它就有了很强兼容性，也就是普通的加字段是没问题的，这个对于普通的二进制编码来讲很难做到。
（5）、序列化过程没有产生 metadata 信息，也就是它不会把对象的结构写在字节里面，而是反序列化的接收方有同一个对象，就可以反解析出来了。
这与我自己写编码有何区别？
（1）、自己写编码有很多不确定性，写不好的话，数据可能放得更大，也容易出错。
（2）、google 的工程师把内部规范后，谷歌开源的产品也大量使用这样的通信协议，越来越多的业界中间件产品开始使用该方案，就连 MySQL 数据库最新版本在数据传输方面也会开始兼容 protobuf。
（3）、谷歌相当于开始在定义一个业界的新的数据传输方案，即有性能又降低代码研发的难度，也有跨语言访问的能力，所以才会有越来越多的人喜欢使用这个东西。
那么它有什么缺点呢？还真不多，它基本兼顾了很多序列化和反序列化中你需要考虑的所有的事情，达到了一种非常良好的平衡，但是硬要挑缺陷，我们就得找场景才行：
（1）、protobuf 需要双方明确数据类型，且定义的文件中每一个对象要明确数据类型，对于 Object 类型的表达没有方案，你自己必须提前预知这个 Object 到底是什么类型。
（2）、使用 repeated 可以表达数组，但是只能表达相同类型的数据，例如上面提到的 JDBC 一行数据的多个列数据类型不同的时候，要用这个表达，会比较麻烦；另外，默认情况下数组只能表达 1 维数组，要表达二维数组，需要使用对象嵌套来间接完成。
（3）、它提供的数据类型都是基本数据类型，如果不是普通类型，要自己想办法转换为普通类型进行传输，例如从 MongoDB 查处一个 Docment 对象，这个对象序列化是需要自己先通过别的方式转换为 byte[] 或 String 放进去的，而相对 XML、JSON 普通是提供了递归的功能，但是如果 protobuf 要提供这个功能，必然会面临数据放大的问题，通用和性能永远是矛盾的。
（4）、相对于自定义 byte 的话，序列化和反序列化是一次性完成，不能逐步完成，这样如果传递数组嵌套，在反序列化的时候会产生大量的 Java 对象，另外自定义 byte 的话可以进一步减少内存拷贝，不过谷歌这个相对文本协议来讲内存拷贝已经少很多了。
到此，相信大家对“常见 Serialize 技术有哪些”有了更深的了解，不妨来实际操作一番吧！这里是丸趣 TV 网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
