Java默认提供的序列化：无法跨语言、序列化后的码流太大、序列化的性能差

XML，优点：人机可读性好，可指定元素或特性的名称。
缺点：
序列化数据只包含数据本身以及类的结构，不包括类型标识和程序集信息；
只能序列化公共属性和字段；
不能序列化方法；
文件庞大，文件格式复杂，传输占带宽。
适用场景：当做配置文件存储数据，实时数据转换。



JSON，是一种轻量级的数据交换格式，
优点：兼容性高、数据格式比较简单，易于读写、序列化后数据较小，可扩展性好，兼容性好、与XML相比，其协议比较简单，解析速度比较快。
缺点：数据的描述性比XML差、不适合性能要求为ms级别的情况、额外空间开销比较大。
适用场景（可替代ＸＭＬ）：跨防火墙访问、可调式性要求高、基于Web browser的Ajax请求、传输数据量相对小，实时性要求相对低（例如秒级别）的服务。

Fastjson，采用一种“假定有序快速匹配”的算法。
优点：接口简单易用、目前java语言中最快的json库。
缺点：过于注重快，而偏离了“标准”及功能性、代码质量不高，文档不全。
适用场景：协议交互、Web输出、Android客户端

Thrift，不仅是序列化协议，还是一个RPC框架。
优点：序列化后的体积小, 速度快、支持多种语言和丰富的数据类型、对于数据字段的增删具有较强的兼容性、支持二进制压缩编码。
缺点：使用者较少、跨防火墙访问时，不安全、不具有可读性，调试代码时相对困难、不能与其他传输层协议共同使用（例如HTTP）、
无法支持向持久层直接读写数据，即不适合做数据持久化序列化协议。
适用场景：分布式系统的RPC解决方案



Avro，Hadoop的一个子项目，解决了JSON的冗长和没有IDL的问题。
优点：支持丰富的数据类型、简单的动态语言结合功能、具有自我描述属性、提高了数据解析速度、快速可压缩的二进制数据形式、可以实现远程过程调用RPC、支持跨编程语言实现。缺点：对于习惯于静态类型语言的用户不直观。
适用场景：在Hadoop中做Hive、Pig和MapReduce的持久化数据格式。

Protobuf
将数据结构以.proto文件进行描述，通过代码生成工具可以生成对应数据结构的POJO对象和Protobuf相关的方法和属性。
优点：序列化后码流小，性能高、结构化数据存储格式（XML JSON等）、通过标识字段的顺序，可以实现协议的前向兼容、结构化的文档更容易管理和维护。
缺点：需要依赖于工具生成代码、支持的语言相对较少，官方只支持Java 、C++ 、python。
适用场景：对性能要求高的RPC调用、具有良好的跨防火墙的访问属性、适合应用层对象的持久化


其它

protostuff 基于protobuf协议，但不需要配置proto文件，直接导包即可
Jboss marshaling 可以直接序列化java类， 无须实java.io.Serializable接口
Message pack 一个高效的二进制序列化格式
Hessian 采用二进制协议的轻量级remoting onhttp工具
kryo 基于protobuf协议，只支持java语言,需要注册（Registration），然后序列化（Output），反序列化（Input）




序列化协议的选择 

颞部系统间调用，性能要求在100ms以上的服务，基于XML的SOAP协议是一个值得考虑的方案。
基于Web browser的Ajax，以及Mobile app与服务端之间的通讯，JSON协议是首选。
对于性能要求不太高，或者以动态类型语言为主，或者传输数据载荷很小的的运用场景，JSON也是非常不错的选择。
对于调试环境比较恶劣的场景，采用JSON或XML能够极大的提高调试效率，降低系统开发成本。
当对性能和简洁性有极高要求的场景，Protobuf，Thrift，Avro之间具有一定的竞争关系。
对于T级别的数据的持久化应用场景，Protobuf和Avro是首要选择。
如果持久化后的数据存储在hadoop子项目里，Avro会是更好的选择。

对于持久层非Hadoop项目，以静态类型语言为主的应用场景，Protobuf会更符合静态类型语言工程师的开发习惯。
由于Avro的设计理念偏向于动态类型语言，对于动态语言为主的应用场景，Avro是更好的选择。

如果需要提供一个完整的RPC解决方案，Thrift是一个好的选择。
如果序列化之后需要支持不同的传输层协议，或者需要跨防火墙访问的高性能场景，Protobuf可以优先考虑。
protobuf的数据类型有多种：bool、double、float、int32、int64、string、bytes、enum、message。
protobuf的限定符：
required: 必须赋值，不能为空、
optional:字段可以赋值，也可以不赋值、
repeated: 该字段可以重复任意次数（包括0次）
枚举；只能用指定的常量集中的一个值作为其值；

protobuf的基本规则：
每个消息中必须至少留有一个required类型的字段、包含0个或多个optional类型的字段；
repeated表示的字段可以包含0个或多个数据；[1,15]之内的标识号在编码的时候会占用一个字节（常用），[16,2047]之内的标识号则占用2个字节，
标识号一定不能重复、使用消息类型，也可以将消息嵌套任意多层，可用嵌套消息类型来代替组。

protobuf的消息升级原则：
不要更改任何已有的字段的数值标识；
不能移除已经存在的required字段，optional和repeated类型的字段可以被移除，但要保留标号不能被重用。
新添加的字段必须是optional或repeated。
因为旧版本程序无法读取或写入新增的required限定符的字段。

编译器为每一个消息类型生成了一个.java文件，以及一个特殊的Builder类（该类是用来创建消息类接口的）。
如：UserProto.User.Builder builder = UserProto.User.newBuilder();builder.build()；

Netty中的使用：
ProtobufVarint32FrameDecoder 是用于处理半包消息的解码类；
ProtobufDecoder(UserProto.User.getDefaultInstance())这是创建的UserProto.java文件中的解码类；
ProtobufVarint32LengthFieldPrepender 对protobuf协议的消息头上加上一个长度为32的整形字段，用于标志这个消息的长度的类；ProtobufEncoder 是编码类

将StringBuilder转换为ByteBuf类型：copiedBuffer()方法



史上最全 Java 面试题之：Netty 篇
https://www.cnblogs.com/crazymakercircle/p/13903625.html