又到周末了，周更选手申請出站~

這次分享一下上個月碰到的離奇的問題。一個簡單的問題，硬是因為異常被悄咪咪吃掉，過關難度直線提升，導致小黑哥排查一個晚上。

這個美好的晚上，本想着開兩把 LOL 無限火力，在召喚師峽谷來個五殺的~

哎，就這樣沒了啊！我知道，你們一定能理解這種五殺被搶的感覺~

下次，真的，誰再讓我看到悄咪咪的吃掉異常，我真的要上去一 Jio 了！

好了，本文可不是水文，看完本篇文章，你可以學到以下知識點：

• Arthas 排查技巧
• 啥是 NoClassDefFoundError
• Dubbo 異常內部處理方式

好了，同學們，打開小本子，準備記好知識點~

先贊后看養成習慣，微信搜索「程序通事」，關注就完事了

起因

我們有個業務系統，應用之間調用鏈如下所示：

A 應用是業務發生起始應用，在這個應用中將會根據一定規則選擇最後的通訊渠道 C，然後將這個渠道標識傳遞給 B 應用。

B 應用的功能類似網關，這個應用將會根據 A 應用傳遞過來的渠道標識，將會請求路由下發到具體的 C 應用，起到服務路由的功能。

C 應用是與外部應用交互的應用，我們將其稱為渠道通訊機。

假設一次業務中，A 應用根據規則選擇 C2 的渠道標識，然後傳遞給 B 應用。B 應用根據這個標識選擇使用 C2 進行通訊，最後 C2 調用外部應用完成一次業務調用。

上述所有應用都基於 Dubbo 進行遠程通訊，B 應用實現原理在小黑哥之前文章「支付路由系統演進史」中有寫過，感興趣的同學可以查看一下。

介紹完業務的基本情況，現在我們來看下到底發生了啥事。

一次業務需求中，需要改動 C2 應用，這次改動功能點真的很小，很快就完成了。小黑哥想着閑着也是閑着，於是就把之前 C2 應用中打印的日誌中一些沒有脫敏的信息，進行脫敏處理。

由於之前日誌框架脫敏處理存在一些問題，於是就將日誌框架從 Log4j 升級為 LogBack。升級之後，為了防止不同日誌框架中之間的產生衝突，於是使用 IDEA Maven Helper 插件，統一將應用中所有的 Log4j 相關依賴都給排除了。

改動完成之後，將 C2 應用發布到測試環境，再次從 A 應用發起測試， B 應用返回異常提示未找到 C2 應用。

B 應用業務代碼類似如下：

public Response pay(Request req) {
    
    try {
        if (!isSupport(req.getChnlCode())) {
            return new Response("ERROR", "未找到相關渠道應用");
        }
        return doPay(req);
    } catch (Exception e) {
        return new Response("ERROR", "未找到相關渠道應用");
    }
}

正常情況下，若是配置存在問題，B 應用將會返回未找到具體渠道，請求也會在 B 應用結束，不會調用到 C2 應用（也沒辦法調用）。

然而此次配置什麼都沒問題， 而且最詭異的是 C2 應用居然收到了請求，並且成功處理了業務請求。

排查問題

由於 B 應用異常處理時，將異常吃掉了，我們沒辦法得知這個過程到底發生了啥事，所以第一要緊的事獲取異常信息。

最簡單的辦法就是，將 B 應用改造一下，加入打印異常日誌。不過當時比較懶，不想改造應用，就想獲取異常信息，於是想到使用 Arthas。

Arthas 排錯技巧

Arthas 是Alibaba開源的Java診斷工具，這裏就不再詳細介紹這個工具，主要講下這次排錯用到的命令-watch。

watch 命令可以方便觀察指定方的調用情況，可以具體觀察方法的返回值、拋出異常、入參，另外還可以通過 OGNL表達式查看對應的變量。

這裏我們主要為了查看方法拋出的異常信息，執行命令如下：

watch com.dubbo.example.DemoService doPay -e -x 2 '{params,throwExp}'

上述命令將會在方法異常之後觀察方法的入參以及異常信息。

注意，我們需要查看 doPay 方法，而不是 pay 方法。這是因為 pay方法中我們將異常捕獲，不太可能會拋出異常哦~

異常信息如下所示：

真正引起此次錯誤的異常信息為：

java.lang.NoClassDefFoundError: Could not initialize class xx.xxx.xx.GELogger

