感謝網友【黃億華】投遞本稿。

上一篇文章我們概要介紹了Netty的原理及結構，下面幾篇文章我們開始對Netty的各個模組進行比較詳細的分析。Netty的結構最底層是buffer模組，這部分也相對獨立，我們就先從buffer講起。

What: buffer二三事

buffer中文名又叫緩衝區，按照維基百科的解釋，是”在資料傳輸時，在記憶體裡開闢的一塊臨時儲存資料的區域”。它其實是一種化同步為非同步的機制，可以解決資料傳輸的速率不對等以及不穩定的問題。

根據這個定義，我們可以知道涉及I/O(特別是I/O寫)的地方，基本會有buffer的存在。就Java來說，我們非常熟悉的Old I/O–InputStream

而NIO中則直接將buffer這個概念封裝成了物件，其中最常用的大概是ByteBuffer了。於是使用方式變為了：將資料寫入Buffer，flip()一下，然後將資料讀出來。於是，buffer的概念更加深入人心了！

Netty中的buffer也不例外。不同的是，Netty的buffer專為網路通訊而生，所以它又叫ChannelBuffer(好吧其實沒有什麼因果關係…)。我們下面就來講講Netty中的buffer。當然，關於Netty，我們必須講講它的所謂”Zero-Copy-Capable”機制。

When & Where: TCP/IP協議與buffer

TCP/IP協議是目前的主流網路協議。它是一個多層協議，最下層是物理層，最上層是應用層(HTTP協議等)，而在Java開發中，一般只接觸TCP以上，即傳輸層和應用層的內容。這就是Netty的主要應用場景。

TCP報文有個比較大的特點，就是它傳輸的時候，會先把應用層的資料項拆開成位元組，然後按照自己的傳輸需要，選擇合適數量的位元組進行傳輸。什麼叫”自己的傳輸需要”？首先TCP包有最大長度限制，那麼太大的資料項肯定是要拆開的。其次因為TCP以及下層協議會附加一些協議頭資訊，如果資料項太小，那麼可能報文大部分都是沒有價值的頭資訊，這樣傳輸是很不划算的。因此有了收集一定數量的小資料，並打包傳輸的Nagle演算法(這個東東在HTTP協議裡會很討厭，Netty裡可以用setOption(“tcpNoDelay”, true)關掉它)。

這麼說可能太抽象了一點，我們舉個例子吧：

傳送時，我們這樣分3次寫入(‘|’表示兩個buffer的分隔):

   +-----+-----+-----+
   | ABC | DEF | GHI |
   +-----+-----+-----+

接收時，可能變成了這樣:

   +----+-------+---+---+
   | AB | CDEFG | H | I |
   +----+-------+---+---+

很好懂吧？可是，說了這麼多，跟buffer有個什麼關係呢？別急，我們來看下面一部分。

Why: buffer中的分層思想

我們先回到之前的`messageReceived`方法：

    public void messageReceived(
            ChannelHandlerContext ctx, MessageEvent e) {
        // Send back the received message to the remote peer.
        transferredBytes.addAndGet(((ChannelBuffer) e.getMessage()).readableBytes());
        e.getChannel().write(e.getMessage());
    }

這裡MessageEvent.getMessage()預設的返回值是一個ChannelBuffer。我們知道，業務中需要的”Message”，其實是一條應用層級別的完整訊息，而一般的buffer工作在傳輸層，與”Message”是不能對應上的。那麼這個ChannelBuffer是什麼呢？

來一個官方給的圖，我想這個答案就很明顯了：

這裡可以看到，TCP層HTTP報文被分成了兩個ChannelBuffer，這兩個Buffer對我們上層的邏輯(HTTP處理)是沒有意義的。但是兩個ChannelBuffer被組合起來，就成為了一個有意義的HTTP報文，這個報文對應的ChannelBuffer，才是能稱之為”Message”的東西。這裡用到了一個詞”Virtual Buffer”，也就是所謂的”Zero-Copy-Capable Byte Buffer”了。是不是頓時覺得豁然開朗了？

