記一個(gè)錯(cuò)誤使用 Netty ByteToMessageDecoder 的方式

0. 錯(cuò)誤示范

最近在優(yōu)化一個(gè)基于 Netty 實(shí)現(xiàn)的 proxy，為了消除消息序列化的成本，在解碼完成后用了 in.retainedSlice 保存原始數(shù)據(jù)，發(fā)送的時(shí)候直接 write 即可。

解碼模塊是基于 ByteToMessageDecoder 實(shí)現(xiàn)的，轉(zhuǎn)發(fā)的協(xié)議是 redis 協(xié)議，本來(lái)是個(gè)很好的想法，結(jié)果想當(dāng)然的用錯(cuò)了API，下面是簡(jiǎn)化的代碼。

public class NavieDecoderDemo extends ByteToMessageDecoder {

    private int startIndex;
    private int endIndex;

    @Override
    protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
        if (status == WAIT_FOR_REQUEST) {
            processRequest(in);
        } else if (status == WAIT_FOR_FIELD) {
            processField(in);
        } else if (status == WAIT_FOR_CONTENT) {
            if (processContent(in)){
                ByteBuf origin = in.retainedSlice(startIndex, endIndex - startIndex);
                request.setOrigin(origin);
                out.add(request);
                request = null;
            }
        }
    }

    public Object processRequest(ByteBuf buffer) {
        startIndex = buffer.readerIndex();
        ...
    }

    public boolean processContent(ByteBuf buffer) {
        ...
        if (request.getFieldIndex() == request.getFieldNum()) {
            endIndex = buffer.readerIndex();
            status = WAIT_FOR_REQUEST;
            return true;
        }
        status = WAIT_FOR_FIELD;
        return false;
    }
}

開(kāi)始解碼的時(shí)候?qū)⒆x索引記錄在 startIndex 中，解碼出一條完成的 redis 命令后再將當(dāng)前的讀索引記錄在 endIndex 中，然后再 in.retainedSlice(startIndex, endIndex - startIndex) 一下就是原始數(shù)據(jù)切片。

1. 出錯(cuò)了

這個(gè)用法太想當(dāng)然了，API 文檔也沒(méi)有說(shuō)明，但是程序一直運(yùn)行正常，所以也沒(méi)太多關(guān)注。

最近優(yōu)化測(cè)試偶爾發(fā)現(xiàn)幾條錯(cuò)誤，特別是對(duì)于大消息體，基本上發(fā)十幾條消息就出錯(cuò)，總的來(lái)說(shuō)有兩類錯(cuò)誤日志：

  1. 讀 ByteBuf 時(shí)拋出 io.netty.util.IllegalReferenceCountException: refCnt: 0
  2. 成功讀到部分?jǐn)?shù)據(jù)，解析的時(shí)候發(fā)現(xiàn)數(shù)據(jù)是偏移的。

此處的“偏移”很重要，由于數(shù)據(jù)不是亂的，只是向后偏移了，才猜測(cè)是不是 ByteToMessageDecoder 中聚合 ByteBuf 的問(wèn)題。

2. 打日志

