一、回顧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實現類。在實際開發當中基於這兩個抽象類的實現非常具有實用性，所以在這裏稍作分析， 其中如有不足與不正確的地方還望指出與海涵。

 

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

 

 

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

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

【其他文章推薦】

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

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

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

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

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

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

1. 背景說明

在開展自動化測試工作時，經常會由於一些外在原因（如網絡中斷、返回超時）導致自動化測試用例運行失敗，而這些失敗並不是用例本身驗證或被測程序存在Bug而引起的，更可氣的是這些失敗場景有可能還是偶發的，為了保證測試用例運行的穩定性和驗證有效性，我們需要一種針對失敗用例重試的運行機制。

今天給大家分享的主題：自動化測試工作中，用例腳本失敗重試機制的實現方式。

結合自動化測試框架來講，用例運行失敗重試機制，通常有三種形式來實現：

• 藉助依賴框架自身是否有用例失敗重試運行機制。

• 從用例腳本自身邏輯處入手，實現失敗運行重試。(適用於被特殊處理過的用例邏輯)

• 從擴展框架源碼，自定義失敗重試運行機制。（通常適合於所有失敗用例）

接下來，我們以Robot Framework框架為例，以具體的實戰示例項目介紹如何實現用例失敗重試機制。

2. 示例項目環境搭建

為了便於演示，重新創建一套新的虛擬隔離環境，用於搭建Robot Framework框架，操作步驟如下。

1、創建虛擬環境robotframework_env

python3 -m venv robotframework_env

2､激活虛擬環境

cd robotframework_env
source bin/activate

3、在虛擬環境中，安裝robotframework、robotframework-ride庫（安裝最新即可）。

pip install robotframework
pip install robotframework-ride

如下圖所示：

4､ 輸入命令：bin ./ride.py啟動RIDE，如下圖所示。

PS: 其它三方庫演示項目中，暫不需要，讀者可根據實際需求，自行安裝。

3. 創建實戰示例項目

1､ 創建trainning演示項目，並在項目下，創建失敗重試機制實戰目錄，並依次創建測試套件、測試用例，示例結構如下：

2､ 編寫測試用例，測試用例邏輯如下：

*** Settings ***
Library           Collections

*** Test Cases ***
Class_01_隨機取數，模擬隨機出現失敗場景
    @{list}=    create list    1    2    3
    ${random_num}=    Evaluate    random.choice(${list})    random
    log    ${random_num}
    should be true    ${random_num}==2

• 在測試用例中，先通過create list關鍵字創建了一個名稱為${list}的列表變量，並依次存入1､2､3三個元素。
• 再通過Evaluate萬能關鍵字，結合random.chocie方法，從${list}列表中隨機取出一個整型元素，保存到名稱為${random_num}變量中。
• 最後，通過should be true關鍵字，斷言${random_num}變量等於2,由於第二步的隨機取值，會讓${random_num}變量值具有隨機性（可能等於2,也可能是1或3），從而實現模擬一條隨機失敗的用例場景。

運行成功結果：

運行失敗結果：

4. 用例失敗重試機制實現

Robot Framework 官方並沒有提供類似retry等參數來配置失敗用例重執行。僅僅提供了--rerunfailed參數對基於結果文件output.xml來選擇重新執行失敗的用例。

4.1 基於RF框架自身的重試機制

1､ 以第3節中新建的示例項目為例，為了便於演示，以命令行來操作，在命令行中輸入執行用例命令，並且將輸出文件保存到original.xml文件中。

robot --output original.xml .

2､ 重新運行測試用例，並將第二次運行的結果文件輸出保存到rerun.xml文件中。

robot --output rerun.xml --rerunfailed original.xml .

3､合併兩次運行的結果輸出文件。

rebot --merge original.xml rerun.xml

在Robot Framework中除了有--rerunfailed參數針對失敗的測試用例外，也有針對測試套件的--rerunfailedsuites，參數詳細說明如下：

