Netty核心概念(5)之Channel

1.前言

 上一节讲了Netty的第一个关键启动类,启动类所做的一些操作,和服务端的channel固定的handler执行过程,谈到了不管是connect还是bind方法最终都是调用了channel的相关方法,此节开始对channel进行说明。channel设置的概念非常多,而且都很重要,先放个NIO的客户端Channel的类结构图。

2.主要概念

2.1 channel

   channel就是直接与操作系统层到交道的数据通道了,可能是java提供的,也可能是通过native方法自己扩展了C++功能的渠道,但是不管哪类,都有一个基础的定义。下面是channel中主要定义的接口方法:

  id():获取该channel的标识

  eventloop():获取该channel注册的线程池

  parent():获取该channel的父channel,NIO没有父channel,一般为null

  config():获取该channel的配置

  isOpen():该channel是否打开状态

  isRegistered():该channel是否注册到线程池中

  isActive():该channel是否可用

  metadata():该channel的元数据

  localAddress():该channel的本地绑定地址端口

  remoteAddress():该channel连接的对端的地址端口

  closeFuture():该channel关闭时触发的future

  isWritable():该channel当前是否可写,只有IO线程会处理可写状态

  bytesBeforeUnwritable():该channel还能写多少字节

  unsafe():获取该channel的unsafe操作对象,对于channel的读写,一般不直接操作channel,而是转交给unsafe对象处理,channel本身通常只做查询状态,获取相关字段内容的操作。

  alloc():获取分配的缓冲区

  read():进行read操作

  write():进行write操作

 上面的方法我们看见了一个不熟悉的unsafe对象,这个也是一个比较重要的概念,理解该类在整个结构所处的位置作用,对于理解框架有较大的帮助。Unsafe被直接定义在Channel接口内部,意味着该接口是与Channel绑定的,上述方法的时候也解释过该类作用。channel本身不直接做相应的工作,交给unsafe方法调用。下图是unsafe的接口定义:

  recvBufAllocHandle():获取处理读取channel数据之后处理的handler

  localAddress():本地地址端口

  remoteAddress():远程地址端口

  register():将channel注册到线程池中

  bind():服务端绑定本地端口

  connect():客户端连接远程端口

  disconnect():断开连接

  close():关闭channel

  closeForcibly():强制关闭

  deregister():移除线程池的注册

  beginRead():准备读取数据

  write():写入数据

  flush():强制刷新

  voidPromise():特殊的promise

  outboundBuffer():获取输出数据的buffer操作类

 看到上面的一系列接口就能够明白,实际操作channel的是unsafe类,但是是直接操作unsafe类吗?比如绑定端口的时候确实调用的是channel.bind方法啊,实际上这里还涉及其它概念,绕了一圈进行操作的。unsafe看名称也应该明白,这个对channel进行操作的类是个线程非安全的类,所以一般通过Netty本身的结构设计,保证线程隔离,才能放心使用。当然如果不自己定义一种IO方式,基本上使用现在Netty封装好的不会有什么问题,如果自己造轮子,这个就要额外注意了。