這樣的程序 debug 不方便，只能打日志了，加了兩個(gè)位置：

  1. 在 out.add( 之前打印 startIndex、endIndex、解碼過(guò)程中讀取的字節(jié)、retainedSlice 的可讀字節(jié)數(shù)。
  2. 將 MERGE_CUMULATOR 復(fù)制出來(lái)，在三個(gè) return 之前打印標(biāo)識(shí)。
[2020-04-09 11:18:11:255] - MERGE_CUMULATOR in.isContiguous
[2020-04-09 11:18:11:262] - MERGE_CUMULATOR writeBytes
[2020-04-09 11:18:11:262] - ---- out /10.251.120.22:41984 0 16498 16498 16498
[2020-04-09 11:18:11:662] - MERGE_CUMULATOR in.isContiguous
[2020-04-09 11:18:11:663] - ---- out /10.251.120.22:41984 0 16498 16498 16498
[2020-04-09 11:18:11:673] - MERGE_CUMULATOR in.isContiguous
[2020-04-09 11:18:11:673] - MERGE_CUMULATOR writeBytes
[2020-04-09 11:18:11:674]  - ---- out /10.251.120.22:41984 0 16498 16498 16498
[2020-04-09 11:18:11:682] - MERGE_CUMULATOR in.isContiguous
[2020-04-09 11:18:11:682] - MERGE_CUMULATOR writeBytes
[2020-04-09 11:18:11:683] - ---- out /10.251.120.22:41984 0 16498 16498 16498
[2020-04-09 11:18:11:691] - MERGE_CUMULATOR in.isContiguous
[2020-04-09 11:18:11:691] - MERGE_CUMULATOR writeBytes
[2020-04-09 11:18:11:692] - ---- out /10.251.120.22:41984 0 16498 16498 16498
[2020-04-09 11:18:11:700] - MERGE_CUMULATOR in.isContiguous
[2020-04-09 11:18:11:701] - MERGE_CUMULATOR writeBytes
[2020-04-09 11:18:11:702] - ---- out /10.251.120.22:41984 0 16498 16498 16498
[2020-04-09 11:18:11:797] - MERGE_CUMULATOR in.isContiguous
[2020-04-09 11:18:11:798] - MERGE_CUMULATOR writeBytes
[2020-04-09 11:18:11:799] - ---- out /10.251.120.22:41984 0 16498 16498 16498
[2020-04-09 11:18:11:896] - MERGE_CUMULATOR in.isContiguous
[2020-04-09 11:18:11:897] - MERGE_CUMULATOR writeBytes
[2020-04-09 11:18:11:898] - ---- out /10.251.120.22:41984 0 16498 16498 16498
[2020-04-09 11:18:11:995] - MERGE_CUMULATOR in.isContiguous
[2020-04-09 11:18:11:996] - MERGE_CUMULATOR writeBytes
[2020-04-09 11:18:11:997] - ---- out /10.251.120.22:41984 0 16498 16498 16498
[2020-04-09 11:18:12:095] - MERGE_CUMULATOR in.isContiguous
[2020-04-09 11:18:12:096] - MERGE_CUMULATOR writeBytes
[2020-04-09 11:18:12:096] - ---- out /10.251.120.22:41984 0 16497 16497 16497
[2020-04-09 11:18:12:195] - MERGE_CUMULATOR in.isContiguous
[2020-04-09 11:18:12:196] - MERGE_CUMULATOR writeBytes
[2020-04-09 11:18:12:197] - ---- out /10.251.120.22:41984 0 16498 16498 16498
[2020-04-09 11:18:12:295] - MERGE_CUMULATOR in.isContiguous
[2020-04-09 11:18:12:296] - MERGE_CUMULATOR writeBytes
[2020-04-09 11:18:12:296] - ---- out /10.251.120.22:41984 0 16498 16498 16498
[2020-04-09 11:18:12:395] - MERGE_CUMULATOR in.isContiguous
[2020-04-09 11:18:12:396] - MERGE_CUMULATOR writeBytes
[2020-04-09 11:18:12:397] - ---- out /10.251.120.22:41984 0 16498 16498 16498
[2020-04-09 11:18:12:495] - MERGE_CUMULATOR in.isContiguous
[2020-04-09 11:18:12:496] - MERGE_CUMULATOR in.isContiguous
[2020-04-09 11:18:12:496] - MERGE_CUMULATOR writeBytes
[2020-04-09 11:18:12:496] - ---- out /10.251.120.22:41984 0 16390 16498 16390
# 出錯(cuò)

前面都是讀兩次獲取一個(gè)完整的 redis 命令，最后一次就比較特殊了：

[2020-04-09 11:18:12:495] - MERGE_CUMULATOR in.isContiguous
# 讀到末尾，正好是 redis 協(xié)議的一個(gè)完整子部分，所以釋放掉
[2020-04-09 11:18:12:496] - MERGE_CUMULATOR in.isContiguous
# 現(xiàn)在 cumulation 是不完整的了，但是 startIndex 是 0，slice 時(shí)不會(huì)報(bào)錯(cuò)
[2020-04-09 11:18:12:496] - MERGE_CUMULATOR writeBytes
# 最后發(fā)現(xiàn)第一個(gè) ByteBuf 是 108 字節(jié)，已經(jīng)被釋放了
[2020-04-09 11:18:12:496] - ---- out /10.251.120.22:41984 0 16390 16498 16390

由于 redis 字段的讀取用的是 readSlice(，如果是位于前半部分釋放了，那就是IllegalReferenceCountException；如果位于 retainSlice 的后半部分，那就是消息格式出錯(cuò)了（偏移）。

3. 如何處理

把 ByteToMessageDecoder 看了一遍，想基于這個(gè)抽象類實(shí)現(xiàn)還是比較麻煩，還不如拷貝出來(lái)改一下，控制好釋放的時(shí)機(jī)。

4. ByteToMessageDecoder 筆記

解析 ByteToMessageDecoder 的文章有很多，感覺(jué)《 Netty 解碼器抽象父類 ByteToMessageDecoder 源碼解析 》、《Netty拆包器分析》這兩篇寫的還不錯(cuò)。

核心邏輯很清晰：


?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容