-R --rerunfailed output  Select failed tests from an earlier output file to be
                          re-executed. Equivalent to selecting same tests
                          individually using --test option.

------------------------------------------------
 -S --rerunfailedsuites output  Select failed suite from an earlier output file
                          to be re-executed. New in RF 3.0.1.

• -R或--rerunfailed參數非常有用，它的作用是從output file中選擇失敗的用例重跑。但是有個問題，如果上一次運行時用例全部成功，此時加上-R參數再去運行用例時會報錯： failed: All tests passed ，這導致我沒辦法在jenkins job中使用這個參數。

• -S或--rerunfailedsuites參數和-R參數的作用類似，它的作用是從output file中選擇失敗的用例套件重跑。

4.2 基於用例腳本邏輯重試機制

第二種方法，我們介紹，如何基於用例腳本邏輯特殊改造，實現用例失敗后的重試機制。

基於用例邏輯增加重試機制，核心實現思路：基於RF內置變量${TEST_STATUS}獲取用例運行結果，再結合Teardown運行改造后的關鍵字邏輯即可。

操作如下：

1､對示例1中的Class_01 測試用例進行改造，抽取用例邏輯部分，存放到單獨的關鍵字下，名稱如測試用例關鍵字。

*** Keywords ***
測試用例關鍵字
    @{list}=    create list    1    2    2
    ${random_num}=    Evaluate    random.choice(${list})    random
    log    ${random_num}
    should be true    ${random_num}==2

2､ 添加關鍵字用例重試機制，增加用例重試機制的處理邏輯：

*** Keywords ***
用例重試機制
    [Arguments]    ${times}
    ${status}=    set variable    ${TEST STATUS}
    FOR    ${index}    IN RANGE    ${times}
        log    第${index+1}運行結果: ${status}
        Exit For loop if    '${status}'=='PASS' or '${status}'=='True'
        log    第${index+1}次重試運行
        ${status}=    Run keyword And Return Status    測試用例關鍵字
    END

在用例重試機制關鍵字中，先通過${TEST STATUS}內置變量，獲取用例執行結果，並且接收變量${times}用於控制重試次數，如果用例執行狀態等於PASS則直接退出重試，否則調用Run keyword And Return Status關鍵字繼續運行測試用例。

3､為了便於演示，增加一條名稱為Class_02測試用例，內容如下：

Class_02_隨機取數，模擬隨機出現失敗場景
    測試用例關鍵字
    [Teardown]    run keyword    用例重試機制    5

到此， 我們已經在用例邏輯層面實現了用例失敗重試機制了。

PS: 針對用例邏輯層面實現重試機制，也可以採用關鍵字: Wait Until Keyword Succeeds，讀者可根據自身需求進行改造，本文的用例重試機制並不是唯一的方法。

4.3 基於框架源碼實現重試機制

除了上述兩種方法，最後一種方法是基於框架層面進行改造，增加全局重試機制，

通過改寫Robot Framework源代碼增加--retry選項，實現test級別的失敗用例自動再執行，比如用例失敗后，會重新運行N次，直至成功or 耗盡重試次數，生成的日誌和報告文件中只會體現最後一次執行的結果。

類似如下命令格式：

robot --retry 3 trainning

具體實現：

1､修改文件 : robotframework_env/lib/python3.7/site-packages/robot/run.py，在USAGE變量里添加retry參數。

 -F --extension value     Parse only files with this extension when executing
                          a directory. Has no effect when running individual
                          files or when using resource files. If more than one
                          extension is needed, separate them with a colon.
                          Examples: `--extension txt`, `--extension robot:txt`
                          New in RF 3.0.1. Starting from RF 3.2 only `*.robot`
                          files are parsed by default.
 -N --name name           Set the name of the top level suite. By default the
                          name is created based on the executed file or
                          directory.
 -H --retry retry   　　Set the retry times if test failed.