由於此次 B 應用不存在改動，所以推測這個異常實際發生在 C2 應用，於是在 C2 應用處再次使用 Arthas watch 命令，同樣觀察到相同的錯誤信息。

NoClassDefFoundError

NoClassDefFound，從名字上我們可以推測是因為類不存在，從而引發的這個錯誤。按照這個思路，我們首先可以簡單查看一下 B 應用中是否存在 GELogger 相關類。

查看 B 應用相關依賴包，從中發現了這個類文件，這說明這個類確實存在。

在 IDEA 反編譯查看 GELogger類相關源碼，從中發現了問題。

private static Logger logger;

static {
    System.out.println("static init");
    logger = Logger.getLogger(NoClassDefFoundErrorTestService.class);
    System.out.println("Logger init success");
}

GELogger存在一個靜態代碼塊，用於初始化一個 org.apache.log4j.Logger日誌類。

然後在上面改動中，全部的 Log4j依賴都被排除了，所以這裏運行時應該會拋出另外一個找到 org.apache.log4j.Logger 錯誤。

執行以下代碼，模擬拋錯過程。

System.out.println("模擬第一次 Error");
try {
    NoClassDefFoundErrorTestService noClassDefFoundErrorTestService=new NoClassDefFoundErrorTestService();
} catch (Throwable e) {
    e.printStackTrace();
}
System.out.println("模擬第二次 Error");
try {
    NoClassDefFoundErrorTestService noClassDefFoundErrorTestService=new NoClassDefFoundErrorTestService();
} catch (Throwable e) {
    e.printStackTrace();
}

異常信息如下所示：

第一次創建 NoClassDefFoundErrorTestService實例時，Java 虛擬機讀取加載時，將會初始化靜態代碼塊時。由於 org.apache.log4j.Logger類不存在，靜態代碼塊執行異常，從而導致類加載失敗。

第二次再創建 NoClassDefFoundErrorTestService 實例時，Java 虛擬機不會再次讀取加載，所以直接返回了以下異常。

java.lang.NoClassDefFoundError: Could not initialize class com.dubbo.example.NoClassDefFoundErrorTestService

找到問題真正原因，解決辦法也很簡單，直接排除 GELogger 所在依賴包。

Dubbo 內部異常處理

雖然問題到此解決了，但是這裏還有一個疑問，為何 C2 應用發生了異常，卻沒有相關錯誤日誌，並且 C2 業務邏輯也正常處理完成。

這就要說到 Dubbo 內部異常錯誤處理方式，上面 GELogger 其實作用在一個 Dubbo 自定義 Filter 中，用來記錄結果，模擬代碼如下：

@Activate(
        group = {"provider", "consumer"}
)
public class ErrorFilter implements Filter {


    @Override
    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {

        Result result = invoker.invoke(invocation);
        NoClassDefFoundErrorTestService noClassDefFoundErrorTestService=new NoClassDefFoundErrorTestService();
        // 處理業務邏輯
        return result;
    }
}

這個自定義 Filter 中首先執行 invoker 方法，這個方法將會調用真正的業務方法，這就是為什麼 C2 應用邏輯是正常處理完成。

業務方法處理完成之後，然後執行後續邏輯。由於 NoClassDefFoundErrorTestService將會拋出 Error，最終這個 Error，將會在 HeaderExchangeHandler#handleRequest 被捕獲，然後將會把相關異常信息返回給調用 Dubbo 消費者。

而在 Dubbo 消費者接受到服務提供者返回信息之後，將會在 DefaultFuture#doReceived轉化成 RemotingException。

而 RemotingException 最終將會在 FailoverClusterInvoker#doInvoke 轉換成 RpcException返回給業務代碼。

總結

好了，說了這麼多，總結一下本文知識點

1. 異常捕獲之後，一定要記得打印日誌，並且要記得輸出堆棧信息。
2. 運行時類不存在，將會導致 NoClassDefFoundError，類加載過程失敗，也會導致 NoClassDefFoundError。
3. 對外提供的二方包，最好不要依賴特定日誌框架，如 Log4j,Logback 等，應該使用 Slf4j 框架。

幫助

1、當Dubbo遇上Arthas：排查問題的實踐

2、java.lang.NoClassDefFoundError 的解決方法一例

3、noclassdeffounderror-could-not-initialize-class-error

