Java NIO框架Netty教程(十)-Object对象的连续收发解析分析

全文详见个人独立博客：Java NIO框架Netty教程(十)-Object对象的连续收发解析分析

Java NIO框架Netty教程(十)-Object对象的连续收发解析分析如果您一直关注OneCoder，我们之前有两篇文章介绍关于Netty消息连续收发的问题。( 《Java NIO框架Netty教程（五）- 消息收发次数不匹配的问题 》、《 Java NIO框架Netty教程(七)-再谈收发信息次数问题 》)。如果您经常的”怀疑”和思考，我们刚介绍过了Object的传递，您是否好奇，在Object传递中是否会有这样的问题？如果Object流的字节截断错乱，那肯定是会出错的。Netty一定不会这么傻的，那么Netty是怎么做的呢？ 我们先通过代码验证一下是否有这样的问题。（有问题的可能性几乎没有。） /** * 当绑定到服务端的时候触发，给服务端发消息。 * * @author lihzh * @alia OneCoder */ @Override public void channelConnected(ChannelHandlerContext ctx, ChannelStateEvent e) { // 向服务端发送Object信息 sendObject(e.getChannel()); } /** * 发送Object * * @param channel * @author lihzh * @alia OneCoder */ private void sendObject(Channel channel) { Command command = new Command(); command.setActionName(&quot;Hello action.&quot;); Command commandOne = new Command(); commandOne.setActionName(&quot;Hello action. One&quot;); Command command2 = new Command(); command2.setActionName(&quot;Hello action. Two&quot;); channel.write(command2); channel.write(command); channel.write(commandOne); } 打印结果： Hello action. Two Hello action. Hello action. One 一切正常。那么Netty是怎么分割对象流的呢？看看ObjectDecoder怎么做的。 在ObjectDecoder的基类LengthFieldBasedFrameDecoder中注释中有详细的说明。我们这里主要介绍一下关键的代码逻辑： @Override protected Object decode( ChannelHandlerContext ctx, Channel channel, ChannelBuffer buffer) throws Exception { if (discardingTooLongFrame) { long bytesToDiscard = this.bytesToDiscard; int localBytesToDiscard = (int) Math.min(bytesToDiscard, buffer.readableBytes()); buffer.skipBytes(localBytesToDiscard); bytesToDiscard -= localBytesToDiscard; this.bytesToDiscard = bytesToDiscard; failIfNecessary(ctx, false); return null; } if (buffer.readableBytes() < lengthFieldEndOffset) { return null; } int actualLengthFieldOffset = buffer.readerIndex() + lengthFieldOffset; long frameLength; switch (lengthFieldLength) { case 1: frameLength = buffer.getUnsignedByte(actualLengthFieldOffset); break; case 2: frameLength = buffer.getUnsignedShort(actualLengthFieldOffset); break; case 3: frameLength = buffer.getUnsignedMedium(actualLengthFieldOffset); break; case 4: frameLength = buffer.getUnsignedInt(actualLengthFieldOffset); break; …… 我们这里进入的是4，还记得在编码时候的开头的4位占位字节吗？跟踪进去发现。 public int getInt(int index) { return (array[index] & 0xff) << 24 | (array[index + 1] & 0xff) << 16 | (array[index + 2] & 0xff) << 8 | (array[index + 3] & 0xff) << 0; } 原来，当初在编码时，在流开头增加的4字节的字符是做这个的。他记录了当前了这个对象流的长度，便于在解码时候准确的计算出该对象流的长度，正确解码。看来，我们如果我们自己写的对象编码解码的工具，要考虑的还有很多啊。 附：LengthFieldBasedFrameDecoder的JavaDoc /** * A decoder that splits the received {@link ChannelBuffer}s dynamically by the * value of the length field in the message.  It is part