2.2 ChannelPipeline

 在前面陆续都提到了这个pipeline,本小节就好好聊聊这个类的作用。先不看接口定义,先关注该类在整个结构所处的位置。打开AbstractChannel,仔细研究一下这个类抽象的channel类,你就会有所收获。channel的主要操作方法大部分都是通过pipeline来完成的,如:bind,connect,close,deregister,flush,read,write等。奇怪吗?并不是我们上面说的由unsafe处理。但是这并不矛盾,unsafe是对最底层最基础的处理,我们会有一系列的业务层需要处理,比如bind时对socket的参数设置交由handler处理,所以channel会将相关操作委托给pipeline处理,pipeline经过一系列操作,最后调用unsafe的相关动作,最终回到channel。pipeline翻译是管道,这里感觉更像流水线操作。

 现在再来看pipeline的基本定义就不会觉得突兀了。

 pipline的方法很多,但是分成两大类:1.注册handler;2.使用handler;截图是使用handler的方法,注册handler的方法很多,这里不进行介绍。ChannelPipeline没有那么多的实现类,基础的就是DefaultChannelPipeline,所以直接对该类的部分方法解析。

 1.先是注册handler的方法究竟干了什么,拿例子中使用的addLast()方法为例:

    public final ChannelPipeline addLast(EventExecutorGroup group, String name, ChannelHandler handler) {
        final AbstractChannelHandlerContext newCtx;
        synchronized (this) {
            checkMultiplicity(handler);

            newCtx = newContext(group, filterName(name, handler), handler);

            addLast0(newCtx);

            // If the registered is false it means that the channel was not registered on an eventloop yet.
            // In this case we add the context to the pipeline and add a task that will call
            // ChannelHandler.handlerAdded(...) once the channel is registered.
            if (!registered) {
                newCtx.setAddPending();
                callHandlerCallbackLater(newCtx, true);
                return this;
            }

            EventExecutor executor = newCtx.executor();
            if (!executor.inEventLoop()) {
                newCtx.setAddPending();
                executor.execute(new Runnable() {
                    @Override
                    public void run() {
                        callHandlerAdded0(newCtx);
                    }
                });
                return this;
            }
        }
        callHandlerAdded0(newCtx);
        return this;
    }

 要看懂这段代码还有个内容要注意,tail和head,以及handlerContext(这个是handler相关的概念,这里不进行介绍)。tail和head是pipeline持有的handler头结点和尾结点,看见addLast的时候就应该明白,handler是以链式结构串起来的,在前面也说过,handler是职责链模式,是有先后顺序的。这个方法就是将handler放在职责链尾。中间有个过程,将handler用context包装了,这个不是本节的重点,之后handler章再介绍。

 2.接下来就是pipeline的重点,其是通过什么方式操作channel的,或者说是操作channel的过程是怎样的。

    public final ChannelFuture bind(SocketAddress localAddress) {
        return tail.bind(localAddress);
    }

 基本的channel操作都是通过默认的tail完成的,这些操作有bind,connect,close,deregister,flush,read,write。tail是一个handlerContext,这里会涉及一些handlerContext的内容,简略说下吧:在之前pipeline添加handler的时候,生成了context,context构成了链结构,其知道自己的前后handler是哪个。其他的不细说,最终是通过tail的这个handler不断的早它前一个out类型的handler,最终找到head,看HeadContext类你就会明白了,该类获取了channel的unsafe对象,所有操作都由该对象完成,这样整个环节就连上了。由channel生成channelpipeline和unsafe对象,所有操作交给pipeline,pipeline从tail一直搜索到head,最后由head获取channel的unsafe方法,最终进行相关操作。

 还有一类方法这里也进行介绍一下,牵扯到handlerContext职责链的运行过程,不细讲。

    public final ChannelPipeline fireChannelActive() {
        AbstractChannelHandlerContext.invokeChannelActive(head);
        return this;
    }

 这个从head开始调用

     public void channelActive(ChannelHandlerContext ctx) throws Exception {
            ctx.fireChannelActive();

            readIfIsAutoRead();
        }

 然后又调用了自己的fireChannelActive方法,从head往后找,next的in类型的方法,推动了整个职责链的操作了。所以pipeline的fireChannelActive()方法是起始方法,推动职责链的调用。

3.后记

  channel一共有三个重要的概念:

    1.Channel本身不做事情,将事件都交给ChannelPipeline。

    2.ChannelPipeline本身也不做什么,其主要是控制handler链,由tail查询到head持有unsafe对象,控制channel的连接,读取,写入,提供了由head到tail的直接触发事件链方法fireXXX。

    3.Unsafe是操作channel的最终位置。

  最后附上一个关系图,该图只有一部分,并不完全,不要完全相信:

  

posted @ 2018-04-27 23:05  dark_saber  阅读(2903)  评论(0编辑  收藏  举报