歡迎關注我的公眾號：程序通事，獲得日常乾貨推送。如果您對我的專題內容感興趣，也可以關注我的博客：studyidea.cn

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?

※超省錢租車方案

一、回顧Stream管道流操作

通過前面章節的學習，我們應該明白了Stream管道流的基本操作。我們來回顧一下：

• 源操作：可以將數組、集合類、行文本文件轉換成管道流Stream進行數據處理
• 中間操作：對Stream流中的數據進行處理，比如：過濾、數據轉換等等
• 終端操作：作用就是將Stream管道流轉換為其他的數據類型。這部分我們還沒有講，我們後面章節再介紹。

看下面的腦圖，可以有更清晰的理解：

二、中間操作：有狀態與無狀態

其實在程序員編程中，經常會接觸到“有狀態”，“無狀態”，絕大部分的人都比較蒙。而且在不同的場景下，“狀態”這個詞的含義似乎有所不同。但是“萬變不離其宗”，理解“狀態”這個詞在編程領域的含義，筆者教給大家幾個關鍵點：

• 狀態通常代表公用數據，有狀態就是有“公用數據”
• 因為有公用的數據，狀態通常需要額外的存儲。
• 狀態通常被多人、多用戶、多線程、多次操作，這就涉及到狀態的管理及變更操作。

是不是更蒙了？舉個例子，你就明白了

• web開發session就是一種狀態，訪問者的多次請求關聯同一個session，這個session需要存儲到內存或者redis。多次請求使用同一個公用的session，這個session就是狀態數據。
• vue的vuex的store就是一種狀態，首先它是多組件公用的，其次是不同的組件都可以修改它，最後它需要獨立於組件單獨存儲。所以store就是一種狀態。

回到我們的Stream管道流

• filter與map操作，不需要管道流的前面後面元素相關，所以不需要額外的記錄元素之間的關係。輸入一個元素，獲得一個結果。
• sorted是排序操作、distinct是去重操作。像這種操作都是和別的元素相關的操作，我自己無法完成整體操作。就像班級點名就是無狀態的，喊到你你就答到就可以了。如果是班級同學按大小個排序，那就不是你自己的事了，你得和周圍的同學比一下身高並記住，你記住的這個身高比較結果就是一種“狀態”。所以這種操作就是有狀態操作。

三、Limit與Skip管道數據截取

List<String> limitN = Stream.of("Monkey", "Lion", "Giraffe", "Lemur")
        .limit(2)
        .collect(Collectors.toList());
List<String> skipN = Stream.of("Monkey", "Lion", "Giraffe", "Lemur")
        .skip(2)
        .collect(Collectors.toList());

• limt方法傳入一個整數n，用於截取管道中的前n個元素。經過管道處理之後的數據是：[Monkey, Lion]。
• skip方法與limit方法的使用相反，用於跳過前n個元素，截取從n到末尾的元素。經過管道處理之後的數據是： [Giraffe, Lemur]

四、Distinct元素去重

我們還可以使用distinct方法對管道中的元素去重，涉及到去重就一定涉及到元素之間的比較，distinct方法時調用Object的equals方法進行對象的比較的，如果你有自己的比較規則，可以重寫equals方法。

List<String> uniqueAnimals = Stream.of("Monkey", "Lion", "Giraffe", "Lemur", "Lion")
        .distinct()
        .collect(Collectors.toList());

上面代碼去重之後的結果是： [“Monkey”, “Lion”, “Giraffe”, “Lemur”]

五、Sorted排序

默認的情況下，sorted是按照字母的自然順序進行排序。如下代碼的排序結果是：[Giraffe, Lemur, Lion, Monkey]，字數按順序G在L前面，L在M前面。第一位無法區分順序，就比較第二位字母。

List<String> alphabeticOrder = Stream.of("Monkey", "Lion", "Giraffe", "Lemur")
        .sorted()
        .collect(Collectors.toList());

排序我們後面還會給大家詳細的講一講，所以這裏暫時只做一個了解。

六、串行、并行與順序

通常情況下，有狀態和無狀態操作不需要我們去關心。除非？：你使用了并行操作。

還是用班級按身高排隊為例：班級有一個人負責排序，這個排序結果最後就會是正確的。那如果有2個、3個人負責按大小個排隊呢？最後可能就亂套了。一個人只能保證自己排序的人的順序，他無法保證其他人的排隊順序。

