2. 程式人生 > >Java NIO框架Netty教程(十)

Java NIO框架Netty教程(十)

阿新 • • 發佈：2018-12-23

如果您一直關注OneCoder，我們之前有兩篇文章介紹關於Netty訊息連續收發的問題。( 《Java NIO框架Netty教程（五）- 訊息收發次數不匹配的問題 》、《 Java NIO框架Netty教程(七)-再談收發資訊次數問題 》)。如果您經常的”懷疑”和思考，我們剛介紹過了Object的傳遞，您是否好奇，在Object傳遞中是否會有這樣的問題？如果Object流的位元組截斷錯亂，那肯定是會出錯的。Netty一定不會這麼傻的，那麼Netty是怎麼做的呢？

我們先通過程式碼驗證一下是否有這樣的問題。（有問題的可能性幾乎沒有。）

/**
	 * 當繫結到服務端的時候觸發，給服務端發訊息。
	 * 
	 * @author lihzh
	 * @alia OneCoder
	 */
 

	@Override
	public void channelConnected(ChannelHandlerContext ctx, ChannelStateEvent e) {
		// 向服務端傳送Object資訊
		sendObject(e.getChannel());
	}

	/**
	 * 傳送Object
	 * 
	 * @param channel
	 * @author lihzh
	 * @alia OneCoder
	 */
	private void sendObject(Channel channel) {
		Command command = new Command
 
();
		command.setActionName("Hello action.");
		Command commandOne = new Command();
		commandOne.setActionName("Hello action. One");
		Command command2 = new Command();
		command2.setActionName("Hello action. Two");
		channel.write(command2);
		channel
 
.write(command);
		channel.write(commandOne);
	}

列印結果：

Hello action. Two Hello action. Hello action. One

一切正常。那麼Netty是怎麼分割物件流的呢？看看ObjectDecoder怎麼做的。 在ObjectDecoder的基類LengthFieldBasedFrameDecoder中註釋中有詳細的說明。我們這裡主要介紹一下關鍵的程式碼邏輯：

