先看一段简单的代码一服务端publicstaticvoidmain(String[]args)throwsException{// sendToEachOther();// 1启动器负责组装netty组件启动服务器newServerBootstrap()//2BossEventLoop WorkerEventLoop(selector,thread),group组.group(newNioEventLoopGroup())// 3选择服务器SocketChannel实现.channel(NioServerSocketChannel.class).childHandler(newChannelInitializerNioSocketChannel(){OverrideprotectedvoidinitChannel(NioSocketChannelch){//4 将传过来的bytebuf转换为字符串ch.pipeline().addLast(newStringDecoder(CharsetUtil.UTF_8));// 入站ByteBuf - Stringch.pipeline().addLast(newChannelInboundHandlerAdapter(){OverridepublicvoidchannelRead(ChannelHandlerContextctx,Objectmsg)throwsException{System.out.println(Server received from client: msg);}OverridepublicvoidexceptionCaught(ChannelHandlerContextctx,Throwablecause){cause.printStackTrace();ctx.close();}});}}).bind(8083);}二客户端publicstaticvoidmain(String[]args)throwsException{// 1启动器负责组装netty组件启动服务器newBootstrap()//2EventLoopGroup.group(newNioEventLoopGroup())// 3选客户端ServerSocketChannel实现.channel(NioSocketChannel.class).handler(newChannelInitializerNioSocketChannel(){OverrideprotectedvoidinitChannel(NioSocketChannelch){//4 字符串解析为bufch.pipeline().addLast(newStringEncoder(CharsetUtil.UTF_8));}}).connect(newInetSocketAddress(localhost,8083)).sync().channel().writeAndFlush(hello,how are you);}分别启动服务端和客户端发现服务端没有输出任何数据我就试着将客户端发送的内容hello,how are you改成了hello,world服务端就正确输出了数据这是什么原因三原因分析这个现象的核心原因是服务端没有配置帧拆分器仅靠StringDecoder的容错特性刚好让短字符串hello,world绕过了TCP传输的不稳定性而长字符串hello,how are you触发了Netty的半包等待机制具体可以拆解为3个关键细节短字符串刚好一次性完成传输hello,world的字节长度仅11字节属于非常小的数据包在你当前的本地回环localhost通信场景下TCP几乎不会对它进行分片也不会触发内核缓冲区的延迟发送机制整个字节流一次性完整到达服务端的Socket缓冲区。StringDecoder拿到完整的UTF-8字节序列后直接将其转换为字符串顺利传递到你的channelRead方法中完成打印。长字符串触发了半包等待之前的hello,how are you长度达到17字节在没有配置任何拆帧处理器的情况下Netty的StringDecoder没有内置的消息边界识别能力。本地TCP传输时可能把这个长字符串拆分成了2个小包发送服务端第一次只收到了部分字节StringDecoder无法判断这是一个不完整的字符串帧就会一直处于等待剩余数据的状态不会把不完整的数据向下传递给业务Handler自然不会触发打印。没有异常抛出掩盖了问题这种半包场景下不会抛出解码异常你的exceptionCaught方法完全不会被触发整个流程看起来就像服务端完全没有收到消息实际上数据已经停留在解码器的等待队列中直到后续有新数据到来才会尝试拼接解析。如果要让任意长度的字符串都能稳定被服务端接收只需要在服务端的StringDecoder之前添加固定规则的拆帧处理器比如换行分隔的LineBasedFrameDecoder就能彻底避免这种依赖数据包长度的“偶然正常”现象。四如何解决半包读取问题在Netty中解决半包读取问题的核心思路是通过应用层协议明确消息边界让接收端能精准识别出完整的业务数据包避免依赖TCP字节流的无边界特性导致的数据读取不完整。以下是Netty官方推荐的几种成熟解决方案适配不同的业务场景1. 固定分隔符方案通过约定特殊字符作为消息的结束标记Netty会自动以该标记拆分数据将完整的单条消息传递给后续业务Handler彻底避免半包等待。LineBasedFrameDecoder以换行符\n或\r\n作为分隔符是最常用的轻量方案适合日志、简单文本类通信场景。配置时指定最大帧长度超过长度仍未找到分隔符就会抛出异常防止数据异常导致内存溢出。DelimiterBasedFrameDecoder支持自定义多个分隔符比如可以指定KaTeX parse error: Expected group after _ at position 1: _̲作为消息结束标记适配自定义的特殊边界规则。典型配置示例2. 固定长度方案客户端和服务端提前约定每条业务消息的固定字节长度不足长度时用指定字符填充。Netty的FixedLengthFrameDecoder会自动按预设长度截取数据无论TCP传输过程中出现粘包还是半包都能保证每次拿到完整的定长消息。适用场景业务消息长度统一的简单场景比如指令类通信。示例配置约定每条消息固定15字节直接添加解码器即可自动完成半包处理ch.pipeline().addLast(newFixedLengthFrameDecoder(15));3. 长度字段前置方案工业级通用方案在自定义协议的消息头部预留固定长度的字段专门记录后续业务数据体的字节长度。Netty的LengthFieldBasedFrameDecoder会自动读取长度字段根据长度值从字节流中截取对应长度的完整消息是目前最通用、扩展性最强的半包处理方案Dubbo、Redis等主流框架都基于该思路实现协议解析。核心配置参数指定最大帧长度、长度字段的偏移位置、长度字段自身的字节数即可自动适配绝大多数自定义协议。示例配置消息头部前4字节存储数据体长度后续直接读取对应长度的完整消息// 最大帧长4096长度字段偏移0长度字段占4字节消息体和长度字段直接相邻ch.pipeline().addLast(newLengthFieldBasedFrameDecoder(4096,0,4,0,4));4. 其他辅助优化手段避免依赖短连接解决半包虽然每次发完消息就断开连接可以天然制造消息边界但频繁创建销毁连接性能极低仅适合极低频次的通信场景。合理调整缓冲区通过ChannelOption.SO_RCVBUF调整TCP内核接收缓冲区大小同时设置Netty的ByteBuf初始容量减少大消息被拆分的概率但该手段只能缓解半包无法从根本上解决问题。
 获取与实战)
