Netty源码分析-- 处理客户端接入请求(八)

这一节我们来一起看下,一个客户端接入进来是什么情况。首先我们根据之前的分析,先启动服务端,然后打一个断点。

这个断点打在哪里呢?就是NioEventLoop上的select方法上。

然后我们启动一个客户端。

然后我们debug看到,selectedKey的数量 = 1,说明有accept或者读写等事件发生。

接下就会进 processSelectedKeys()

我们上一节讲到,这里的attach就是NioServerSocketChannel, 我们进入 processSelectedKey() 方法

重点来了,这里对各种事件进行分发,debug看我们现在是16,也就是说是accept事件。

继续跟进去F5进去

发现进入到了AbstractNioMessageChannel的read方法。这里进入的是 AbstractNioMessageChannel !!!;

为了加深印象,我们先暂停,重新跑一个读事件

发现当前的selectKey = 1,也就是读事件

F5 进入

发现,读事件进入到AbstractNioByteChannel中,

那么也就是accept进入  AbstractNioMessageChannel , 而 read 进入AbstractNioByteChannel 中。

好了,我们回过头来继续看 AbstractNioMessageChannel 中的read 方法。

关于这个分配器,这里我先不看,待后面分析内存模型的时候再说。我们直接看下面的代码:

我们发现这个是一个循环,不断的调用doReadMessages方法,并且传入了一个readBuf,而且这个readBuf是一个ArrayList, 那这里我们猜测可能是把读取到的客户端放到List集合中保存,然后再循环处理客户端连接。

进入doReadMessage方法一探究竟。

通过工具类调用 NioServerSocketChannel 内部封装的 serverSocketChannel 的 accept 方法,获取一个SocketChannel, 如果大家还记得我第一篇讲NIO的地方Netty源码分析--NIO(一),这里应该会有印象,我这里贴出来:

这里就是获取到了客户端的socketChannel

然后这里将SocketChannel封装成了一个NioSocketChannel,然后添加到了readBuf这个ArrayList中存储。

封装这里,这里不想多说了,跟创建NioServerSocketChannel类似,大家可以去回顾一下 Netty源码分析--创建Channel(三)

继续往下看,这里就是循环readBuf,链式执行 管道中的 handler 的 ChannelRead 方法。

根据前面几篇的分析,我们知道 , pipeline 里面又 4 个 handler ,分别是 Head,LoggingHandler,ServerBootstrapAcceptor,Tail,链式调用其中的 ChannelRead  方法,这里我们着重看  ServerBootstrapAcceptor 中个的 ChannelRead  方法。

这里为刚刚的客户端channel 添加了handler,设置了options和childAttrs,注意这里的addLast方法,并没有调用initChannel方法,具体这里添加了什么,我前面几篇有提及,大家可以再回顾一下。

接下来这里呢,就是把客户端channel注册到多路复用器上,跟服务端channel注册的流程是一样的。大家可以去看

Netty源码分析--Channel注册(上)(五)

Netty源码分析--Channel注册(中)(六)

Netty源码分析--Channel注册&绑定端口(下)(七)

我们直接说重点:

注册完成之后,就进入到了 pipeline.invokeHandlerAddedIfNeeded() 方法,我们跟下这个代码。

跟下去我们会进入上图这个execute()方法,如上图,我们看下  ctx

那么链式结构也就是 HeadContext -> NettyServer【ChannelInitializer】(我的启动类) -> TailContext

不断的跟下去,我们发现其实就是去调用当初我们在NettyServer中的initChannel。

那么也就是说,这里才是真正往pipeline中添加handler的过程!!!

神奇的是,后面还有一个remove方法。

那么这个是啥意思呢?我们再来看下ctx的链式结构

也就是说变成了 HeadContext - > NettyServer ->  IdleStateHandler ...等 -> TailContext

大家发现了吗? NettyServer 还在, 也就是  ChannelInitializer 这个handler 还在链上,但是它的作用已经结束了,没错,这里删除的就是它。

怎么删的就不说了,无非就是把 ChannelInitializer 两段的链表直接连接起来,把 ChannelInitializer  剔除就可以了。

接下来就是  pipeline.fireChannelRegistered(); 和 pipeline.fireChannelActive();

就是在所有的handler中链式调用channelRegister 和 channelActive方法。

总结一下:ServerBootstrapAcceptor 才是那个负责接收客户端连接,并且将其注册到多路复用器上的核心类

那么到这里,客户端的接入就完成了,下一篇我们来看,客户端的读写过程以及Netty的内存模型是什么样子的。