我這裡總結一下，如果要說NIO的Buffer和Netty的ChannelBuffer最大的區別的話，就是前者僅僅是傳輸上的Buffer，而後者其實是傳輸Buffer和抽象後的邏輯Buffer的結合。延伸開來說，NIO僅僅是一個網路傳輸框架，而Netty是一個網路應用框架，包括網路以及應用的分層結構。

當然，使用ChannelBuffer表示”Message”，不失為一個比較實用的方法，但是使用一個物件來表示解碼後的Message可能更符合習慣一點。在Netty裡，MessageEvent.getMessage()是可以存放一個POJO的，這樣子抽象程度又高了一些，這個我們在以後講到ChannelPipeline的時候會說到。

How: Netty中的ChannelBuffer及實現

好了，終於來到了程式碼實現部分。之所以囉嗦了這麼多，因為我覺得，關於”Zero-Copy-Capable Rich Byte Buffer”，理解為什麼需要它，比理解它是怎麼實現的，可能要更重要一點。

關於程式碼閱讀，我想可能很多朋友跟我一樣，喜歡”順藤摸瓜”式讀程式碼–找到一個入口，然後順著檢視它的呼叫，直到理解清楚。很幸運，ChannelBuffers(注意有s!)就是這樣一根”藤”，它是所有ChannelBuffer實現類的入口，它提供了很多靜態的工具方法來建立不同的Buffer，靠“順藤摸瓜”式讀程式碼方式，大致能把各種ChannelBuffer的實現類摸個遍。先列一下ChannelBuffer相關類圖。

此外還有WrappedChannelBuffer系列也是繼承自AbstractChannelBuffer，圖放到了後面。

ChannelBuffer中的readerIndex和writerIndex

Netty中的buffer是完全重新實現的，與NIO ByteBuffer與ByteBuffer不同的是，它內部儲存了一個讀指標readerIndex和一個寫指標writerIndex，可以同時進行讀和寫，而不需要使用flip()進行讀寫切換。AbstactChannelBuffer類裡面包含了主要的讀寫邏輯，貼一段程式碼，讓大家能看的更明白一點：

public void writeByte(int value) {
setByte(writerIndex ++, value);
}

public byte readByte() {
if (readerIndex == writerIndex) {
throw new IndexOutOfBoundsException("Readable byte limit exceeded: "
+ readerIndex);
}
return getByte(readerIndex ++);
}

public int writableBytes() {
return capacity() - writerIndex;
}

public int readableBytes() {
return writerIndex - readerIndex;
}

這裡readerIndex總是小於writerIndex。我覺得這樣的方式非常自然，比單指標與flip()要更加好理解一些。AbstactChannelBuffer還有兩個相應的mark指標markedReaderIndex和markedWriterIndex，跟NIO的原理一樣，作標記用，這裡不再贅述了。

位元組序Endianness與HeapChannelBuffer

HeapChannelBuffer是最常用的Buffer，跟NIO HeapByteBuffer作用相當，其底層也是一個byte[]。

HeapChannelBuffer有兩個子類：BigEndianHeapChannelBuffer和LittleEndianHeapChannelBuffer。這裡有個很基礎的概念：位元組序(ByteOrder/Endianness)。位元組序規定了多於一個位元組的數字(int啊long什麼的)，如何在記憶體中表示。BIG_ENDIAN(大端序)表示高位在前，按照大端序，整型數12會被儲存為0 0 0 12這樣四個位元組，而LITTLE_ENDIAN則正好相反。可能搞C/C++的程式設計師對這個會比較熟悉，而Javaer則比較陌生一點，因為Java已經把記憶體給管理好了。但是在網路程式設計方面，根據協議的不同，不同的位元組序也可能會被用到。目前大部分協議還是採用大端序，可參考RFC1700。

瞭解了這些知識，我們也很容易就知道為什麼會有BigEndianHeapChannelBuffer和LittleEndianHeapChannelBuffer了。

