上一節一起學習了幾個解碼器，用於解決TCP協議網路傳輸過程中粘包和拆包的問題，用過Netty的人總會說一句話“用Netty一定要了解一下它的底層原理，這樣才敢用”，其實很有感悟，Netty in action 這本書中也有一個章節分析了codec，也定義了幾個自定義的譯碼器，但是它自定義的幾個譯碼器全部是繼承與ByteToMessageDecoder的，我們上文中的幾個解碼器例如DelimiterBasedFrameDecoder，FixedLengthFrameDecoder，LineBasedFrameDecoder這幾個全部繼承於ByteToMessageDecoder

LineBasedFrameDecoder.

FixedLengthFrameDecoder.java

DelimiterBasedFrameDecoder.java

可以看出常用的一些解碼器都是繼承於ByteToMessageDecoder，說明了這個decoder的重要性

今天我們就分析一下ByteToMessageDecoder這個類，我們並不是分析原始碼，至少現在還不是分析原始碼的時候，我個人覺得框架技術啥的，至少先會用，會用之後看原始碼事半功倍

首先，我們先看下ByteToMessageDecoder的完整宣告：

簡單的分析一下：

1）繼承了我們使用頻率最高的ChannelInboundHandlerAdapter，的確，它必須是一個handler，這樣才可以被新增到channelPipeline中處理資訊流，既然繼承與ChannelInboundHandlerAdapter，我們要看的就是channelRead這個方法

2）這是一個抽象類，抽象類和介面的區別就是它應該有抽象方法沒有實現，如下：

這個decode方法就是一個抽象方法，也就是DelimiterBasedFrameDecoder，FixedLengthFrameDecoder這些子類，具體的實現類需要實現了

簡單的看下，我們就知道我們主要看的是就是這兩個方法了

首先我們先看channelRead方法：

這是channelRead的原始碼，我們可以看出，程式碼一開始就判斷msg是不是ByteBuf，也就是為什麼我們一般把解碼器放在Channelhandler鏈的第一個的原因了，這樣做的好處就是msg一般就是ByteBuf，不會被其他的業務邏輯影響，至少這時msg的很“純潔”的。而且這個msg極有可能是directByteBuf，也就是說這是堆外記憶體的，因為我們ByteBuf在傳輸的時候堆外記憶體傳輸的時候可以少一次複製，之前的章節提及過

然後如果是第一次接收的情況下，直接接data放入到cumulation中，這個cumulation是一個全域性變數：

這樣做的好處就是cumulation相當於一個容器，在上層程式碼多次呼叫channelRead的時候，也就是當傳送端的資訊可能被接收端分多次接收的時候，這個容器儲存資訊

解析來我們接著看：

第135行主要判斷cumulation的可寫下標+當前的讀取的data的可讀容量之和是不是大於cumulation的最大容量，這樣做的就是防止cumulation的ByteBuf容量溢位，如果大於了，則說明cumulation需要擴容了

擴容的程式碼如圖展示，需要注意的就是需要將老的oldCumulation釋放掉

擴容之後，程式碼146行將新新增的data加入到cumulation中，147行再釋放data所佔用的記憶體空間，在149行就開始進行decode了，這個callDecode方法其實是對入參out進行了編輯

之所以out中的值是多個，是因為calldecode方法內部有一個迴圈，輸入的型別是ByteBuf的in變數，只要它的isReadable方法返回true，說明該ByteBuf中還有可讀的byte，可以按照使用者自定的decode方法去切分分割，將按照使用者方法切割的資訊放入入參out中就可以了

我們剛剛也說明了，decode是一個抽象方法，需要每一個具體的類去實現，給出具體的分割轉化的業務邏輯

接下來我覺得也是最最值得我學習的，就是finally這段程式碼：

不是程式碼寫的多麼精闢，只是我從來沒有在finally裡面寫過業務程式碼，最多關關資源之類的動作在裡面寫過，也就是說即使後面的資料處理發生異常或者怎麼怎樣，只要out這個list中有值，則會呼叫後續的fireChannelRead的方法

沒有去對ByteToMessageDecoder這個方法進行深入的解析，只是瞭解它的基本原理~