四、使用包定长FixedLengthFrameDecoder解决半包粘包
4.1 试验
由于客户端发给服务器端的是hello server,im a client字符串，该字符串占用24字节，所以在服务器端channelpipeline里面添加一个长度为24的定长解码器和二进制转换为string的解码器：
然后修改NettyServerHandler的channelRead如下：
由于服务器发给客户端的是hello client ,im server字符串，该字符串占用23字节，所以在客户端端channelpipeline里面添加一个长度为23的定长解码器和二进制转换为string的解码器：
然后修改NettyClientHandler的channelRead如下：
然后重新启动服务器客户端，结果如下：
服务器端结果：
----Server Started----
--- accepted client---
0receive client info: hello server,im a client
send info to client:hello client ,im server
1receive client info: hello server,im a client
send info to client:hello client ,im server
2receive client info: hello server,im a client
send info to client:hello client ,im server
3receive client info: hello server,im a client
send info to client:hello client ,im server
4receive client info: hello server,im a client
send info to client:hello client ,im server
5receive client info: hello server,im a client
send info to client:hello client ,im server
6receive client info: hello server,im a client
send info to client:hello client ,im server
7receive client info: hello server,im a client
send info to client:hello client ,im server
8receive client info: hello server,im a client
send info to client:hello client ,im server
9receive client info: hello server,im a client
send info to client:hello client ,im server
客户端结果：
--- client already connected----
0receive from server:hello client ,im server
1receive from server:hello client ,im server
2receive from server:hello client ,im server
3receive from server:hello client ,im server
4receive from server:hello client ,im server
5receive from server:hello client ,im server
6receive from server:hello client ,im server
7receive from server:hello client ,im server
8receive from server:hello client ,im server
9receive from server:hello client ,im server
可知使用FixedLengthFrameDecoder已经解决了半包粘包问题。
4.2 FixedLengthFrameDecoder的原理
顾名思义是使用包定长方式来解决粘包半包问题，假设服务端接受到下面四个包分片：
那么使用FixedLengthFrameDecoder(3)会将接受buffer里面的上面数据解码为下面固定长度为3的3个包
FixedLengthFrameDecoder是继承自 ByteToMessageDecoder类的,当服务器接受buffer数据就绪后会调用ByteToMessageDecoder的channelRead方法进行读取，下面我们从这个函数开始讲解：
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
//4.2.1
if (msg instanceof ByteBuf) {
CodecOutputList out = CodecOutputList.newInstance();
try {
...
//4.2.2
callDecode(ctx, cumulation, out);
} catch (DecoderException e) {
throw e;
} catch (Throwable t) {
throw new DecoderException(t);
} finally {
...
}
} else {
//4.2.3
ctx.fireChannelRead(msg);
}
}
如上代码4.2.2具体是方法callDecode进行数据读取的，其代码如下：
protected void callDecode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) {
try {
//4.2.4
while (in.isReadable()) {
int outSize = out.size();
//4.2.4.1
if (outSize > 0) {
fireChannelRead(ctx, out, outSize);
out.clear();
...
}
//4.2.4.2
int oldInputLength = in.readableBytes();
decodeRemovalReentryProtection(ctx, in, out);
...
//4.2.4.3
if (outSize == out.size()) {
if (oldInputLength == in.readableBytes()) {
break;
} else {
continue;
}
}
...
//4.2.4.4
if (isSingleDecode()) {
break;
}
}
} catch (DecoderException e) {
throw e;
} catch (Throwable cause) {
throw new DecoderException(cause);
}
}
如上代码callDecode中4.2.4是使用循环进行读取，这是因为可能出现粘包情况，使用循环可以逐个对单包进行处理。
其中4.2.4.1判断如果读取了包则调用fireChannelRead激活channelpipeline里面的其它handler的channelRead方法，因为这里，FixedLengthFrameDecoder只是channelpipeline中的一个handler。
代码4.2.4.2的decodeRemovalReentryProtection方法作用是调用FixedLengthFrameDecoder的decode方法具体从接受buffer读取数据，后者代码如下：
protected final void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
Object decoded = decode(ctx, in);//4.2.6
if (decoded != null) {
out.add(decoded);
}
}
protected Object decode(
@SuppressWarnings("UnusedParameters") ChannelHandlerContext ctx, ByteBuf in) throws Exception {
if (in.readableBytes() < frameLength) {
return null;
} else {
return in.readRetainedSlice(frameLength);
}
}
如上代码4.2.6如果发现接受buffer里面的字节数小于我们设置的固定长度frameLength则说明出现了半包情况，则直接返回null；否者读取固定长度的字节数。
然后执行代码4.2.4.3，其判断outSize == out.size()说明代码4.2.6没有读取一个包（说明出现了半包），则看当前buffer缓存的字节数是否变化了，如果没有变化则结束循环读取，如果变化了则可能之前的半包已经变成了全包，则需要再次调用4.2.6进行读取判断。
代码4.2.4.4判断是否只需要读取单个包（默认false），如果是则读取一个包后就跳出循环，也就是如果出现了粘包现象，在一次channelRead事件到来后并不会循环读取所有的包，而是读取最先到的一个包，那么buffer里面剩余的包要等下一次channelRead事件到了时候在读取。
最后
想了解JDK NIO和更多Netty基础的可以单击我
想了解更多关于粘包半包问题单击我
更多关于分布式系统中服务降级策略的知识可以单击 单击我
想系统学dubbo的单击我
想学并发的童鞋可以 单击我
