pipeline.fireChannelRead(byteBuf) 如果没有指定，就是workThread来处理这些数据（卑微的打工仔。） handler之间的传播信息通过fireXXX方法：其区别是从哪个节点开始传播。 默认处理线程就是Channel绑定的NioEventLoop线程，也可以设置其他（其它的线程走的是开个新的定时任务）: pipeline.addLast(new UnorderedThreadPoolEventExecutor(10), serverHandler) inbound从head开始，找下一个可以执行channelRead的地方(通过inbound属性轮询出下一个inboundHandlerContext)，一直到尾节点TailContext outbound刚好执行顺序反过来。 其实真正处理数据还是在ctx.fireChannelRead(msg)

在读小标题的时候，发现读起来不顺口。于是统一成 动词 + 名词：启动服务，构建连接，接收数据，处理业务，发送数据，断开连接，关闭服务。当然，核心的逻辑知识都烂熟于心了，于是提个非常不起眼的小小建议。老师讲得非常好，帮我理清了主线逻辑。学会了怎么欣赏Netty。学习他怎么使用内存？怎么使用锁?怎么使用设计模式？怎么使用双向链表？

事件在 pipeline 中的传播，需要关注事件的传播行为和执行线程： 1. 传播行为：事件执行到某个 Handler 后，如果不手动触发 ctx.fireChannelRead，则传播中断。 2. 执行线程：业务线程默认是在 NioEventLoop 中执行。如果业务处理有阻塞，需要考虑另起线程执行。

老师，EchoServerHandler的channelRead()方法并没有再调用ctx.fireChannelRead(msg)，是不是pipeline到这里就断了 ？

如果一个请求数据很大导致读取多次，意味执行多次pipeline.fireChannelRead(byteBuf)，这样业务逻辑执行多次了，不知道理解是否有问题

老师你好，executionMask这个地方有一些疑问，课程中说这个值是在pipeline.add(handler)的时候添加的，这个地方应该怎么理解呢？是所有用过add()方法的都会生成统一的一个mask，还是说不同的handler生成不同的mask，那么在pipeline依次调用handler的过程中，我如何能知道当前读到的数据，应该让哪一个handler处理呢？（有的业务只需要1、2handler处理，有的需要3、4处理）