2019-11-25server没有分boss和work?作者回复: 你看的很细致，点赞，第四章雏形，所以直接写，方便起见，没有分，在第五章分了。看来把原理知识放前面还是有用的，直接能看出问题了。哈哈
1
2019-12-21老师，为什么你在channelread方法里就把结果给flush了呢，我理解是不是应该在readcomplete方法flush，channelread方法只是一次读事件的一部分数据啊。作者回复: 你理解的没问题，直接channel read里写也没问题，因为已经是一次完整请求了，写在complete里面有好处，就是减少flush次数，这个在第五章会详细说，这里是案例雏形，所以先用最简单的方式展示给大家，另外你说的部分数据，到了业务层已经包含完整请求了，在一次解码的handler里倒是可能是“部分”，所以这里功能没有问题的。
2019-12-05老师的最后一行代码，有个closeFuture()，既然是长连接，这close的肯定不是连接，那close的是什么呢？作者回复: 这里的close指的是服务器/客户端的关闭，不是单个连接的关闭。
1
2019-12-03老师您好！
1. 我这边看到是4.1.32.Final这个版本的，我在interface ChannelHandler中发现void exceptionCaught这个方法被被标记为Deprecated，是不是我在业务handle收集异常使用这个方法是不被建议的吗？还是有更好的解决方式？
2. 老师能简单的介绍一下，多个业务handler在fire事件的时候应该注意什么，或者有什么容易犯错的点吗？作者回复: 1 业务handler的异常现在被分成两个部分了：读用异常处理，所以exceptionCaught才从ChannelHandler（Deprecated）搞到ChannelInboundHandler里面，而写是用 PromiseNotificationUtil.tryFailure(promise, cause, promise instanceof VoidChannelPromise ? null : logger);来控制，所以收集异常的exceptionCaught方法还是在用，只是说只针对读，所以才移动了位置；
其实这个分2部分，也可以参考第五章的25页的异常处理统计那部分，也能体现。
2 主要三个问题注意：（1）handler顺序 （2）handler是否可共享 （3）内部处理是否有有资源应该释放而未释放，比如堆外的bytebuf.
2019-11-27老师 您现在的实现都是短链接的嘛？每个channel只使用一次？ netty是不是应该有和数据库连接池类似的实现呀 链接复用 省去3握4挥的过程？望指点作者回复: 都是长连接，netty默认都是长连接，除非你显式特地去断，所以，你从两个角度分析:服务器端有没有断你的连接？客户端有没有断你的连接，都没有，肯定长连接，默认也是没有的，因为他也不知道你的逻辑是需要一个请求断一次还是一定时间才断。