• 串行的好處是可以保證順序，但是通常情況下處理速度慢一些
• 并行的好處是對於元素的處理速度快一些（通常情況下），但是順序無法保證。這可能會導致進行一些有狀態操作的時候，最後得到的不是你想要的結果。

Stream.of("Monkey", "Lion", "Giraffe", "Lemur", "Lion")
        .parallel()
        .forEach(System.out::println);

• parallel()函數表示對管道中的元素進行并行處理，而不是串行處理。但是這樣就有可能導致管道流中後面的元素先處理，前面的元素后處理，也就是元素的順序無法保證。

如果數據量比較小的情況下，不太能觀察到，數據量大的話，就能觀察到數據順序是無法保證的。

Monkey
Lion
Lemur
Giraffe
Lion

通常情況下，parallel()能夠很好的利用CPU的多核處理器，達到更好的執行效率和性能，建議使用。但是有些特殊的情況下，parallel並不適合：深入了解請看這篇文章：
https://blog.oio.de/2016/01/22/parallel-stream-processing-in-java-8-performance-of-sequential-vs-parallel-stream-processing/
該文章中幾個觀點，說明并行操作的適用場景：

• 數據源易拆分：從處理性能的角度，parallel()更適合處理ArrayList，而不是LinkedList。因為ArrayList從數據結構上講是基於數組的，可以根據索引很容易的拆分為多個。

• 適用於無狀態操作：每個元素的計算都不得依賴或影響任何其他元素的計算，的運算場景。
• 基礎數據源無變化：從文本文件裏面邊讀邊處理的場景，不適合parallel()并行處理。parallel()一開始就容量固定的集合，這樣能夠平均的拆分、同步處理。

歡迎關注我的博客，裏面有很多精品合集

• 本文轉載註明出處（必須帶連接，不能只轉文字）：字母哥博客。

覺得對您有幫助的話，幫我點贊、分享！您的支持是我不竭的創作動力！ 。另外，筆者最近一段時間輸出了如下的精品內容，期待您的關注。

• 《手摸手教你學Spring Boot2.0》
• 《Spring Security-JWT-OAuth2一本通》
• 《實戰前後端分離RBAC權限管理系統》
• 《實戰SpringCloud微服務從青銅到王者》
• 《VUE深入淺出系列》

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計最專業,超強功能平台可客製化

作者：HelloGitHub-小魚乾

摘要：如何優雅地誇一個程序員呢？vscode-rainbow-fart 作為一個彩虹屁的項目，深得程序員心，能在你編程時瘋狂稱讚你的除了你自己，還有它。除了鼓勵之外，Super Linte 是官方出品的旨在保證代碼和文檔一致性的工具，有了它，你可以更優雅地進行編程。說完優雅編程，來說下優雅使用 k8s，那就不得不提 Lens，一個專業管理 k8s 工具。

以下內容摘錄自微博@HelloGitHub 的 GitHub Trending，選項標準：新發布 | 實用 | 有趣，根據項目 release 時間分類，發布時間不超過 7 day 的項目會標註 New，無該標誌則說明項目 release 超過一周。由於本文篇幅有限，還有部分項目未能在本文展示，望周知

• 本文目錄
  • 1. 本周特推
    • 1.1 GitHub 官方出品：super-linter
    • 1.2 彩虹屁 VSCode 插件：vscode-rainbow-fart
  • 1. GitHub Trending 周榜
    • 2.1 Python 實用編程：practical-python
    • 2.2 有碼變高清：pulse
    • 2.3 刷題模版：algorithm-pattern
    • 2.4 一分鐘一個小 case：python-small-examples
    • 2.5 專業管理 k8s：lens
    • 2.6 益智遊戲：shapez
    • 2.7 數據科學：GoPlus
  • 1. 本周 GitHub Trending #量化投資# 主題的主力軍
    • 3.1 量化交易框架：vnpy
    • 3.2 量化交易組件：easytrader
    • 3.3 30 天掌握量化交易：stock
  • 1. 推薦閱讀

1. 本周特推

1.1 GitHub 官方出品：super-linter

本周 star 增長數：3100+

GitHub Super Linter 是由 GitHub Services DevOps 工程團隊開源的提供給 Action 調用的存儲庫，目的是保持我們文檔和代碼的一致性，同時提升整個公司之間的交流和協作的效率。特性包括：