2､在run.py文件，RobotFramework類增加make方法，並在開始之前導入庫from xml.dom import minidom。

def make(self, outxml):
        xmldoc = minidom.parse(outxml)
        suiteElementList = xmldoc.getElementsByTagName('suite')
        mySuite = []
        for suiteElement in suiteElementList:
            if suiteElement.childNodes is not None:
                for element in suiteElement.childNodes:
                    if element.nodeName == 'test':
                        mySuite.append(suiteElement)
                        break
        for suite in mySuite:
            testElements = {}
            for element in suite.childNodes:
                if element.nodeName == 'test':
                    name = element.getAttribute('name')
                    if testElements.get(name) == None:
                        testElements.update({name: [element]})
                    else:
                        testElements.get(name).append(element)
            for n, el in testElements.items():
                for i in el[0:-1]:
                    textElement = i.nextSibling
                    suite.removeChild(i)
                    suite.removeChild(textElement)
        savefile = open(outxml, 'w')
        root = xmldoc.documentElement
        root.writexml(savefile)
        savefile.close()

3､RobotFramework類的main方法，加入紅色內容 self.make(settings.output)

4､ 打開robot/conf/setting.py文件，修改_cli_opts字典，增加'Retry': ('retry', 3),，如下所示：

5､打開robot/model/itemlist.py文件，修改visit方法：

    def visit(self, visitor):
        for item in self:
            if self.__module__ == 'robot.model.testcase' and hasattr(visitor, "_context"):
                testStatus = ''
                for i in range(0, int(visitor._settings._opts['Retry'])):
                    if testStatus != 'PASS':
                        if item.name in visitor._executed_tests:
                            visitor._executed_tests.pop(item.name)
                        item.visit(visitor)
                        testStatus = visitor._context.variables['${PREV_TEST_STATUS}']
                    else:
                        break
            else:
                item.visit(visitor)

6､做完如上配置之後，我們來驗證一下參數是否配置成功了，輸入robot —help查看一下配置參數項。

7､ 輸入如下命令，結合Class_01用例，驗證用例失敗重試機制:

robot --test Class_01_隨機取數，模擬隨機出現失敗場景 --retry 3 .

如果測試用例運行結果為PASS，運行一次即正常結束，如果用例運行失敗，則會重試3次執行。

5. 小結

本文以Robot Framework框架為例，介紹了在自動化測試過程中，如何實現用例腳本失敗重試機制，並且分享了三類實現思路：

• 藉助依賴框架自身是否有用例失敗重試運行機制。

• 從用例腳本自身邏輯處入手，實現失敗運行重試。(適用於被特殊處理過的用例邏輯)

• 從擴展框架源碼，自定義失敗重試運行機制。（通常適合於所有失敗用例）

認真品味本文的讀者，會發現，雖然本文內容是以Robot Framework框架為例，但其實任何自動化測試框架，要實現測試用例腳本重試機制，都繞不開本文所提到的三類實現方式思路。學會變通、靈活運用才是王道。

希望對大家在實施自動化測試工作當中有所幫助或啟發！如果覺得有用，不用以身相許，關注一下就行。

原文傳送門： 原文閱讀

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

【其他文章推薦】

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

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

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

※超省錢租車方案

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

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

中斷機制

我是CPU一號車間的阿Q，我又來了！

我們日常的工作就是不斷執行代碼指令，不過這看似簡單的工作背後其實也並不輕鬆。

咱不能悶着頭啥也不管一個勁的只管執行代碼，還得和連接在主板上的其他單位打交道。經常保持聯繫的有鍵盤、鼠標、磁盤，哦對，還有網卡，這傢伙最近把我惹到了，待會再說這事兒。

原以為內存那傢伙已經夠慢的了，沒想到跟上面這幾位通個信比他更慢，咱CPU工廠的時間一刻值千金，不能幹等着，耽誤工夫。後來廠里一合計，想了個叫中斷的辦法。

