1.首先对于MessageToByteEncoder 其实没啥太多亮点 他就是将我们的message转换成byte，主要的亮点还是在ByteToMessageDecoder即解码。

2.ByteToMessageDecoder是netty解码的一个抽象类，其实现了channelRead方法，而实现者只要实现其decode方法即可。

3.那ByteToMessageDecoder的channelRead方法帮我们解决了什么问题？其实就是帮我得到一个完整的数据包，假如我们传递了100个字节，可能接被底层tcp分为三个数据包发送（30，30，40）或者出现粘包情况一次性传递200字节的数据，所以我们需要一个解码器能识别一个完整的数据包即可，而MessageToByteEncoder就是做了这样的工作。

4.我们判断一个数据包是否完整有多种方式，再头部放置该数据包的具体长度，或者数据包中以特殊的标识符为记号。目前主流的是前者而且netty已经帮我们实现了---LengthFieldBasedFrameDecoder。下面我们就是是从数据整个解码流程开始谈起从ByteToMessageDecoder到--LengthFieldBasedFrameDecoder。

5.ByteToMessageDecoder的channelread的逻辑是：如果当前的对象是byteBuf则可以处理，非bytebuf的直接交给下一个handler。

6.从threadlocal获取存放每一次解码之后的结果的对象CodecOutputList，查看我们的bytebuf类型的cumulation是否为空，若为空代表这是当前这个消息的第一次解码，不为空则代表当前这个数据需要和前几次接受到的数据一起进行解码。

7.而上述合并cumulation是通过cumulator进行操作的，而cumulator有两种实现方式，一个是把所有的bytebuf积攒到一个大的bytebuf里面，第二种方式就是创建一个compositeByteBuf。前者需要内存之间拷贝后者并不需要，netty默认使用前者。

8.接下来就是调用callDecode去循环解码，这个我们稍后解析。我们先解析当callDecode执行完毕之后回去执行其finally方法，该方法主要就是先检测当前的cumulation不为空且又不能读取那么就直接释放，也会进行次数判断即当前的数据包 我们channelread读取了次数超过discardAfterReads了则 我们需要抛弃已读数据，这样能节省内存避免我们发生oom异常，但是因为该方法需要数组拷贝，所以不能常用。

9.那么会发生discardAfterReads的情况有哪些尼，试想下我们编码时候告诉我解码器 我会传送100个G给你，那么这个channelhandler得需要存储100g内容在jvm中（或者堆外内存）,如果我们得内存不够大则会抛出oom异常，所以这边做了一个优化，连续多次读取还未读取到一个完整得数据包 则丢弃一些已经read的字节 这样就可以重复写。当然discardSomeReadBytes得逻辑就是将我们已经reade的部分（并不是全部）给抛弃如果我们没有read则不抛弃。

10.我们的callDecode逻辑是：循环判断cumulation是否可读，然后判断我们的是否已经又部分解码好的内容，如果有则传递到下一个channelhandler，但是我们bytetomessage一般都是解码一个完整的数据包发送到下一个。

11.我们会先获取我们的当前的cumulation可读的字节大小，然后调用子类去进行解码（也就是我们的这边的LengthFieldBasedFrameDecoder）。

12.如果我们发现我们的cummulation子类没有读取那么我们就跳出循环，子类没有读取的原因大概率是因为这不是一个完整的数据包，具体的我们会在下面分析LengthFieldBasedFrameDecoder的时候说明

13.如果成功读取则我们会最终传递到下一个channelhandler。那么我下面就要将LengthFieldBasedFrameDecoder的解码逻辑。

14.LengthFieldBasedFrameDecoder的逻辑大致就是我们预先设定我们这个类最大能接受多少字节的内容进行解码，以及是否需要在解码初期跳过一些字节，最关键的就是lengthFieldOffset和lengthFieldLength参数，前者代表我们从这个字节中的第几个字节开始获取这个完整数据包的长度，后者代表我们标识长度的值用几个字节标识。比如lengthFieldOffset=0，lengthFieldLength=4则代表我们要从第一个字节开始获取4个字节，这四个字节的值就是整个数据包的长度。注意这个长度仅仅包含真正的数据内容的长度不好包含长度值本身的字节大小。我们知道一个字节等于8为那么4个字节就是32位。如果我们数据长度较大，那么可以设置为Long即64位。

15.每次LengthFieldBasedFrameDecoder都是将整个字节长度和解码得到的字节长度值进行比较，如果不一致则不进行解码。直到接受的数据大于我们设置的长度值，我们才开始解码并返回解码值。

16.好了说完上面我们细致的说下LengthFieldBasedFrameDecoder的解码细致流程。

17.首先判断discardingTooLongFrame是否等于true，如果是true代表netty在上一次检测到即将传递的数据大小超过我们设置的解码最大值，那么我们需要整个数据包都抛弃，而上一次只是抛弃一部分，还有剩余的需要继续抛弃。

18.然后根据failFast来判断是在抛弃所有数据完成之后就抛出异常，还是只要检测到超出就抛出异常。

19.如果discardingTooLongFrame为false ，我们接下来需要判断我们传递过来的数据的字节长度是否超过lengthFieldEndOffset，如果没有超过代表我们还无法获取即将传递过来的数据的长度，那么我们直接结束编码。

20.如果成功获取到即将要传递过来的字节长度然后再加上字节长度值本身的字节大小得到一个总的frameLength，我们拿这个frameLength分别和lengthFieldEndOffset以及maxFrameLength进行比较，前者是判断如果得到数据包的长度还小于我们的lengthFieldEndOffset，那么说明我们没有没有数据传递或者offset搞错了 ，直接抛出异常。

21.如果我们frameLength大于maxFrameLength，则该数据包会被完全抛弃掉并抛出异常。

22.如果上面都没有问题 我们再判断我们收集到的数据是否大于等于frameLength，如果小于说明不是一个完整的包。直接返回等待下次接收到剩余的数据包再进行解码。

23.最后再跳过一些initialBytesToStrip，如果还满足成功条件 则我们就进行解码，从cummlation中抽取一个完整的数据包。
---即bytebuf，然后传递到其他的channelhandler进行处理。

24.整个解码过程大致说完，netty系列即将要结束 如果有问题请留言！！