• 防止將損壞的代碼上傳到主分支；
• 幫助建立多種語言的編碼最佳實踐；
• 制訂代碼布局和格式的指南；
• 自動化流程以幫助簡化代碼審查；

GitHub 地址→https://github.com/github/super-linter/

1.2 彩虹屁 VSCode 插件：vscode-rainbow-fart

本周 star 增長數：1800+

Newvscode-rainbow-fart 是一個彩虹屁 VSCode 插件，在你編程時瘋狂稱讚你，可以根據代碼關鍵字播放貼近代碼意義的真人語音，誇你寫代碼牛逼。

GitHub 地址→https://github.com/SaekiRaku/vscode-rainbow-fart

2. GitHub Trending 周榜

2.1 Python 實用編程：practical-python

本周 star 增長數：1850+

practical-python 是一個從事 Python 編程近三十年的工程師出的 Python 核心課程，它需要你 3、4 天的學習時間，大約 25-35 小時的時間，包括 130 多個項目實踐。

GitHub 地址→https://github.com/dabeaz-course/practical-python

2.2 有碼變高清：pulse

本周 star 增長數：1500+

Newpulse 是一個可以將馬賽克圖片百年變成高清圖的工具，近日由杜克大學（Duke University）研究團隊開發了。作為一款 AI 修圖黑科技 PULSE，可以解決所有低像素煩惱。據說它能夠將圖像原始分辨率放大 64 倍，任何渣畫質都可以秒變高清、逼真圖像，甚至被打了馬賽克的人臉圖像，毛孔、皺紋，頭髮也都能被清晰還原。

GitHub 地址→https://github.com/adamian98/pulse

2.3 刷題模版：algorithm-pattern

本周 star 增長數：2800+

Newalgorithm-pattern 是項目作者找工作時，從 0 開始刷 LeetCode 的心得記錄，通過各種刷題文章、專欄、視頻等總結的一套自己的刷題模板。

GitHub 地址→https://github.com/greyireland/algorithm-pattern

2.4 一分鐘一個小 case：python-small-examples

本周 star 增長數：10900+

python-small-examples 是一個告別枯燥，60 秒學會一個 Python 小例子的項目，目前庫已有 223 個實用的小例子 。

GitHub 地址→https://github.com/jackzhenguo/python-small-examples

2.5 專業管理 k8s：lens

本周 star 增長數：800+

Len 是一個開源、免費可用的 IDE，可方便管理 Kubernetes 的工具。

GitHub 地址→https://github.com/lensapp/lens

2.6 益智遊戲：shapez.io

本周 star 增長數：600+

shapez.io 是一個受 Factorio 啟發的搭建遊戲。你要做的事情就是簡單地通過切割，旋轉，合併和繪製形狀的零件來產生形狀。

GitHub 地址→https://github.com/tobspr/shapez.io

2.7 數據科學：GoPlus

本周 star 增長數：1800+

NewGoPlus 是數據科學的 Go+ 語言。

GitHub 地址→https://github.com/qiniu/goplus

3. 本周 GitHub Trending #投資量化#主題的主力軍

在本期主題模塊，小魚乾這裏選取了 3 個和量化相關的小工具，希望能增加你的收入，養肥你的錢包。

3.1 量化交易框架：vnpy

vn.py 是一套基於 Python 的開源量化交易系統開發框架。

GitHub 地址→https://github.com/vnpy/vnpy

3.2 量化交易組件：easytrader

easytrader 是一個提供同花順客戶端/國金/華泰客戶端/雪球的基金、股票自動程序化交易以及自動打新，支持跟蹤 joinquant /ricequant 模擬交易和實盤雪球組合的量化交易組件。特性：

• 進行自動的程序化股票交易
• 支持跟蹤 joinquant, ricequant 的模擬交易
• 支持跟蹤雪球組合調倉
• 支持通用的同花順客戶端模擬操作
• 實現自動登錄
• 支持通過 webserver 遠程操作客戶端
• 支持命令行調用，方便其他語言適配
• 基於 Python 3.6, Win。注: Linux 僅支持雪球

GitHub 地址→https://github.com/shidenggui/easytrader

3.3 30 天掌握量化交易：stock

stock 是作者作為業餘投機者（韭菜）一枚，自學量化交易，把經歷寫成代碼推送到 GitHub 的項目。

