我继续努力了解Netty的内幕。
在ChannelPipeline中，显然的目的是让ChannelHandler彼此之间几乎不知道。入站处理程序会对事件做出反应并触发其他事件，从而重新触发未完全使用或处理的所有事件。很好
处理程序可以做的事情之一就是调用channelHandlerContext.read()。 （对于此示例，假设自动读取已关闭。）
当然，最终最终会引发一个channelReadComplete事件（很明显，在所有处理程序都调用了它们的channelRead方法并真正完成读取之后）。
我所看到的一种模式是处理程序处理此channelReadComplete事件的处理程序是先转发此事件（channelHandlerContext.fireChannelReadComplete()），然后请求读取（通常是关闭自动读取功能） ）（channelHandlerContext.read()。 HttpContentDecoder is an arbitrarily selected example of such a pattern that does exactly this。
假设我在HttpContentDecoder之后的处理程序中遵循相同的模式。现在是否会出现两个read()请求排队的情况？理想情况下，只需要一个就对了，因为如果启用了自动读取功能，情况就是这样？
更笼统地说：在执行此操作的 n 个处理程序的管道中，这不会导致 n read()请求，实际上只需要一个请求？