明确关键点:
要搞懂事件在多个channelHandler间的传播顺序,有几个关键点需要明确
0.channelHandler分为两大类,即InboundChannelHandler和OutboundChannelHandler,InboundChannelHandler用于处理入站事件(如read),OutboundChannelHandler处理出站事件(如write)
1.所有channelHandler由channelPipeline统一管理,pipeline维护一个双向链表结构(下文称为channelHandler链),添加移除channelHandler都会作用到链表上
2.channelPipeline初始化时,会默认创建两个哨兵channelHandler,即HeadContext、TailContext,HeadContext在链表头部,TailContext在尾部,我们添加的channelHandler总是处于二者之间
比如我们通过SocketChannel.pipeline().addLast方法依次添加了ByteToMessageDecoder、MessagetobyteEncoder、BizHandler之后,channelHandler链就是这样
(ps:标红的inbound、outbound表示该channelHandler属于InboundChannelHandler还是OutboundChannelHandler,当然了,也可以二者都属于)
(ps:从左往右是next方向,从右往左是prev方向)
3.事件传播会以某个channelHandler为起点,沿着channelHandler链、向next或者prev方向查找符合要求的目标channelHandler,然后将事件传给它,目标channelHandler可以接着传播,也可以停止传播
- 在netty中,事件传播有两类方法
- 通过Pipeline传播,比如pipeline.fireChannelRead传播读事件、pipeline.write传播写事件(还有些地方通过channel传播,实际上也是委托给Pipeline)
- 通过ChannelHandlerContext传播,比如ChannelHandlerContext.fireChannelRead传播读事件、ChannelHandlerContext.write传播写事件
- 通过Pipeline传播入站事件时,起点为HeadContext,通过ChannelHandlerContext传播入站事件时,起点为当前channelHandler(该ChannelHandlerContext对应的channelHandler就是当前channelHandler);传播的方向为next(从左往右),目标是InboundHandler(也就是只传给InboundHandler)
- 通过Pipeline传播出站事件时,起点为TailContext,通过ChannelHandlerContext传播出站事件时,起点为当前channelHandler;传播的方向为prev(从右往左),目标是OutboundHandler(也就是只传给OutboundHandler)
下面进行详细说明
channelHandler链的构造:
服务端/客户端启动时,会初始化channelPipeline,channelPipeline初始化时会创建一个channelHandler链,结构为双向链表;(ps:这里服务端客户端逻辑一致)
就拿服务端来说,服务端的启动入口大家都知道,是ServerBootstrap.bind(port)方法
bind方法首先会通过反射创建一个Channel,Channel初始化过程中会创建一个Pipeline,这个过程如下图:
在NioServerSocketChannel父类AbstractChannel的构造方法中,会初始化一个ChannelPipeline
newChannelPipeline会创建一个DefaultChannelPipeline实例,其构造方法如下:
HeadContext、TailContext,就是上面说的哨兵,通过next/prev属性连接起来,其中TailContext是InboundHandler,HeadContext既是InboundHandler,也是OutboundHandler
后续我们调用pipeline.addLast()方法添加的channelHandler都会处于HeadContext与TailContext之间
channelHandler链组装好之后,接下来就是事件传播了;我们以读写事件为例,在netty中,read事件由netty帮我们传播,write事件由开发者传播
read事件传播:
先看read事件,我们得找到read事件的源头,Netty中,channel的所有IO事件都由EventLoop处理,所以我们将视线转移到NioEventLoop中,NioEventLoop的run方法里就干了两件事情
1是轮询并处理selector事件,2是处理taskQueue中的任务,我们的重点放在1,从run开始,直到出现已就绪的read事件,开始将其传播,大致流程如下:
最后调用pipeline.fireChannelRead进行read事件传播,方法体如下:
head!!!没错,就是HeadContext,通过Pipeline传播入站事件时,就以HeadContext为起点,它会找到下一个inboundHandler,然后将事件传播给它:
(AbstractChannelHandlerContext是ChannelHandler的上下文,一一对应的,找到ChannelHandlerContext就相当于找到了ChannelHandler)
这个do while会一直往next方向找,直到第一个InboundHandler,调用其channelRead方法,对于我们上面的Handler链,就会首先找到ByteToMessageDecoder;
ByteToMessageDecoder的channelRead方法会先调用子类的decode方法,然后继续传播事件:
fireChannelRead方法:
它调用的是ChannelHandlerContext.fire*,前面说了,通过ChannelHandlerContext传播事件的起点是当前channelHandler,传播的方向是next,代码和上面贴的是同一份,我再贴过来:
会往next方向,找到下一个InboundHandler,也就是我们的BizHandler
通常情况下,BizHandler的channelRead方法中,我们不会再继续往下传播read事件了,read事件到此结束,所以本次read事件的传播过程就是这样:
1.NioEventLoop轮询出就绪的read事件后,调用Pipeline.fireChannelRead方法传播事件
2.通过Pipeline传播读事件时,会以HeadContext为起点,向next方向,查找下一个InboundHandler,在本例中,也就是ByteToMessageDecoder
3.在解码出Message后,ByteToMessageDecoder会调用ChannelHandlerContext.fireChannelRead方法传播事件
4..通过ChannelHandlerContext传播读事件时,会以当前channelHandler为起点,向next方向,查找下一个InboundHandler,在本例中,也就是BizHandler
5.BizHandler中我们一般不会继续传播读事件,读事件结束
write事件传播:
再来看看write事件,原理与上面的read事件类似,区别就是方向相反、目标不同!
入站事件的方向是next方向,目标是InboundHandler
出站事件的方向是prev方向,目标是OutboundHandler,终点是HeadContext
正常情况下,write事件由我们开发者触发,分为两种方式:
对应我们前面说的,事件传播的两类方法:ctx.write对应ChannelHandlerContext,ctx.channel().write对应Pipeline
拿ctx.channel().write来说,流程大致如下:
Pipeline.write方法如下:
tail!!!没错,就是TailContext,pipeline的最后一个channelHandler,通过Pipeline传播出站事件时,以TailContext为起点,它会找到下一个outboundHandler,然后将事件传播给它::
可以看到,传播方向与read相反,往prev方向找前一个OutboundHandler,我把channelHandler链再贴过来
TailContext先找到BizHandler,发现不是OutboundHandler,再找到MessageToByteEncoder,发现是OutboundHandler,调用其write方法:
MessageToByteEncoder会先调用子类的encode方法,再调用ChannelHandlerContext.write方法传播write事件
ChannelHandlerContext.write方法会以当前channelHandler为起点,往prev方向找前一个OutboundHandler,也就是HeadContext
HeadContext是出站事件的终点,它会调用底层unsafe的write方法往netty的写缓冲区写入字节流,对于我们来说,write事件到此就结束了,本次write事件的传播过程大致如下:
1.BizHandler中调用ctx.channel().write(msg)传播write事件
2.channel.write方法会调用Pipeline.write,通过Pipeline传播写事件时,会以TailContext为起点,向prev方向,查找下一个OutboundHandler,也就是MessageToByteEncoder
3.MessageToByteEncoder调用完子类的encode方法将消息编码后,继续调用ChannelHandlerContext.write(msg)传播事件
4.通过ChannelHandlerContext传播写事件时,会以当前channelHandler为起点,向prev方向,查找下一个OutboundHandler,也就是出站事件的终点,HeadContext
5.HeadContext调用底层的unsafe将消息写入缓冲区,写事件结束
如果在BizHandler中,调用的是ctx.write方法,那起点就不是TailContext了,而是当前Handler,往回找到下一个满足条件的Handler,也就是MessageToByteEncoder,对本例来说,效果一样
如果在往pipeline中添加Handler时,把MessageToByteEncoder放到BizHandler后面,也就是这样:
你想一想,在BizHandler里调用ctx.write(msg)和ctx.channel().write(msg)效果还一样吗?