GitHub 地址→https://github.com/Rockyzsu/stock

推薦閱讀

• GitHub 熱點速覽 Vol.24：程序員自我增值，優雅賺零花錢
• GitHub 熱點速覽 Vol.23：前後端最佳實踐
• GitHub 熱點速覽 Vol.22：如何打造超級技術棧

以上為 2020 年第 23 個工作周的 GitHub Trending 如果你 Pick 其他好玩、實用的 GitHub 項目，記得來 HelloGitHub issue 區和我們分享下喲

HelloGitHub 交流群現已全面開放，添加微信號：HelloGitHub 為好友入群，可同前端、Java、Go 等各界大佬談笑風生、切磋技術~

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※南投搬家公司費用需注意的眉眉角角，別等搬了再說!

※新北清潔公司,居家、辦公、裝潢細清專業服務

※教你寫出一流的銷售文案?

在日常的網絡開發當中，協議解析都是必須的工作內容，Netty中雖然內置了基於長度、分隔符的編解碼器，但在大部分場景中我們使用的都是自定義協議，所以Netty提供了  MessageToByteEncoder<I>  與  ByteToMessageDecoder  兩個抽象類，通過繼承重寫其中的encode與decode方法實現私有協議的編解碼。這篇文章我們就對Netty中的自定義編解碼器進行實踐與分析。

一、編解碼器的使用

下面是MessageToByteEncoder與ByteToMessageDecoder使用的簡單示例，其中不涉及具體的協議編解碼。

創建一個sever端服務

EventLoopGroup bossGroup = new NioEventLoopGroup(1);
        EventLoopGroup workerGroup = new NioEventLoopGroup();
        final CodecHandler codecHandler = new CodecHandler();
        try {
            ServerBootstrap b = new ServerBootstrap();
            b.group(bossGroup, workerGroup).channel(NioServerSocketChannel.class).option(ChannelOption.SO_BACKLOG, 100)
                    .handler(new LoggingHandler(LogLevel.INFO)).childHandler(new ChannelInitializer<SocketChannel>() {
                        @Override
                        public void initChannel(SocketChannel ch) throws Exception {
                            ChannelPipeline p = ch.pipeline();
                            if (sslCtx != null) {
                                p.addLast(sslCtx.newHandler(ch.alloc()));
                            }
                            //添加編解碼handler
                            p.addLast(new MessagePacketDecoder(),new MessagePacketEncoder());
                            //添加自定義handler
                            p.addLast(codecHandler);
                        }
                    });

            // Start the server.
            ChannelFuture f = b.bind(PORT).sync();

繼承MessageToByteEncoder並重寫encode方法，實現編碼功能

public class MessagePacketEncoder extends MessageToByteEncoder<byte[]> {

    @Override
    protected void encode(ChannelHandlerContext ctx, byte[] bytes, ByteBuf out) throws Exception {
        //進行具體的編碼處理 這裏對字節數組進行打印
        System.out.println("編碼器收到數據："+BytesUtils.toHexString(bytes));
        //寫入並傳送數據
        out.writeBytes(bytes);
    }
}

繼承ByteToMessageDecoder 並重寫decode方法，實現解碼功能

public class MessagePacketDecoder extends ByteToMessageDecoder {
    @Override
    protected void decode(ChannelHandlerContext ctx, ByteBuf buffer, List<Object> out){
        try {
            if (buffer.readableBytes() > 0) {
                // 待處理的消息包
                byte[] bytesReady = new byte[buffer.readableBytes()];
                buffer.readBytes(bytesReady);
                //進行具體的解碼處理
                System.out.println("解碼器收到數據："+ByteUtils.toHexString(bytesReady));
                //這裏不做過多處理直接把收到的消息放入鏈表中，並向後傳遞
                out.add(bytesReady);
            
            }
        }catch(Exception ex) {
            
        }

    }

}

實現自定義的消息處理handler,到這裏其實你拿到的已經是編解碼后的數據

public class CodecHandler extends ChannelInboundHandlerAdapter{
    @Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) {
        System.out.println("CodecHandler收到數據："+ByteUtils.toHexString((byte[])msg));
        byte[] sendBytes = new byte[] {0x7E,0x01,0x02,0x7e};
        ctx.write(sendBytes);
    }

    @Override
    public void channelReadComplete(ChannelHandlerContext ctx) {
        ctx.flush();
    }

    @Override
    public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
        // Close the connection when an exception is raised.
        cause.printStackTrace();
        ctx.close();
    }
}

