Netty笔记:ReplayingDecoder中buffer使用的一点小陷阱

最新推荐文章于 2024-09-14 17:21:40 发布

tianshilang

最新推荐文章于 2024-09-14 17:21:40 发布

阅读量362

点赞数 1

java nio 同时被 2 个专栏收录

7 篇文章 0 订阅

订阅专栏

nio tomcat netty netty

3 篇文章 0 订阅

订阅专栏

ReplayingDecoder的原理是阻塞IO，当没有读到足够的数据时，会抛出RelayError，进入以后的LOOP中不断check是否有足够的数据。因此每次读取时我们倒要check一下buffer的数据。为此Netty提供了ReplayingDecoderBuffer这样一个代理类封装原有的buffer。以readInt为例，首先要检查是否有4个字节可读。不满足抛出ReplayError。

@Override
    public int readInt() {
        checkReadableBytes(4);
        return buffer.readInt();
    }

    private void checkReadableBytes(int readableBytes) {
        if (buffer.readableBytes() < readableBytes) {
            throw REPLAY;
        }
    }

陷阱在哪呢？我在ReplayingDecoder中使用buffer的readableBytes()发现总是一个很大数字，这个数据非常大明显超出我的数据整帧的大小好多倍。很蹊跷，我查看了一下代码发现

@Override

    public int readableBytes() {
        if (terminated) {
            return buffer.readableBytes();
        } else {
            return Integer.MAX_VALUE - buffer.readerIndex();
        }
    }

从结果上看terminated为false，所以他返回了Integer.MAX_VALUE - buffer.readerIndex();。terminated是什么呢有什么作用呢我又查看了code，terminated仅在cleanup的时候。当terminated为true才会读到真实buffer的readableBytes和capacity。并且ReplayingDecoderBuffer为protected，只能package内部使用，我们就不能将buffer转型为该类。至于terminated的作用还是没有想明白，还是尽量别用readableBytes这个方法，绕过他去吧。