原文地址:https://www.cnblogs.com/huxipeng/p/11107407.html

时间: 2024-08-02 09:44:27

Netty源码分析-- 处理客户端接入请求(八)的相关文章

zookeeper源码分析之一客户端发送请求流程

znode 可以被监控,包括这个目录节点中存储的数据的修改,子节点目录的变化等,一旦变化可以通知设置监控的客户端,这个功能是zookeeper对于应用最重要的特性,通过这个特性可以实现的功能包括配置的集中管理,集群管理,分布式锁等等. 知识准备: zookeeper定义的状态有: Unknown (-1),Disconnected (0),NoSyncConnected (1),SyncConnected (3),AuthFailed (4),ConnectedReadOnly (5),Sasl

Netty源码分析之客户端启动过程

一.先来看一下客户端示例代码. 1 public class NettyClientTest { 2 public void connect(int port, String host) throws Exception { 3 EventLoopGroup group = new NioEventLoopGroup();//与服务端不同,客户端只需要一个IO线程组 4 5 try { 6 Bootstrap b = new Bootstrap(); 7 b.group(group) 8 .op

Netty源码分析第3章(客户端接入流程)---->第5节: 监听读事件

Netty源码分析第三章: 客户端接入流程 第五节: 监听读事件 我们回到AbstractUnsafe的register0()方法: private void register0(ChannelPromise promise) { try { //省略代码 //做实际的注册 doRegister(); neverRegistered = false; registered = true; //触发事件 pipeline.invokeHandlerAddedIfNeeded(); safeSetS

Netty源码分析第3章(客户端接入流程)---->第4节: NioSocketChannel注册到selector

Netty源码分析第三章: 客户端接入流程 第四节: NioSocketChannel注册到selector 我们回到最初的NioMessageUnsafe的read()方法: public void read() { //必须是NioEventLoop方法调用的, 不能通过外部线程调用 assert eventLoop().inEventLoop(); //服务端channel的config final ChannelConfig config = config(); //服务端channel

Netty源码分析第3章(客户端接入流程)---->第3节: NioSocketChannel的创建

Netty源码分析第三章: 客户端接入流程 第三节: NioSocketChannel的创建 回到上一小结的read()方法: public void read() { //必须是NioEventLoop方法调用的, 不能通过外部线程调用 assert eventLoop().inEventLoop(); //服务端channel的config final ChannelConfig config = config(); //服务端channel的pipeline final ChannelPi

Netty源码分析--内存模型(上)(十一)

前两节我们分别看了FastThreadLocal和ThreadLocal的源码分析,并且在第八节的时候讲到了处理一个客户端的接入请求,一个客户端是接入进来的,是怎么注册到多路复用器上的.那么这一节我们来一起看下客户端接入完成之后,是怎么实现读写操作的?我们自己想一下,应该就是为刚刚读取的数据分配一块缓冲区,然后把channel中的信息写入到缓冲区中,然后传入到各个handler链上,分别进行处理.那Netty是怎么去分配一块缓冲区的呢?这个就涉及到了Netty的内存模型. 当然,我们在第一节的时

Netty源码分析第4章(pipeline)---->第7节: 前章节内容回顾

Netty源码分析第四章: pipeline 第七节: 前章节内容回顾 我们在第一章和第三章中, 遗留了很多有关事件传输的相关逻辑, 这里带大家一一回顾 首先看两个问题: 1.在客户端接入的时候, NioMessageUnsafe的read方法中pipeline.fireChannelRead(readBuf.get(i))为什么会调用到ServerBootstrap的内部类ServerBootstrapAcceptor中的channelRead()方法 2.客户端handler是什么时候被添加

4. Netty源码分析之Unsafe

Unsafe类实际上是Channel接口的辅助类,实际的IO操作都是由Unsafe接口完成的. 一.Unsafe继承关系图 二.AbstractUnsafe源码分析 1. register方法 register方法主要用于将当前Unsafe对应的Channel注册到EventLoop的多路复用器上,然后调用DefaultChannelPipeline的fireChannelRegisted方法,如果Channel被激活,则调用fireChannelActive方法. public final v

netty 源码分析二

以服务端启动,接收客户端连接整个过程为例分析, 简略分为 五个过程: 1.NioServerSocketChannel 管道生成, 2.NioServerSocketChannel 管道完成初始化, 3.NioServerSocketChannel注册至Selector选择器, 4.NioServerSocketChannel管道绑定到指定端口,启动服务 5.NioServerSocketChannel接受客户端的连接,进行相应IO操作 Ps:netty内部过程远比这复杂,简略记录下方便以后回忆