運行一個客戶端模擬發送字節0x01,0x02,看一下輸出的執行結果

解碼器收到數據：0102
CodecHandler收到數據：0102
編碼器收到數據：7E01027E

 根據輸出的結果可以看到消息的入站與出站會按照pipeline中自定義的順序傳遞，同時通過重寫encode與decode方法實現我們需要的具體協議編解碼操作。

二、源碼分析

 通過上面的例子可以看到MessageToByteEncoder<I>與ByteToMessageDecoder分別繼承了ChannelInboundHandlerAdapter與ChannelOutboundHandlerAdapter，所以它們也是channelHandler的具體實現,並在創建sever時被添加到pipeline中， 同時為了方便我們使用，netty在這兩個抽象類中內置與封裝了一些其操作；消息的出站和入站會分別觸發write與channelRead事件方法，所以上面例子中我們重寫的encode與decode方法，也都是在父類的write與channelRead方法中被調用，下面我們就別從這兩個方法入手，對整個編解碼的流程進行梳理與分析。

1、MessageToByteEncoder

編碼需要操作的是出站數據，所以在MessageToByteEncoder的write方法中會調用我們重寫的encode具體實現， 把我們內部定義的消息實體編碼為最終要發送的字節流數據發送出去。

    @Override
    public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {
        ByteBuf buf = null;
        try {
            if (acceptOutboundMessage(msg)) {//判斷傳入的msg與你定義的類型是否一致
                @SuppressWarnings("unchecked")
                I cast = (I) msg;//轉為你定義的消息類型
                buf = allocateBuffer(ctx, cast, preferDirect);//包裝成一個ByteBuf
                try {
                    encode(ctx, cast, buf);//傳入聲明的ByteBuf，執行具體編碼操作
                } finally {
                    /**
                     * 如果你定義的類型就是ByteBuf 這裏可以幫助你釋放資源，不需要在自己釋放
                     * 如果你定義的消息類型中包含ByteBuf，這裡是沒有作用，需要你自己主動釋放
                     */
                    ReferenceCountUtil.release(cast);//釋放你傳入的資源
                }

                //發送buf
                if (buf.isReadable()) {
                    ctx.write(buf, promise);
                } else {
                    buf.release();
                    ctx.write(Unpooled.EMPTY_BUFFER, promise);
                }
                buf = null;
            } else {
                //類型不一致的話，就直接發送不再執行encode方法，所以這裏要注意如果你傳遞的消息與泛型類型不一致，其實是不會執行的
                ctx.write(msg, promise);
            }
        } catch (EncoderException e) {
            throw e;
        } catch (Throwable e) {
            throw new EncoderException(e);
        } finally {
            if (buf != null) {
                buf.release();//釋放資源
            }
        }
    }

 MessageToByteEncoder的write方法要實現的功能還是比較簡單的，就是把你傳入的數據類型進行轉換和發送；這裡有兩點需要注意：

• 一般情況下，需要通過重寫encode方法把定義的泛型類型轉換為ByteBuf類型， write方法內部自動幫你執行傳遞或發送操作；
• 代碼中雖然有通過ReferenceCountUtil.release(cast)釋放你定義的類型資源，但如果定義的消息類中包含ByteBuf對象，仍需要主動釋放該對象資源；

2、ByteToMessageDecoder

從命名上就可以看出ByteToMessageDecoder解碼器的作用是把字節流數據編碼轉換為我們需要的數據格式

作為入站事件，解碼操作的入口自然是channelRead方法

 @Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
        if (msg instanceof ByteBuf) {//如果消息是bytebuff
            CodecOutputList out = CodecOutputList.newInstance();//實例化一個鏈表
            try {
                ByteBuf data = (ByteBuf) msg;
                first = cumulation == null;
                if (first) {
                    cumulation = data;
                } else {
                    cumulation = cumulator.cumulate(ctx.alloc(), cumulation, data);
                }
                callDecode(ctx, cumulation, out);//開始解碼
            } catch (DecoderException e) {
                throw e;
            } catch (Exception e) {
                throw new DecoderException(e);
            } finally {
                if (cumulation != null && !cumulation.isReadable()) {//不為空且沒有可讀數據，釋放資源
                    numReads = 0;
                    cumulation.release();
                    cumulation = null;
                } else if (++ numReads >= discardAfterReads) {
                    // We did enough reads already try to discard some bytes so we not risk to see a OOME.
                    // See https://github.com/netty/netty/issues/4275
                    numReads = 0;
                    discardSomeReadBytes();
                }

                int size = out.size();
                decodeWasNull = !out.insertSinceRecycled();
                fireChannelRead(ctx, out, size);//向下傳遞消息
                out.recycle();
            }
        } else {
            ctx.fireChannelRead(msg);
        }
    }

