5.6 对象序列化/反序列化
1 对象序列化/反序列化简介
在实际开发中，为了简化开发，通常请求和响应都使用使用Java对象表示，对使用者屏蔽底层的协议细节。例如一些RPC框架，支持把用户定义的Java对象当做参数去请求服务端，服务端响应也是一个Java对象。
而前面我们讲解的案例都是以字符串作为请求和响应参数，实际上，Netty对于我们的自定义的Java对象作为请求响应参数也是支持的，其默认支持通过以下机制对Java对象进行序列化和反序列化：
ObjectEncoder/ObjectDecoder：使用JDK序列化机制编解码
ProtobufEncoder/ ProtobufDecoder：使用google protocol buffer进行编解码
MarshallingEncoder/MarshallingDecoder：使用JBoss Marshalling进行编解码
XmlDecoder：使用Aalto XML parser进行解码，将xml解析成Aalto XML parser中定义的Java对象，没有提供相应的编码器
JsonObjectDecoder：使用Json格式解码。当检测到匹配数量的"{" 、”}”或”[””]”时，则认为是一个完整的json对象或者json数组。这个解码器只是将包含了一个完整Json格式数据的ByteBuf实例交给之后的ChannelInbounderHandler解析，因此我们需要依赖其他的JSON框架，如Gson、jackson、fastjson等。没有提供相应的编码器。
除了Netty默认值支持的这些序列化机制，事实上还有很多的其他的序列化框架，如：hessian、Kryo、Avro、fst、msgback、thrift、protostuff等。
在实际开发中，通常我们没有必要支持上述所有的序列化框架，支持部分即可。主要的选择依据如下表：
| 选择依据 | 说明 |
| 效率 | 即序列化和反序列化的性能。这方面Kryo、Avro、fst、hessian等都不错。 |
| 序列化后的占用字节数 | 对于同一个Java对象，不同的框架序列化后占用的字节数不同。例如JDK序列化体积较大，而Kryo的体积较小。体积过大的话，会增加网络带宽压力。 |
| 是否有可视化需求 | json、xml序列化机制的结果能以文本形式展示；但是其他的框架大多是二进制的，因此可视化。 |
| 开发成本 | 一些序列化框架使用较为复杂，如thrift、protocol buffer；另外则很简单，如JDK序列化、Hessian等 |
从本教程而言，主要是为了介绍如何在Netty中使用这些序列化框架，方式类似，因此不会对每一种都进行介绍。在后续的文章中，我们将会对：JDK序列化、Hessian序列化、protocol buffer序列化进行讲解。
2 通信协议格式要求
另外一点需要注意的是，上面提到的这些序列化框架通常不能单独使用。例如发送方只是将Java对象序列化成二进制字节，对于接收方而言，则无法判断到底哪些字节可以构成一个完整的Java对象，也就无法反序列化。因此我们通常需要结合长度编码，可以使用上一节提到的LengthFieldBasedFrameDecoder/LengthFieldPrepender来协助完成。
最简单的通信协议格式如下：
+--------+----------+ | Length | Content | +--------+----------+
其中：
Length：表示Content字段占用的字节数，Length本身占用的字节数我们可以指定为一个固定的值。
Content：对象经过序列化后二进制字节内容
对于上述协议，通常我们只能选择支持一种序列化框架，如果要支持多个序列化框架，我们可以对通信协议格式稍作改造，增加一个字段来表示使用的序列化框架，如：
+--------+-------------+------------+ | Length | Serializer | Content | +--------+-------------+------------+
其中：Serializer我们可以指定使用1个字节表示，因此可以有256个值可选，我们用不同的值代表不同的框架。在编码时，选择好序列化框架后，进行序列化，并指定Serializer字段的值。在解码时，根据Serializer的值选择对应的框架进行反序列化；
在后面的章节中，让我们开启对象的序列化/反序列化之旅！