DynamicChannelBuffer

DynamicChannelBuffer是一個很方便的Buffer，之所以叫Dynamic是因為它的長度會根據內容的長度來擴充，你可以像使用ArrayList一樣，無須關心其容量。DynamicChannelBuffer實現自動擴容的核心在於ensureWritableBytes方法，演算法很簡單：在寫入前做容量檢查，容量不夠時，新建一個容量x2的buffer，跟ArrayList的擴容是相同的。貼一段程式碼吧(為了程式碼易懂，這裡我刪掉了一些邊界檢查，只保留主邏輯)：

    public void writeByte(int value) {
        ensureWritableBytes(1);
        super.writeByte(value);
    }

    public void ensureWritableBytes(int minWritableBytes) {
        if (minWritableBytes <= writableBytes()) {
            return;
        }

        int newCapacity = capacity();
        int minNewCapacity = writerIndex() + minWritableBytes;
        while (newCapacity < minNewCapacity) {
            newCapacity <<= 1;
        }

        ChannelBuffer newBuffer = factory().getBuffer(order(), newCapacity);
        newBuffer.writeBytes(buffer, 0, writerIndex());
        buffer = newBuffer;
    }

CompositeChannelBuffer

CompositeChannelBuffer是由多個ChannelBuffer組合而成的，可以看做一個整體進行讀寫。這裡有一個技巧：CompositeChannelBuffer並不會開闢新的記憶體並直接複製所有ChannelBuffer內容，而是直接儲存了所有ChannelBuffer的引用，並在子ChannelBuffer裡進行讀寫，從而實現了”Zero-Copy-Capable”。來段簡略版的程式碼，應該更能說明其原理：

	public class CompositeChannelBuffer{

	    //components儲存所有內部ChannelBuffer
	    private ChannelBuffer[] components;
	    //indices記錄在整個CompositeChannelBuffer中，每個components的起始位置
	    private int[] indices;
	    //快取上一次讀寫的componentId
	    private int lastAccessedComponentId;

	    public byte getByte(int index) {
	        //通過indices中記錄的位置索引到對應第幾個子Buffer
	        int componentId = componentId(index);
	        return components[componentId].getByte(index - indices[componentId]);
	    }

	    public void setByte(int index, int value) {
	        int componentId = componentId(index);
	        components[componentId].setByte(index - indices[componentId], value);
	    }

	}

查詢componentId的演算法再次不作介紹了，大家自己實現起來也不會太難。值得一提的是，基於ChannelBuffer連續讀寫的特性，使用了順序查詢(而不是二分查詢)，並且用lastAccessedComponentId來進行快取。

ByteBufferBackedChannelBuffer

前面說ChannelBuffer是自己的實現的，其實只說對了一半。ByteBufferBackedChannelBuffer就是封裝了NIO ByteBuffer的類，用於實現堆外記憶體的Buffer(使用NIO的DirectByteBuffer)。當然，其實它也可以放其他的ByteBuffer的實現類。程式碼實現就不說了，也沒啥可說的。

WrappedChannelBuffer

WrappedChannelBuffer都是幾個對已有ChannelBuffer進行包裝，完成特定功能的類。程式碼不貼了，實現都比較簡單，列一下功能吧。

至此Netty 3.7的buffer部分我們基本瞭解了，相關內容還是比較簡單的，也沒有太多費腦細胞的地方。

Netty 4.0之後就不同了，ChannelBuffer改名ByteBuf，成為了單獨專案buffer，並且為了效能優化，加入了BufferPool之類的機制，已經變得比較複雜了(本質倒沒怎麼變)。效能優化是個比較複雜的事情，研究原始碼時，建議先避開這些東西，瞭解其整體結構，等到需要深入時再對演算法進行細緻研究。舉個例子，Netty4.0裡為了優化，將Map換成了Java 8裡6000行的ConcurrentHashMapV8，你們感受一下…

下篇文章我們開始講Channel。

參考資料：