callDecode方法內部通過while循環的方式對ByteBuf數據進行解碼，直到其中沒有可讀數據 

    protected void callDecode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) {
        try {
            while (in.isReadable()) {//判斷ByteBuf是還有可讀數據
                int outSize = out.size();//獲取記錄鏈表大小

                if (outSize > 0) {//判斷鏈表中是否已經有數據
                    fireChannelRead(ctx, out, outSize);//如果有數據繼續向下傳遞
                    out.clear();//清空鏈表

                    // Check if this handler was removed before continuing with decoding.
                    // If it was removed, it is not safe to continue to operate on the buffer.
                    //
                    // See:
                    // - https://github.com/netty/netty/issues/4635
                    if (ctx.isRemoved()) {
                        break;
                    }
                    outSize = 0;
                }

                int oldInputLength = in.readableBytes();
                decodeRemovalReentryProtection(ctx, in, out);//開始調用decode方法

                // Check if this handler was removed before continuing the loop.
                // If it was removed, it is not safe to continue to operate on the buffer.
                //
                // See https://github.com/netty/netty/issues/1664
                if (ctx.isRemoved()) {
                    break;
                }

                //這裏如果鏈表為空且bytebuf沒有可讀數據，就跳出循環
                if (outSize == out.size()) {
                    if (oldInputLength == in.readableBytes()) {
                        break;
                    } else {//有可讀數據繼續讀取
                        continue;
                    }
                }

                if (oldInputLength == in.readableBytes()) {//beytebuf沒有讀取，但卻進行了解碼
                    throw new DecoderException(
                            StringUtil.simpleClassName(getClass()) +
                                    ".decode() did not read anything but decoded a message.");
                }

                if (isSingleDecode()) {//是否設置了每條入站數據只解碼一次，默認false
                    break;
                }
            }
        } catch (DecoderException e) {
            throw e;
        } catch (Exception cause) {
            throw new DecoderException(cause);
        }
    }

decodeRemovalReentryProtection方法內部會調用我們重寫的decode解碼實現

    final void decodeRemovalReentryProtection(ChannelHandlerContext ctx, ByteBuf in, List<Object> out)
            throws Exception {
        decodeState = STATE_CALLING_CHILD_DECODE;//標記狀態
        try {
            decode(ctx, in, out);//調用我們重寫的decode解碼實現
        } finally {
            boolean removePending = decodeState == STATE_HANDLER_REMOVED_PENDING;
            decodeState = STATE_INIT;
            if (removePending) {//這裏判斷標記，防止handlerRemoved事件與解碼操作衝突
                handlerRemoved(ctx);
            }
        }
    }

channelRead方法中接受到數據經過一系列邏輯處理，最終會調用我們重寫的decode方法實現具體的解碼功能；在decode方法中我們只需要ByteBuf類型的數據解析為我們需要的數據格式直接放入 List<Object> out鏈表中即可，ByteToMessageDecoder會自動幫你向下傳遞消息。

三、總結

通過上面的講解，我們可以對Netty中內置自定義編解碼器MessageToByteEncoder與ByteToMessageDecoder有一定的了解，其實它們本質上是Netty封裝的一組專門用於自定義編解碼的channelHandler實現類。在實際開發當中基於這兩個抽象類的實現非常具有實用性，所以在這裏稍作分析， 其中如有不足與不正確的地方還望指出與海涵。

 

關注微信公眾號，查看更多技術文章。

 

 

轉載說明：未經授權不得轉載，授權后務必註明來源（註明：來源於公眾號：架構空間， 作者：大凡）

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※想知道最厲害的網頁設計公司"嚨底家"!

※幫你省時又省力,新北清潔一流服務好口碑

※別再煩惱如何寫文案,掌握八大原則!

※產品缺大量曝光嗎?你需要的是一流包裝設計!