@Override
    protected Object decode(
            ChannelHandlerContext ctx, Channel channel, ChannelBuffer buffer) throws Exception {

        if (discardingTooLongFrame) {
            long bytesToDiscard = this.bytesToDiscard;
            int localBytesToDiscard = (int) Math.min(bytesToDiscard, buffer.readableBytes());
            buffer.skipBytes(localBytesToDiscard);
            bytesToDiscard -= localBytesToDiscard;
            this.bytesToDiscard = bytesToDiscard;
            failIfNecessary(ctx, false);
            return null;
        }

        if (buffer.readableBytes() < lengthFieldEndOffset) {
            return null;
        }

        int actualLengthFieldOffset = buffer.readerIndex() + lengthFieldOffset;
        long frameLength;
        switch (lengthFieldLength) {
        case 1:
            frameLength = buffer.getUnsignedByte(actualLengthFieldOffset);
            break;
        case 2:
            frameLength = buffer.getUnsignedShort(actualLengthFieldOffset);
            break;
        case 3:
            frameLength = buffer.getUnsignedMedium(actualLengthFieldOffset);
            break;
        case 4:
            frameLength = buffer.getUnsignedInt(actualLengthFieldOffset);
            break;
……

我們這裡進入的是4，還記得在編碼時候的開頭的4位佔位位元組嗎？跟蹤進去發現。

public int getInt(int index) {
        return  (array[index]     & 0xff) << 24 |
                (array[index + 1] & 0xff) << 16 |
                (array[index + 2] & 0xff) <<  8 |
                (array[index + 3] & 0xff) <<  0;
    }

原來，當初在編碼時，在流開頭增加的4位元組的字元是做這個的。他記錄了當前了這個物件流的長度，便於在解碼時候準確的計算出該物件流的長度，正確解碼。看來，我們如果我們自己寫的物件編碼解碼的工具，要考慮的還有很多啊。

附：LengthFieldBasedFrameDecoder的JavaDoc

/**
* A decoder that splits the received {@link ChannelBuffer}s dynamically by the
* value of the length field in the message.  It is particularly useful when you
* decode a binary message which has an integer header field that represents the
* length of the message body or the whole message.
* <p>
* {@link LengthFieldBasedFrameDecoder} has many configuration parameters so
* that it can decode any message with a length field, which is often seen in
* proprietary client-server protocols. Here are some example that will give
* you the basic idea on which option does what.
*
* <h3>2 bytes length field at offset 0, do not strip header</h3>
*
* The value of the length field in this example is <tt>12 (0x0C)</tt> which
* represents the length of "HELLO, WORLD".  By default, the decoder assumes
* that the length field represents the number of the bytes that follows the
* length field.  Therefore, it can be decoded with the simplistic parameter
* combination.
* <pre>
* <b>lengthFieldOffset</b>   = <b>0</b>
* <b>lengthFieldLength</b>   = <b>2</b>
* lengthAdjustment    = 0
* initialBytesToStrip = 0 (= do not strip header)
*
* BEFORE DECODE (14 bytes)         AFTER DECODE (14 bytes)
* +--------+----------------+      +--------+----------------+
* | Length | Actual Content |----->| Length | Actual Content |
* | 0x000C | "HELLO, WORLD" |      | 0x000C | "HELLO, WORLD" |
* +--------+----------------+      +--------+----------------+
* </pre>
*
* <h3>2 bytes length field at offset 0, strip header</h3>
*
* Because we can get the length of the content by calling
* {@link ChannelBuffer#readableBytes()}, you might want to strip the length
* field by specifying <tt>initialBytesToStrip</tt>.  In this example, we
* specified <tt>2</tt>, that is same with the length of the length field, to
* strip the first two bytes.
* <pre>
* lengthFieldOffset   = 0
* lengthFieldLength   = 2
* lengthAdjustment    = 0
* <b>initialBytesToStrip</b> = <b>2</b> (= the length of the Length field)
*
* BEFORE DECODE (14 bytes)         AFTER DECODE (12 bytes)
* +--------+----------------+      +----------------+
* | Length | Actual Content |----->| Actual Content |
* | 0x000C | "HELLO, WORLD" |      | "HELLO, WORLD" |
* +--------+----------------+      +----------------+
* </pre>
*
* <h3>2 bytes length field at offset 0, do not strip header, the length field
*     represents the length of the whole message</h3>
*
* In most cases, the length field represents the length of the message body
* only, as shown in the previous examples.  However, in some protocols, the
* length field represents the length of the whole message, including the
* message header.  In such a case, we specify a non-zero
* <tt>lengthAdjustment</tt>.  Because the length value in this example message
* is always greater than the body length by <tt>2</tt>, we specify <tt>-2</tt>
* as <tt>lengthAdjustment</tt> for compensation.
* <pre>
* lengthFieldOffset   =  0
* lengthFieldLength   =  2
* <b>lengthAdjustment</b>    = <b>-2</b> (= the length of the Length field)
* initialBytesToStrip =  0
*
* BEFORE DECODE (14 bytes)         AFTER DECODE (14 bytes)
* +--------+----------------+      +--------+----------------+
* | Length | Actual Content |----->| Length | Actual Content |
* | 0x000E | "HELLO, WORLD" |      | 0x000E | "HELLO, WORLD" |
* +--------+----------------+      +--------+----------------+
* </pre>
*
* <h3>3 bytes length field at the end of 5 bytes header, do not strip header</h3>
*
* The following message is a simple variation of the first example.  An extra
* header value is prepended to the message.  <tt>lengthAdjustment</tt> is zero
* again because the decoder always takes the length of the prepended data into
* account during frame length calculation.
* <pre>
* <b>lengthFieldOffset</b>   = <b>2</b> (= the length of Header 1)
* <b>lengthFieldLength</b>   = <b>3</b>
* lengthAdjustment    = 0
* initialBytesToStrip = 0
*
* BEFORE DECODE (17 bytes)                      AFTER DECODE (17 bytes)
* +----------+----------+----------------+      +----------+----------+----------------+
* | Header 1 |  Length  | Actual Content |----->| Header 1 |  Length  | Actual Content |
* |  0xCAFE  | 0x00000C | "HELLO, WORLD" |      |  0xCAFE  | 0x00000C | "HELLO, WORLD" |
* +----------+----------+----------------+      +----------+----------+----------------+
* </pre>
*
* <h3>3 bytes length field at the beginning of 5 bytes header, do not strip header</h3>
*
* This is an advanced example that shows the case where there is an extra
* header between the length field and the message body.  You have to specify a
* positive <tt>lengthAdjustment</tt> so that the decoder counts the extra
* header into the frame length calculation.
* <pre>
* lengthFieldOffset   = 0
* lengthFieldLength   = 3
* <b>lengthAdjustment</b>    = <b>2</b> (= the length of Header 1)
* initialBytesToStrip = 0
*
* BEFORE DECODE (17 bytes)                      AFTER DECODE (17 bytes)
* +----------+----------+----------------+      +----------+----------+----------------+
* |  Length  | Header 1 | Actual Content |----->|  Length  | Header 1 | Actual Content |
* | 0x00000C |  0xCAFE  | "HELLO, WORLD" |      | 0x00000C |  0xCAFE  | "HELLO, WORLD" |
* +----------+----------+----------------+      +----------+----------+----------------+
* </pre>
*
* <h3>2 bytes length field at offset 1 in the middle of 4 bytes header,
*     strip the first header field and the length field</h3>
*
* This is a combination of all the examples above.  There are the prepended
* header before the length field and the extra header after the length field.
* The prepended header affects the <tt>lengthFieldOffset</tt> and the extra
* header affects the <tt>lengthAdjustment</tt>.  We also specified a non-zero
* <tt>initialBytesToStrip</tt> to strip the length field and the prepended
* header from the frame.  If you don't want to strip the prepended header, you
* could specify <tt>0</tt> for <tt>initialBytesToSkip</tt>.
* <pre>
* lengthFieldOffset   = 1 (= the length of HDR1)
* lengthFieldLength   = 2
* <b>lengthAdjustment</b>    = <b>1</b> (= the length of HDR2)
* <b>initialBytesToStrip</b> = <b>3</b> (= the length of HDR1 + LEN)
*
* BEFORE DECODE (16 bytes)                       AFTER DECODE (13 bytes)
* +------+--------+------+----------------+      +------+----------------+
* | HDR1 | Length | HDR2 | Actual Content |----->| HDR2 | Actual Content |
* | 0xCA | 0x000C | 0xFE | "HELLO, WORLD" |      | 0xFE | "HELLO, WORLD" |
* +------+--------+------+----------------+      +------+----------------+
* </pre>
*
* <h3>2 bytes length field at offset 1 in the middle of 4 bytes header,
*     strip the first header field and the length field, the length field
*     represents the length of the whole message</h3>
*
* Let's give another twist to the previous example.  The only difference from
* the previous example is that the length field represents the length of the
* whole message instead of the message body, just like the third example.
* We have to count the length of HDR1 and Length into <tt>lengthAdjustment</tt>.
* Please note that we don't need to take the length of HDR2 into account
* because the length field already includes the whole header length.
* <pre>
* lengthFieldOffset   =  1
* lengthFieldLength   =  2
* <b>lengthAdjustment</b>    = <b>-3</b> (= the length of HDR1 + LEN, negative)
* <b>initialBytesToStrip</b> = <b> 3</b>
*
* BEFORE DECODE (16 bytes)                       AFTER DECODE (13 bytes)
* +------+--------+------+----------------+      +------+----------------+
* | HDR1 | Length | HDR2 | Actual Content |----->| HDR2 | Actual Content |
* | 0xCA | 0x0010 | 0xFE | "HELLO, WORLD" |      | 0xFE | "HELLO, WORLD" |
* +------+--------+------+----------------+      +------+----------------+
* </pre>
*
* @see LengthFieldPrepender
*/

相關推薦

Java NIO框架Netty教程(十六)-ServerBootStrap啟動流程源碼分析

ucc ask pip 以及 梳理 學習曲線 owa pan server 有一段事件沒有更新文章了，各種原因都有吧。搬家的瑣事，搬家後的安逸呵呵。不過，OneCoder明白，絕不能放松。對於Netty的學習，也該稍微深入一點了。 所以，這次OneCoder花了幾天時間，仔

Java NIO框架Netty教程(十六)

有一段事件沒有更新文章了，各種原因都有吧。搬家的瑣事，搬家後的安逸呵呵。不過，OneCoder明白，絕不能放鬆。對於Netty的學習，也該稍微深入一點了。 所以，這次OneCoder花了幾天時間，仔細梳理了一下Netty的原始碼，總結了一下Se

Java NIO框架Netty教程(十四)

OneCoder這個週末搬家，並且新家目前還沒有網路，本週的翻譯的任務尚未完成，下週一起補上，先上一篇OIO和NIO對比的小研究。 Netty中不光支援了Java中NIO模型，同時也提供了對OIO模型的支援。（New IO vs Old IO）

Java NIO框架Netty教程(十)

如果您一直關注OneCoder，我們之前有兩篇文章介紹關於Netty訊息連續收發的問題。( 《Java NIO框架Netty教程（五）- 訊息收發次數不匹配的問題 》、《 Java NIO框架Netty教程(七)-再談收發資訊次數問題 》)。如果

Java NIO框架Netty教程(十二)

寫在前面：對Netty併發問題的測試和解決完全超出了我的預期，想說的東西越來越多。所以才出現這個中篇，也就是說，一定會有下篇。至於問題點的發現，OneCoder也在努力驗證中。 繼續併發的問題。在《Java NIO框架Netty教程(十一)-併

Java NIO框架Netty教程(十一)

之前更新了幾篇關於JVM研究的文章，其實也是在做本篇文章驗證的時候，跑的有點遠，呵呵。迴歸Netty教程，這次要講的其實是針對一個問題的研究和驗證結論。另外，最近工作比較忙，所以可能會分文章更新一些階段性的成果，而不是全部彙總更新，以免間隔過久。

Java NIO框架Netty教程(十五)

如果您持續關注OneCoder，您可能會問，在《Java NIO框架Netty教程(十四)- Netty中OIO模型(對比NIO)》中不是說下節介紹的是，NIO和OIO中的worker處理方式嗎。這個一定會有的，只是在研究的過程中，OneCode

Java NIO框架Netty教程（十七）

最近很多人問我有沒有Netty4的Hello World樣例，很早之前知道Netty要出4，當時只知道4的包名完全邊了，因為Netty從JBoss中獨立出來了，並採用了新的netty.io的域名，但是沒想到程式碼也有這麼大的調整。 既然答應

Java NIO框架Netty教程(九) Object對象編/解碼

log writer arr num context 不兼容 是的 pat .html 看到題目，有的同學可能會想，上回不是說過對象傳遞了嗎？是的，只是在Java NIO框架Netty教程(八) Object對象傳遞中，我們只是介紹如何使用Netty提供的編/解碼工具，完成

Java NIO框架Netty教程(四) ChannelBuffer

ets 認識 buffers 不想 http 觸發 getch 我們 基於 在學字符串消息收發(http://www.it165.net/pro/html/201207/3174.html)的時候，已經提到過。ChannelBuffer是Netty中非常重要的概念。所有消息

Java NIO框架Netty教程(三) 字符串消息收發

view itl col ioc 啟動 type lines nta tty 了解了Netty的基本概念(http://www.it165.net/pro/html/201207/3173.html)，開發起來應該會順手很多。 在“Hello World(http://w

Java NIO框架Netty教程（一） – Hello Netty

tex highlight bsp ret 開發 包括 tor 習慣 事件機制 先啰嗦兩句，如果你還不知道Netty是做什麽的能做什麽。那可以先簡單的搜索了解一下。我只能說Netty是一個NIO的框架，可以用於開發分布式的Java程序。具體能做什麽，各位可以盡量發揮想象。技

Java NIO框架Netty教程（三）

瞭解了Netty的基本概念，開發起來應該會順手很多。在“Hello World”程式碼中，我們只是在完成繫結的時候，在各自的本地列印了簡單的資訊，並沒有客戶端和服務端的訊息傳遞。這個肯定是最基本的功能。在上程式碼之前，先補充一個Netty中重要的

Java NIO框架Netty教程(八)

說了這麼多廢話，才提到物件的傳輸，不知道您是不是已經不耐煩了。一個系統內部的訊息傳遞，沒有物件傳遞是不太現實的。下面就來說說，怎麼傳遞物件。 如果，您看過前面的介紹，如果您善於專注本質，勤于思考。您應該也會想到，我們說過，Netty的訊息傳遞都

Java NIO框架Netty教程（五）

週末是最好的學習時間，不過這週末收房子，可想而知事情自然也不會少。這段時間的週末，可能很少有時間學習了。見縫插針吧。 不說廢話了，好好學習。上回通過程式碼理解了Netty底層資訊的流的傳遞機制，不過只是一個感性上的認識。教會你應該如何使用和使用

Java NIO框架Netty教程（四）

Unfortunately, the buffer of a stream-based transport is not a queue of packets but a queue of bytes. It means, even if you sent two messages

Java NIO框架Netty教程（二）

“Hello World”的程式碼固然簡單，不過其中的幾個重要概念（類）和 Netty的工作原理還是需要簡單明確一下，至少知道其是負責什。方便自己以後更靈活的使用和擴充套件。 宣告，筆者一介碼農，不會那麼多專業的詞彙和縮寫，只能以最簡單蒼白的

Java NIO框架Netty教程（一）

先囉嗦兩句，如果你還不知道Netty是做什麼的能做什麼。那可以先簡單的搜尋瞭解一下。我只能說Netty是一個NIO的框架，可以用於開發分散式的Java程式。具體能做什麼，各位可以儘量發揮想象。技術，是服務於人而不是侷限住人的。 Netty的簡介

Java NIO框架Netty教程(十三)

在上節(《Java NIO框架Netty教程(十二)-併發訪問測試(中)》)，我們從各個角度對Netty併發的場景進行了測試。這節，我們將重點關注上節最後提到的問題。在多執行緒併發訪問的情況下，會出現 警告: EXCEPTION, please

Java NIO框架Netty教程(七)

經過簡單的瞭解，筆者大膽的猜測和”武斷”一下該問題的原因。 首先，Selector機制讓我們註冊一個感興趣的事件，然後只要有該事件發生，就會傳遞給接收端。我們寫了三次，接收端一定會出發三次的。 然後，Netty實現機制裡，有個Buffer