不用java进行序列化，大体上可以归结为以下几条。
1、无法跨措辞
比如说java编码后的数据，C++不认识，也不能解码。
2、性能低
编码解码的速率太慢。
3、码流太大
编码之后增加了很多其他的数据，霸占空间。
4、开拓难度大
对开拓职员不友好。
以上几条随便一条都是极大地缺陷，因此我们在这里先先容个中一种编码和解码的技能，叫MessagePack。为什么要利用这个呢？由于以上四条都能很好的办理，以是要用它。当然还有很多其他的精良技能，比如Protobuf等，往后用到的时候再说，我目前的项目由于是C++和java通信，因此选择了这个框架。
既然这个MessagePack这么好，下面我们就直接来看如何在Netty中利用。
二、MessagePack编解码
1、条件
在前面已经提到了，利用的是Springboot开拓的，因此我们首先添加依赖，如果你没有利用maven直接下载干系的jar包导入也可以。
其余，本实例代码在Idea中已经运行通过，而且你最好建两个moducle跑一下，客户端一个，做事端一个。
导入了jar包之后，下面我们就来看看客户端和做事真个代码。
客户端和做事端实现的功能很大略，那便是在建立连接的时候，客户端给做事端发送10个Student工具数据。
2、做事端代码
（1）定义pojo工具Student类
在这里有两点须要我们把稳：
第一点：添加@Message表明，表明可以对此进行序列化。
第二点：一定要有一个默认的布局器。在0.7的版本中听说已经修复了，不过形式上看起来有点麻烦。而且你用0.7的版本之后，上面的@Message表明不再有了。比较麻烦。还不如记住这两条，有表明和默认布局器即可。
（2）编码器MsgPackEncoder
这里面的代码很大略，只有三行，新建一个MessagePack工具，将工具o转化为byte保存在ByteBuf中。
（3）解码器MsgPackDecoder
在这里我们继续了MessageToMessageDecoder，然后重写了decode方法，在里面通过MessagePack再将缓冲区的byte转化为工具。
（4）做事端Server类
在这里面基本上全是套路代码，你直接拿来用即可，里面核心的便是try代码块。我们最关注的是下面这一部分：
我们来剖析一下这些代码：
第一个类：LengthFieldBasedFrameDecoder
参数（1）maxFrameLength：表示的是包的最大长度，超出会做一些分外处理。
参数（2）lengthFieldOffset：指定长度域的偏移量，表示跳过指定长度个字节才是长度域；
参数（3）lengthFieldLength：本数据帧的长度；
参数（4）lengthAdjustment：该字段加长度字段即是数据帧的长度，包体长度调度的大小。
参数（5）initialBytesToStrip：获取完一个完全的数据包之后，忽略前面的指定的位数个字节。
第二个类：MsgPackDecoder
这个类便是我们变动创建的解码类
第三个类：LengthFieldPrepender
客户端利用LengthFieldPrepender给数据添加报文头Length字段，接管方利用LengthFieldBasedFrameDecoder进行解码。
第四个类：MsgPackEncoder
这是我们刚刚创建的编码器类。
第五个类：ServerUAVHandler
这是我们的业务处理类，在这个类中我们处理客户真个各种事宜。
从上面五个类可以看到，LengthFieldBasedFrameDecoder和LengthFieldPrepender，可以自动屏蔽TCP底层的拆包和粘包问题，因此在这里加上，也是为理解决粘包和拆包问题。
下面看看我们的ServerUAVHandler类，着重看看我们的业务处理类
（5）handler类
这里面很大略，在channelActive方法可以处理客户真个连接要求，在channelRead里面可以读取客户端发来的数据。我们利用counter变量记录客户端发了几条数据，不过有个坑须要我们去把稳。
把稳：把稳：List<>中一定得是Object类，而不能是我们的Student。现在我们的做事端基本上就写完了，写完之后该当是这样的构造：
接下来就可以看看客户端了。
3、客户端代码
（1）定义pojo工具Student类：和做事真个Student类一样
（2）编码器MsgPackEncoder：和做事真个一样
（3）解码器MsgPackDecoder：和做事真个一样
（4）客户端client类
由于和做事器的一样，我们也已经剖析了，因此来看看里面不一样的clientHandler类实现吧。
在这里面客户端和做事端建立连接的时候就发送是个工具数据。此时做事端肯定也是会收到10个。客户端也写完了，写完之后该当是下面的构造：
4、试验验证
现在先运行做事端，再运行客户端看看输出结果。这里给出做事端。
我们会看到做事端吸收到了10调数据，而且没有粘包的征象。
对付这个MessagePack的办法和其他的框架综合比拟之后，性能也不算是最优的，但是相对付java序列化机制那就好太多了，我之前曾经写了一篇protobuf的文章，有兴趣可以在我主页看看。
现在我们不仅可以办理粘包拆包的问题，而且也能处理编解码的问题，一个新问题又随之出来了，做事端给客户端主动推送该怎么办呢？这时候传统的HTTP协议，显然已经不能知足我们的需求。缺陷太多了。于是有一个新的技能随之而生，叫做websocket，下一篇再阐述。感谢支持。