在我們車間裝了個大燈，這些單位想聯繫我們辦事兒，就先給我們發一个中斷信號，大燈就會自動亮起。我們平時工作執行代碼指令的時候，每執行一條指令就會瞅一眼看看大燈有沒有亮起來。一旦發現燈亮了，就把手頭的工作先放一邊，去處理一下。

我們記性很差的，等會處理了完了還得回來接着原來的活繼續干，為了等會回來還能接的起來，走之前得把當前執行的這個線程的各個寄存器的值，執行到哪裡了等等這些信息都保存在這個線程的棧里去。

不過有時候我們在執行非常重要的事情的時候，就不想被他們打斷。於是我們又在車間里那個eflags寄存器中設置了一個標記，如果是1我們才允許被打斷，如果是0那就算天王老子找我們也不管了。

哦不對，還有一種不可以屏蔽的中斷NMI，走得是綠色通道。不過我可不期望有這種事情發生，因為一般都沒有好事，不是電源斷電就是溫度過高，或者總線出了錯誤等這之類嚴重的事情。

8259A PIC

還有一個問題，找我們辦事兒的單位有很多，我們得要區分開來，到底是誰來消息了，而且要是他們一起來找，按什麼樣優先級順序處理，也是一件頭疼的事情。

為此，廠里單獨組建了一個全資的子公司來負責這事兒，他就是可編程中斷控制器PIC，外號8259A，其他單位想聯繫我們都得通過這個PIC，我們只需要和PIC進行對接就可以了。

我們給辦事單位都分配了一個編號，叫做中斷向量。我們還準備了一個表格叫中斷描述符表IDT，表格里記錄了很多信息，其中就有處理這个中斷號對應的函數地址。我們找PIC拿到編號后就執行處理函數就OK了。

這個表格有點大，足足有256項，咱CPU車間空間有限，放不下，就把它放在內存那傢伙那裡了，為了能快速找到這個表，專門添置了一個叫idtr的寄存器指向這個表格。

其實除了中斷，我們在執行指令的時候如果遇到了異常情況，也會去這個表裡執行異常處理函數，最常見的比如遇到了除數是0，內存地址錯誤等等情況。

這種情況下，我們必須主動放下手裡的活，去處理異常，所以我們也說異常是同步的，而中斷不知道什麼時候發生，所以是異步的。

APIC

8259A乾的挺不錯的，不過後來咱們廠擴大規模，從單核CPU變成了多核，他就有點應付不過來了。

終於有一天，廠里召開會議，把8259A給撤了，成立了一個新的全資子公司叫高級可編程中斷控制器APIC，名字就多了個高級兩個字，乾的活還是一樣的。

不過你還別說，這兩個字還真不是吹噓，比8259A不知道高到哪裡去了。

這個APIC的新公司一上台，就成立了兩個部門，一個叫I/O APIC，負責接待那些要找我們辦事兒的單位，一個叫Local APIC，以外包的形式入駐到我CPU的各個車間工作，因為就挨着我們辦公，所以取名叫Local。

I/O APIC收到中斷信號以後，根據自己的策略就分發到對應的Local APIC，咱們八個車間就可以專心處理了，為我們省了不少事兒。

不僅如此，通過這個外包團隊，我們八個車間還能向彼此發起中斷請求，我們把這個叫做處理器間中斷Inter-Processor Interrupt，簡稱IPI。

中斷親和性

每當網絡中有數據包到來，網卡那傢伙就發送一个中斷消息過來，告訴我們去處理。

不過最近不知道怎麼回事，網絡數據量激增。咱們廠里明明有8個車間，他非得一個勁的只給我們發消息，搞得我們手頭的工作老是被打斷，忙得不可開交。

終於，我忍不住了，去找網卡那傢伙理論了一番。不過他告訴我，這也不能怪他，分發給誰處理，那是APIC在負責。

想想也是，回頭我就去了APIC那裡，要求他們分攤一點給別的車間處理。

