作者回复: 读保证自上而下，写保证自下而上就行了，读与写之间其实顺序无所谓，但是一般为了好看对称，我们是一组一组写。案例中的顺序功能是没有问题的，只是让你产生了疑惑。 你提出的这个不懂，我觉得我可以改下，但是如果我改了，或许你就没有这个问题了，哈哈，所以我要考虑下好看与教学效果之间做个平衡。

作者回复: 对于tcp大多如此的，但是有一种情况，就是如果你接受到数据，立马就转走，像路由器一样，那这个时候，你的处理就不需要那么多层次的编解码了，因为你不做处理，只是二转手，就像快递员一样，不会拆你的快递一样，就是给你转走； 不是这种情况下，大多都需要4+1, 4是2组：1组处理粘包：1组处理转化给用户好用/存储。最后那个1业务处理。

作者回复: 你这个感觉很好，我也是这么判断的，除了这点之外，你分2种情况看：别人写的和自己要写的，如果是别人写的，你看它可标记成@sharable了。如果自己写的，自己最清楚了，主要看可有线程安全和是否符合自己的需求，比如你统计整个系统的，一般都要做成共享的，如果你统计单一连接的，你肯定就是非共享的，不管用哪种方式去看，自己去实际分析代码最准确。其中就有你说的那个小方法，就是看那个类可有成员变量，如果一个没有，十有八九都可以共享。

作者回复: 客户端常见，服务器端见的少些，还是看具体需求，但是一定要搞清楚两者之间区别，否则要不多绕了一圈，要不就搞出问题了。当然有很多时候也不出问题，这里列出来的意思就是让大家要搞清楚这两个不一样，写的时候，小心点，如果用好了，能节约调用。

作者回复: 嗯，确实容易误导入。以前我也犯过类似的错：很多JAR立马的类名字一样，有天选错了.....

作者回复: 这个问题很好，其实是风格问题，你说的那样也可以，但是现在大多都是按照我那样的写法写，因为体现一对一对的感觉，很清晰，如果按照你想要的那种写法，其实让别人看到的是那种业务逻辑处理的感觉了，然后读者还要去读去找，看看你是不是一对一对的了。

作者回复: 加油，主要还是自己练习一遍。不然貌似懂了不定真正理解的。

作者回复: 速度还可以！

作者回复: 你这样说不是割裂了请求处理和响应了么？而且你说的不对吧。 请求是先解码，解出最终的业务请求，然后执行，然后再编码，作为响应发送回去。 就像在U型滑道上单向玩板车一样，是一个连续的过程。

作者回复: 参考这个实现：io.netty.handler.codec.LengthFieldBasedFrameDecoder#decode(io.netty.channel.ChannelHandlerContext, io.netty.buffer.ByteBuf) 首先，你这样做，netty不知道你是故意的，所以他认为这个数据还没有传完，所以会等你第二个正确的数据过来的时候，把你第二个数据（或部分，反正一共900字节）合并前面的100字节当第一个数据来处理，说是处理，还是传给你业务层，这个时候，一般你肯定会出错的（比如你做json解析肯定抛异常了），因为这个数据不是完整正确的。所以这个时候下步怎么走，要看你的io.netty.channel.ChannelHandler#exceptionCaught 怎么实现了。 这种情况，很难恢复回来了，所以可以直接在这个方法的实现中，直接把连接断掉。 你后面的问题，所以你要做授权（后面一章的内容）等防范，如果都授权过了。那别人就没有机会来发送这种数据。