netty报IndexOutOfBoundsException?
结论:是粘包的问题出现问题的情况,当byteBuf里面可读的字节小于你的包场,这个时候你强行解包就会有问题。而有的时候没问题是因为byteBuf.readableBytes()正好大于你的整个包长(不太严谨,严谨的说法是你解包的时候byteBuf正好有你解对应字段的长度)。解决的办法1:先判断包长是否大于你的固定长度,例如一般可以约定header为定长,开始解包前,记录解包的位置: byteBuf.markReaderIndex();发先可读包长不够解包的长度,包readerIndex置位到最开始解包的位置。对于集成netty的decoder,直接return就好了。 if (byteBuf.readableBytes() \u0026lt; size) { byteBuf.resetReaderIndex(); return; } if (byteBuf.readableBytes() \u0026lt; Constants.HEADER_SIZE_NEW) { return; } byteBuf.markReaderIndex(); short magic = byteBuf.readShort(); if (magic != Constants.MAGIC) { byteBuf.resetReaderIndex(); throw new ForestFrameworkException("ForestDecoder transport header not support, type: " + magic); } byte version = byteBuf.readByte(); byte extend = byteBuf.readByte(); long messageID = byteBuf.readLong(); int size = byteBuf.readInt(); if (byteBuf.readableBytes() \u0026lt; size) { byteBuf.resetReaderIndex(); return; }解决办法2:打包的时候最先打一个包长,然后在打包内容,解包的时候第一步就判断可读的字节是否大于包长....还有其他的办法,可以去了解一下tcp 粘包拆包问题就会豁然开朗。顺手来个广告,dempeZheng/forestRPC基于netty, spring,轻量的高性能分布式RPC服务框架
推荐阅读
- 为啥netty ChannelPipeline要设计成一条双链表
- 对于处理耗时业务的服务,基于netty的服务端的性能为啥高于传统sevlet的服务端?
- C# 4.5的asyc socket,和netty的AIO,以及nodejs的异步非阻塞相比,不同点
- netty的启动过程是咋样的,就是那里启动了socket监听,咋处理请求的
- 为啥 netty 要重新写自己的 buffer 以及 channel
- 怎样配置方便阅读和记录注释Netty源码文件的IDEA环境
- Netty咋保持长连接
- 想在java中使用netty实现非阻塞的消息处理,再使用coroutine充分利用线程时间?