APIC表示這他們做不了主，得讓廠里來決定。

沒過幾天，廠里開了個會，參會的有各車間代表、APIC負責人，還請了操作系統那邊的相關代表過來。

會上，大家為了此事爭執不休。

二號車間虎子：“阿Q，誰叫你們一號車間是Bootstrap Processor，你們就多辛苦一點嘛”

三號車間代表：“你這話說的不合適，大家是一個Team，要互相幫助！要不這樣，既然有這麼多單位要聯繫我們，咱就分下工，比如一號車間負責網卡，二號負責磁盤，我們三號負責鍵盤，以此類推”

五號車間代表：“你想的倒是挺美哦，鍵盤一天能發多少中斷，網卡一天要發多少中斷，你凈挑輕鬆的干。這樣吧，咱就用隨機分發進行負載均衡你們覺得怎麼樣？”

八號車間代表：“隨機個啥啊，多麻煩，依我看吶咱8個車間就輪流來唄”

這時，領導問操作系統代表有沒有什麼建議。

這代表站起身來，推了推眼鏡說到：“幾位有沒有聽過線程的CPU親和性？”

大家都搖了搖頭，問到：“這是個什麼意思？”

“就是有些線程想綁定在你們之中的某一個核上面執行，不希望一會兒在這個核執行，一會兒在那個核執行”

我接過他的話：“好像是有這麼回事兒，之前有遇到過，有個線程一直被分配到我們一號車間，不過我們對這個不用關心吧，執行誰不是幹活啊，對我們都一個樣”

代表搖了搖頭，“唉，這可不一樣！你們每個核的一二級緩存都是自己在管理，要是換到別的核，這緩存多半就沒用了，又得重新來建立，這換來換去的豈不是瞎耽誤功夫嘛！對於一般的線程他們倒是不關心，但是有些線程執行大量的內存訪問和運算處理，又對性能要求很高的話，那就很在意這個問題了”

我們幾個都恍然大悟，紛紛點頭。

虎子起身問到：“那你們是如何實現這個親和性的呢？這跟我們今天的會議又有什麼關係呢？”

代表繼續回答說到：“我先回答你的第一個問題。線程調度是我們操作系統完成的工作，我們提供了API接口，線程通過調用這些接口表明自己的親和性意願，我們在調度的時候就能按照他們的意願把線程分配給你們來執行。”

代表喝了一口水接着說到：“我再回答你的第二個問題。既然線程可以有親和性，那中斷也可以按照這個思路來分發啊！APIC默認有一套分發策略，但是也提供親和性的設置，可以指定誰哪些核來處理，這樣不用把規矩定死，靈活可變，豈不更好？”

剛說完，會議室門口突然出現一年輕少年，揮手將操作系統代表喚了出去。

接下來，我們詳細討論了這種方案的可行性，最後大家一致決定，就照這麼辦，我們一起提出了一個叫中斷親和性的東西，操作系統那邊提供一個可配置的入口smp_affinity，可以通過設置各處理器核的掩碼來決定中斷交由誰來處理，APIC回去負責落地支持。

有了這套方案，再遇到網絡高峰期，咱們一號車間的壓力就有辦法緩解了。

我們剛剛達成一致，操作系統代表返回會議室，神色凝重的說到：“不好意思各位，操作系統那邊有點事情需要趕回去處理一下，先走一步了”

未完待續······

彩蛋

隨着網卡的一聲中斷，一個新的數據包來到了這片土地。

帝國網絡部新來的年輕人顯然沒有意識到危險的到來······

預知後事如何，請關注後續精彩······

往期TOP5文章

真慘！連各大編程語言都擺起地攤了！

因為一個跨域請求，我差點丟了飯碗

完了！CPU一味求快出事兒了！

哈希表哪家強？幾大編程語言吵起來了！

一個HTTP數據包的奇幻之旅

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

【其他文章推薦】

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

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

※回頭車貨運收費標準

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

※超省錢租車方案

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