4.1 中的新功能和值得注意的變更

此文件將帶您檢視 Netty 4.1 和 4.0 之間顯著變更和新功能的清單。

雖然我們已盡力保持與 4.0 的向下相容性，4.1 中仍然包含可能無法與 4.0 完全向下相容的多項新增功能。請務必針對新版本重新編譯您的應用程式。

重新編譯您的應用程式時，您可能會看到一些已不推薦使用的警告訊息。請務必全部修正這些警告訊息，並採用建議的替代方案，如此一來，您在升級到下一個版本時便能減少遇到的麻煩。

由於

• 行動裝置變得越來越強大，
• ADK 中的 NIO 和 SSLEngine 已修正最著名的問題，並且
• 使用者顯然想在行動應用程式中重複使用他們的編碼器和處理常式，

因此，我們決定正式支援 Android（4.0 或更高版本）。

不過，我們目前尚未針對 Android 進行自動化測試套件。如果您發現任何與 Android 相關的問題，請隨時 提出問題。也請考慮為專案做出貢獻，讓 Android 測試成為建置流程的一部分。

這兩個 Channel 和 ChannelHandlerContext 介面實作 AttributeMap 可以讓一個使用者連接一個或是多個使用者自訂屬性到它們身上。有時可能會造成使用者困惑的是 Channel 和 ChannelHandlerContext 有他們自己的儲存空間來存放使用者自訂屬性。例如，即使你放入了屬性『KEY_X』並透過 `Channel.attr(KEY_X).set(valueX)` 設定屬性值，你也永遠無法透過 `ChannelHandlerContext.attr(KEY_X).get()` 取得屬性值，反之亦然。這種行為不僅令人困惑，還會造成記憶體浪費。

為了解決這個問題，我們決定在 Channel 內部只保留一個 map。 AttributeMap 總是用 AttributeKey 當做它的 key。 AttributeKey 確保每個 key 都具有唯一性，因此每個 Channel 擁有超過一個 attribute map 沒有任何意義。只要使用者在自己的 ChannelHandler 中定義自己的 AttributeKey 為一個 private static final，就不會有重複 key 的風險。

現在我們可以有效率的檢查屬性是否存在。

在過去，要找出緩衝區洩漏發生的位置並不簡單，且洩漏警告並沒有提供太多資訊。我們現在有一個進階的洩漏回報機制，可以透過增加效能的代價來啟用。

請參閱 參考計數物件 以取得更多資訊。由於此功能的重要性，也已回傳到 4.0.14.Final。

在 4.x 中, UnpooledByteBufAllocator 是預設分配器，儘管它有它的限制。由於 PooledByteBufAllocator 已經在實務環境中使用一段時間，且我們有一個進階的緩衝區洩漏追蹤機制，現在正是讓它成為新預設分配器的時候了。

現在每個 Channel 都有一個全球唯一的 ID，由下列元素所產生

• MAC 位址 (EUI-48 or EUI-64)，最好是全球唯一的,
• 目前的處理序 ID,
• System#currentTimeMillis()
• System#nanoTime()
• 一個隨機的 32 位元整數,
• 一個遞增的 32 位元整數.

可以使用 `Channel.id()` 方法取得 Channel 的 ID。

EmbeddedChannel 中的 readInbound() 和 readOutbound() 會傳回 ad-hoc 型別參數，因此您不必向下調整其傳回值。這將大幅減少單元測試程式碼的冗餘。

EmbeddedChannel ch = ...;

// BEFORE:
FullHttpRequest req = (FullHttpRequest) ch.readInbound();

// AFTER:
FullHttpRequest req = ch.readInbound();

有些應用程式需要使用者在指定的 Executor 中執行其任務。4.x 指定 ThreadFactory 建立事件迴圈，但現在不再需要。

如需有關此變更的更多資訊，請參閱 pull request #1762。

某些型別（如 AttributeKey）對在容器環境中執行的應用程式不友善，但現在不再如此。

計算擴充 ByteBuf 的新容量的邏輯已從 AbstractByteBuf 移到 ByteBufAllocator，因為 ByteBufAllocator 更了解它管理的緩衝區的容量計算。

• 二進制 Memcache 通訊協定編解碼器
• 壓縮編解碼器
  • BZip2
  • FastLZ
  • LZ4
  • LZF
• DNS 通訊協定編解碼器
• HAProxy 通訊協定編解碼器
• MQTT 通訊協定編解碼器
• SPDY/3.1 支援
• STOMP 編解碼器
• 支援版本 4、4a 和 5 的 SOCKSx 編解碼器；請參閱 socksx 套件。
• XmlFrameDecoder，可串流 XML 文件。
• JsonObjectDecoder，可串流 JSON 物件。
• IP 篩選處理常式

AsciiString 是一種新的 CharSequence 實作，僅包含 1 個位元的字元。當您處理 US-ASCII 或 ISO-8859-1 字串時，您會發現這個類別很好用。

舉例來說，Netty 中的 HTTP 編解碼器和 STOMP 編解碼器使用 AsciiString 來表示標頭名稱。因為 AsciiString 在編碼成 ByteBuf 時沒有任何轉換成本，所以它保證效能比 String 更佳。

TextHeaders 提供一種泛用的資料結構，適用於 HTTP 標頭般的字串 多重對應。HttpHeaders 也已使用 TextHeaders 重新撰寫。

MessageAggregator 提供一種泛用的功能，可將多個較小的訊息集合成一個較大的訊息，就像 HttpObjectAggregator 所做的。HttpObjectAggregator 也已使用 MessageAggregator 重新撰寫。

在 4.0 中，即使存在 100-continue 標頭，也無法在客戶端傳送內容之前拒絕過大 HTTP 訊息。

此版本新增一個可覆寫方法，稱為 `handleOversizedMessage`，以便使用者可以執行他或她偏好的工作。預設情況下，它會回應「413 要求實體太大」的回應並關閉連線。

ChunkedInput 有兩個新方法：progress() 和 length()，分別傳回其傳輸進度和串流總長度。 ChunkedWriteHandler 使用此資訊來通知 ChannelProgressiveFutureListener。

這兩個類別已重新命名為 SnappyFrameEncoder 和 SnappyFrameDecoder。舊類別標記為不推薦使用，而它們實際上是新類別的子類別。