2019-12-06pipeline.fireChannelRead(byteBuf)
如果没有指定，就是workThread来处理这些数据（卑微的打工仔。）
handler之间的传播信息通过fireXXX方法：其区别是从哪个节点开始传播。
默认处理线程就是Channel绑定的NioEventLoop线程，也可以设置其他（其它的线程走的是开个新的定时任务）:
pipeline.addLast(new UnorderedThreadPoolEventExecutor(10), serverHandler)
inbound从head开始，找下一个可以执行channelRead的地方(通过inbound属性轮询出下一个inboundHandlerContext)，一直到尾节点TailContext
outbound刚好执行顺序反过来。
其实真正处理数据还是在ctx.fireChannelRead(msg)展开作者回复: 正解
1
2019-11-20老师，EchoServerHandler的channelRead()方法并没有再调用ctx.fireChannelRead(msg)，是不是pipeline到这里就断了 ？作者回复: 准确的说，pipeline中读的处理流水线就结束了，因为echo server hander是最终处理业务了，它处理完，就可以返回结果，返回结果是相当于走pipeline中写的处理线了。所以你这样表述，大体意思对的，就是不够精确，一类pipeline不仅包括读也包括写，你说断了，其实是读的那条线结束了。
2019-10-31在读小标题的时候，发现读起来不顺口。于是统一成 动词 + 名词：启动服务，构建连接，接收数据，处理业务，发送数据，断开连接，关闭服务。当然，核心的逻辑知识都烂熟于心了，于是提个非常不起眼的小小建议。老师讲得非常好，帮我理清了主线逻辑。学会了怎么欣赏Netty。学习他怎么使用内存？怎么使用锁?怎么使用设计模式？怎么使用双向链表？作者回复: 这个小建议很细致，😂，以后我会尽量追求如此