参考文献：极客时间傅健老师的《Netty源码剖析与实战》Talk is cheap.show me the code!
什么是粘包和半包
在客户端发送数据时，实际是把数据写入到了TCP发送缓存里面的。
半包：顾名思义就是接收到半个包，如果发送的包的大小比TCP发送缓存的容量大，那么这个数据包就会被分成多个包，通过socket多次发送到服务端，服务端第一次从接受缓存里面获取的数据，实际是整个包的一部分，半包不是说只收到了全包的一半，是说收到了全包的一部分。
粘包：如果发送的包的大小比TCP发送缓存容量小，并且TCP缓存可以存放多个包，那么客户端和服务端的一次通信就可能传递了多个包，这时候服务端从接受缓存就可能一下读取了多个包
举个栗子：
我们现在发送两条消息：“ABC”,“DEF”，那么对方接收到的消息不一定是这种格式的，对方可能一次性就接收到“ABCDEF”,也可能分好几次接收到“AB”，“CD”，“EF”,或者更为恶劣一次接收到了两个消息“A”，“BCDEF”。那么这样一次接收两个消息的称为粘包现象，分三次四接收到多个不完整的现象是半包现象。
粘包的主要原因：
发送方每次写入数据 < 套接字缓冲区大小，接收方读取套接字缓冲区数据不够及时。
半包的主要原因：
发送方写入数据 > 套接字缓冲区大小，还有就是发送的数据大于协议的MTU(Maximum Transmission Unit 最大传输单元)的时候必须拆包。（MTU其实就是TCP协议每层的大小）
换个角度：
收发：一个发送可能被多次接收，多次发送可能被一次接收
传输：一个发送可能占用多个传输包，多个发送可能公用一个传输包
根本原因：
TCP是流动协议，消息无边界。（UDP像邮寄的包裹，虽然一次运输多个的，但每个包裹都有“界限”，一个一个签收，所以无粘包、半包问题）
解决问题的根本手段：找出消息的边界
Netty对三种常用封帧方式的支持（三个类都继承ByteTomessageDecoder.java）
解读Netty处理粘包、半包的源码-------解码核心工作流程:
先找到ByteToMessageDecoder.java，可以看到它继承了ChannelInboundHandlerAdapter.java
这个ChannelInboundHandlerAdapter有个核心的入口方法“channelRead()”;
图中的msg就相当于我们的数据，开始就把数据转换成data,
ByteBuf data = (ByteBuf) msg;
然后判断cumulation是否为null,cumulation是数据积累器，用来积累数据。
ByteBuf cumulation;
first = cumulation == null; if (first) { cumulation = data; } else { cumulation = cumulator.cumulate(ctx.alloc(), cumulation, data); }
第一次的时候肯定为null 所以first是true，直接把data数据给了cumulation。再接下来就是解码：
callDecode(ctx, cumulation, out);
进入具体方法
参数中的in就是数据积累器中的数据，也就是我们传入的数据。往下走又这么个方法调用：
decodeRemovalReentryProtection(ctx, in, out);
需要注意的是：decode中时，不能执行完handler remove清理操作，decode完之后需要清理数据，改方法的名称长久是标识功能的。点进去可以查看
可以看出有个decodeState = STATE_CALLING_CHILD_DECODE;这个就是处理刚才remove handler 的；接下来就是“decode(ctx, in, out);”；这个decode是个抽象方法
之前说过Netty对三种封帧的支持分别是：“FixedLengthFrameDecoder”，“DelimiterBasedFrameDecoder”，“LengthFieldBasedFrameDecoder”。这里以“FixedLengthFrameDecoder”为例，所以点开FixedLengthFrameDecoder的decode();
@Override protected final void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception { Object decoded = decode(ctx, in); if (decoded != null) { out.add(decoded); } }
然后再进去查看Object decoded = decode(ctx, in);
protected Object decode( @SuppressWarnings("UnusedParameters") ChannelHandlerContext ctx, ByteBuf in) throws Exception { if (in.readableBytes() < frameLength) { return null; } else { return in.readRetainedSlice(frameLength); } }
这时候就能发现关键点，代码标粗，这个in还是数据积累器的数据，取得之后进行判断，如果小于则返回null不能解出,否则解出。这样一来就完成了一个数据解析的过程。