ICode9

精准搜索请尝试: 精确搜索
首页 > 编程语言> 文章详细

netty源码分析_带你搞懂ChannelHandler事件传播顺序

2020-06-10 11:09:03  阅读:277  来源: 互联网

标签:netty 调用 传播 write Handler HeadContext 事件 搞懂 源码


明确关键点:

要搞懂事件在多个ChannelHandler间的传播顺序,有两个关键点需要明确

1.pipeline初始化时,会创建两个哨兵Handler,即HeadContext、TailContext,head在头,tail在尾,我们添加的Handler就处于首尾Handler之间

       HeadContext可以是入站事件传播的起点,一定是出站事件传播的终点

       TailContext可以是出站事件传播的起点(为啥分为"可以是"与"一定是",下文会有说明)

2.事件的传播起点、方向、目标:

       入站事件传播的起点为当前Handler或者HeadContext,方向为next,也就是往下一个,目标是InboundHandler

       出站事件传播的起点为当前Handler或者TailContext,方向为prev,也就是往回一个,目标是OutboundHandler

下面以这两点为主线进行剖析

Pipeline初始化,组装Handler链:

服务端的启动入口大家都知道,是ServerBootstrap.bind(port)方法

bind方法首先会通过反射创建一个Channel,Channel初始化过程中会创建一个Pipeline,这个过程如下图:

在Channel的构造方法中,会初始化一个ChannelPipeline

newChannelPipeline会创建一个DefaultChannelPipeline实例,其构造方法如下:

HeadContext、TailContext,就是这个pipeline中初始的两个Handler,也就是上面说的哨兵Handler,其中TailContext是InboundHandler,HeadContext既是InboundHandler,也是OutboundHandler

 

后续我们调用pipeline.addLast()方法添加的Handler都会处于HeadContext与TailContext之间,比如在我们添加了ByteToMessageDecoder(子类)、MessagetobyteEncoder(子类)、BizHandler三个Handler之后,Handler链就是这样(注意,Handler之间是双向连接的,从左往右是next方向,从右往左是prev方向):

好了,Handler链已经组装好了,接下来就是事件传播了;我们以读写事件为例,在netty中,read事件由netty帮我们传播,write事件由我们自己传播

read事件传播:

先看read事件,我们得找到read事件的源头,Netty中,channel的所有IO事件由EventLoop处理,所以我们将视线转移到NioEventLoop中,NioEventLoop的run方法里就干了两件事情,1是轮询并处理selector事件,2是处理taskQueue中的任务,我们的重点放在1,从run开始看起,直到出现已就绪的read事件,开始将其传播,大致流程如下:

 

最后调用pipeline.fireChannelRead进行read事件传播,注意了!在netty中,事件传播有两类方法

1.Pipeline.*,比如fireChannelRead传播读事件、write传播写事件(还有一种Channel.fire*,实际上还是调用了Pipeline.fire*)

2.ChannelHandlerContext.*,比如fireChannelRead传播读事件、write传播写事件

这两类方法的唯一区别传播的起点不一样,前者的起点是HeadContext(入站事件起点)、或者TailContext(出站事件起点),后者的起点是当前Handler;

好了,我们接着看pipeline.fireChannelRead方法逻辑,方法体如下:

head!!!没错,就是HeadContext,pipeline中的第一个Handler,通过Pipeline.*方法传播入站事件时,就以HeadContext为起点,它会继续把读事件往下传播,寻找下一个Handler的逻辑如下图(AbstractChannelHandlerContext是ChannelHandler的上下文,一一对应的,找到ChannelHandlerContext就相当于找到了ChannelHandler):

这个do while循环的意思很明确,一直往next方向找,直到第一个InboundHandler,调用其channelRead方法,对于我们上面的Handler链,就会首先找到ByteToMessageDecoder;ByteToMessageDecoder的channelRead方法会先调用子类的decode方法,然后继续传播事件,代码如下:为方便理解,我略去了一些内容,重点关注我红框标出的代码

fireChannelRead方法:

它调用的是ChannelHandlerContext.fire*,前面说了,这类方法的起点是当前Handler,传播的方向是next,寻找Handler的代码和上面贴的是同一份,我再贴过来:

会往next方向,找到下一个InboundHandler,也就是我们的BizHandler

通常情况下,BizHandler的channelRead方法中,我们不会再继续往下传播read事件了,read事件到此结束,所以本次read事件的传播过程就是这样:

1.NioEventLoop轮询出就绪的read事件后,调用Pipeline.fireChannelRead方法传播事件

2.Pipeline.fireChannelRead方法会以HeadContext为起点,向next方向找InboundHandler,在本例中,也就是ByteToMessageDecoder

3.在解码出Message后,ByteToMessageDecoder会调用ChannelHandlerContext.fireChannelRead方法传播事件

4.该方法会以当前Handler为起点,向next方向找InboundHandler,在本例中,也就是BizHandler

5.BizHandler中我们一般不会继续传播读事件,读事件结束

 

write事件传播:

再来看看write事件,原理与上面的read事件类似,区别就是方向相反、目标不同!

入站事件的方向是next方向,目标是InboundHandler

出站事件的方向与入站事件相反,是prev方向,也就是往回传播,目标是OutboundHandler,终点是HeadContext

正常情况下,write事件由我们开发者触发,分为两种方式:

对应我们前面说的,事件传播的两类方法:Pipeline.*、ChannelHandlerContext.*

拿ctx.channel().write来说,流程大致如下:

Pipeline.write方法如下:

tail!!!没错,就是TailContext,pipeline的最后一个Handler,通过Pipeline.*方法传播出站事件时,就以TailContext为起点,它会继续把出站事件往下传播,查找下一个Handler的逻辑如下:

可以看到,传播方向与read相反,往回找前一个OutboundHandler,我把Handler链再贴过来

TailContext先找到BizHandler,发现不是OutboundHandler,再找到MessageToByteEncoder,发现是OutboundHandler,调用其write方法:

MessageToByteEncoder会先调用子类的encode方法,再调用ChannelHandlerContext.write方法传播write事件,会以当前Handler为起点,往prev方向找前一个OutboundHandler,也就是HeadContext,HeadContext是出站事件的终点,它会调用底层unsafe的write方法往netty的写缓冲区写入字节流,对于我们来说,write事件到此就结束了,本次write事件的传播过程大致如下:

1.BizHandler中调用ctx.channel().write(msg)传播write事件

2.channel.write方法会调到Pipeline.write,我们说过,它会以TailContext为起点,prev为方向,OutboundHandler为目标,查找下一个符合要求的Handler,也就是MessageToByteEncoder

3.MessageToByteEncoder调用完子类的encode方法将消息编码后,继续调用ChannelHandlerContext.write(msg)传播事件

4.ChannelHandlerContext.write方法以当前Handler为起点,prev为方向,OutboundHandler为目标,查找下一个符合要求的Handler,也就是出站事件的终点,HeadContext

5.HeadContext调用底层的unsafe将消息写入缓冲区,写事件结束

 

如果在BizHandler中,调用的是ctx.write方法,那起点就不是TailContext了,而是当前Handler,往回找到下一个满足条件的Handler,也就是MessageToByteEncoder,对本例来说,效果一样

如果在往pipeline中添加Handler时,把MessageToByteEncoder放到BizHandler后面,也就是这样:

你想一想,在BizHandler里调用ctx.write(msg)和ctx.channel().write(msg)效果还一样吗?

 

标签:netty,调用,传播,write,Handler,HeadContext,事件,搞懂,源码
来源: https://blog.csdn.net/wb_snail/article/details/106621670

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有