netty系列之：channelHandlerContext详解

Posted 2023-05-03

参考技术A 我们知道ChannelHandler有两个非常重要的子接口，分别是ChannelOutboundHandler和ChannelInboundHandler,基本上这两个handler接口定义了所有channel inbound和outbound的处理逻辑。

不管是ChannelHandler还是ChannelOutboundHandler和ChannelInboundHandler，几乎他们中所有的方法都带有一个ChannelHandlerContext参数，那么这个ChannelHandlerContext到底是做什么用的呢？它和handler、channel有什么关系呢？

熟悉netty的朋友应该都接触过ChannelHandlerContext，如果没有的话，这里有一个简单的handler的例子：

这里的handler继承了SimpleChannelInboundHandler，只需要实现对应的方法即可。这里实现的是channelActive方法，在channelActive方法中，传入了一个ChannelHandlerContext参数，我们可以通过使用ChannelHandlerContext来调用它的一些方法。

先来看一下ChannelHandlerContext的定义：

首先ChannelHandlerContext是一个AttributeMap，可以用来存储多个数据。

然后ChannelHandlerContext继承了ChannelInboundInvoker和ChannelOutboundInvoker,可以触发inbound和outbound的一些方法。

除了继承来的一些方法之外，ChannelHandlerContext还可以作为channel，handler和pipline的沟通桥梁，因为可以从ChannelHandlerContext中获取到对应的channel，handler和pipline：

还要注意的是ChannelHandlerContext还返回一个EventExecutor，用来执行特定的任务：

接下来，我们具体看一下ChannelHandlerContext的实现。

AbstractChannelHandlerContext是ChannelHandlerContext的一个非常重要的实现，虽然AbstractChannelHandlerContext是一个抽象类，但是它基本上实现了ChannelHandlerContext的所有功能。

首先看一下AbstractChannelHandlerContext的定义：

AbstractChannelHandlerContext是ChannelHandlerContext的一个具体实现。

通常来说一个handler对应一个ChannelHandlerContext，但是在一个程序中可能会有多于一个handler，那么如何在一个handler中获取其他的handler呢？

在AbstractChannelHandlerContext中有两个同样是AbstractChannelHandlerContext类型的next和prev,从而使得多个AbstractChannelHandlerContext可以构建一个双向链表。从而可以在一个ChannelHandlerContext中，获取其他的ChannelHandlerContext，从而获得handler处理链。

AbstractChannelHandlerContext中的pipeline和executor都是通过构造函数传入的：

可能有朋友会有疑问了，ChannelHandlerContext中的channel和handler是如何得到的呢？

对于channel来说，是通过pipeline来获取的：

对于handler来说，在AbstractChannelHandlerContext中并没有对其进行实现，需要在继承AbstractChannelHandlerContext的类中进行实现。

对于EventExecutor来说,可以通过构造函数向AbstractChannelHandlerContext传入一个新的EventExecutor，如果没有传入或者传入为空的话，则会使用channel中自带的EventLoop:

因为EventLoop继承自OrderedEventExecutor,所以它也是一个EventExecutor。

EventExecutor主要用来异步提交任务来执行,事实上ChannelHandlerContext中几乎所有来自于ChannelInboundInvoker和ChannelOutboundInvoker的方法都是通过EventExecutor来执行的。

对于ChannelInboundInvoker来说，我们以方法fireChannelRegistered为例：

fireChannelRegistered调用了invokeChannelRegistered方法，invokeChannelRegistered则调用EventExecutor的execute方法，将真实的调用逻辑封装在一个runnable类中执行。

注意，在调用executor.execute方法之前有一个executor是否在eventLoop中的判断。如果executor已经在eventLoop中了，那么直接执行任务即可，不需要启用新的线程。

对于ChannelOutboundInvoker来说，我们以bind方法为例，看一下EventExecutor是怎么使用的：

可以看到执行的逻辑和invokeChannelRegistered方法很类似，也是先判断executor在不在eventLoop中，如果在的话直接执行，如果不在则放在executor中执行。

上面的两个例子中都调用了next的相应方法，分别是next.invokeChannelRegistered和next.invokeBind。

我们知道ChannelHandlerContext只是一个封装，它本身并没有太多的业务逻辑，所以next调用的相应方法，实际上是Context中封装的ChannelInboundHandler和ChannelOutboundHandler中的业务逻辑，如下所示：

所以，从AbstractChannelHandlerContext可以得知，ChannelHandlerContext接口中定义的方法都是调用的handler中具体的实现，Context只是对handler的封装。

DefaultChannelHandlerContext是AbstractChannelHandlerContext的一个具体实现。

我们在讲解AbstractChannelHandlerContext的时候提到过，AbstractChannelHandlerContext中并没有定义具体的handler的实现，而这个实现是在DefaultChannelHandlerContext中进行的。

DefaultChannelHandlerContext很简单，我们看一下它的具体实现：

DefaultChannelHandlerContext中额外提供了一个ChannelHandler属性，用来存储传入的ChannelHandler。

到此DefaultChannelHandlerContext可以传入ChannelHandlerContext中一切必须的handler，channel，pipeline和EventExecutor。

本节我们介绍了ChannelHandlerContext和它的几个基本实现，了解到了ChannelHandlerContext是对handler，channel和pipline的封装，ChannelHandlerContext中的业务逻辑，实际上是调用的是底层的handler的对应方法。这也是我们在自定义handler中需要实现的方法。

netty系列之：NIO和netty详解

参考技术A netty为什么快呢？这是因为netty底层使用了JAVA的NIO技术，并在其基础上进行了性能的优化，虽然netty不是单纯的JAVA nio，但是netty的底层还是基于的是nio技术。

nio是JDK1.4中引入的，用于区别于传统的IO，所以nio也可以称之为new io。

nio的三大核心是Selector,channel和Buffer，本文我们将会深入探究NIO和netty之间的关系。

在讲解netty中的NIO实现之前，我们先来回顾一下JDK中NIO的selector，channel是怎么工作的。对于NIO来说selector主要用来接受客户端的连接，所以一般用在server端。我们以一个NIO的服务器端和客户端聊天室为例来讲解NIO在JDK中是怎么使用的。

因为是一个简单的聊天室，我们选择Socket协议为基础的ServerSocketChannel,首先就是open这个Server channel:

然后向server channel中注册selector:

虽然是NIO，但是对于Selector来说，它的select方法是阻塞方法，只有找到匹配的channel之后才会返回，为了多次进行select操作，我们需要在一个while循环里面进行selector的select操作：

selector中会有一些SelectionKey,SelectionKey中有一些表示操作状态的OP Status,根据这个OP Status的不同，selectionKey可以有四种状态，分别是isReadable,isWritable,isConnectable和isAcceptable。

当SelectionKey处于isAcceptable状态的时候，表示ServerSocketChannel可以接受连接了，我们需要调用register方法将serverSocketChannel accept生成的socketChannel注册到selector中，以监听它的OP READ状态，后续可以从中读取数据：

当selectionKey处于isReadable状态的时候，表示可以从socketChannel中读取数据然后进行处理：

上面的serverResponse方法中，从selectionKey中拿到对应的SocketChannel，然后调用SocketChannel的read方法，将channel中的数据读取到byteBuffer中，要想回复消息到channel中，还是使用同一个socketChannel，然后调用write方法回写消息给client端，到这里一个简单的回写客户端消息的server端就完成了。

接下来就是对应的NIO客户端，在NIO客户端需要使用SocketChannel,首先建立和服务器的连接：

然后就可以使用这个channel来发送和接受消息了：

向channel中写入消息可以使用write方法，从channel中读取消息可以使用read方法。

这样一个NIO的客户端就完成了。

虽然以上是NIO的server和client的基本使用，但是基本上涵盖了NIO的所有要点。接下来我们来详细了解一下netty中NIO到底是怎么使用的。

以netty的ServerBootstrap为例，启动的时候需要指定它的group,先来看一下ServerBootstrap的group方法：

ServerBootstrap可以接受一个EventLoopGroup或者两个EventLoopGroup，EventLoopGroup被用来处理所有的event和IO，对于ServerBootstrap来说，可以有两个EventLoopGroup，对于Bootstrap来说只有一个EventLoopGroup。两个EventLoopGroup表示acceptor group和worker group。

EventLoopGroup只是一个接口，我们常用的一个实现就是NioEventLoopGroup,如下所示是一个常用的netty服务器端代码：

这里和NIO相关的有两个类，分别是NioEventLoopGroup和NioServerSocketChannel，事实上在他们的底层还有两个类似的类分别叫做NioEventLoop和NioSocketChannel，接下来我们分别讲解一些他们的底层实现和逻辑关系。

NioEventLoopGroup和DefaultEventLoopGroup一样都是继承自MultithreadEventLoopGroup：

他们的不同之处在于newChild方法的不同，newChild用来构建Group中的实际对象，NioEventLoopGroup来说，newChild返回的是一个NioEventLoop对象，先来看下NioEventLoopGroup的newChild方法：

这个newChild方法除了固定的executor参数之外，还可以根据NioEventLoopGroup的构造函数传入的参数来实现更多的功能。

这里参数中传入了SelectorProvider、SelectStrategyFactory、RejectedExecutionHandler、taskQueueFactory和tailTaskQueueFactory这几个参数，其中后面的两个EventLoopTaskQueueFactory并不是必须的。

最后所有的参数都会传递给NioEventLoop的构造函数用来构造出一个新的NioEventLoop。

在详细讲解NioEventLoop之前，我们来研读一下传入的这几个参数类型的实际作用。

SelectorProvider是JDK中的类，它提供了一个静态的provider()方法可以从Property或者ServiceLoader中加载对应的SelectorProvider类并实例化。

另外还提供了openDatagramChannel、openPipe、openSelector、openServerSocketChannel和openSocketChannel等实用的NIO操作方法。

SelectStrategyFactory是一个接口，里面只定义了一个方法，用来返回SelectStrategy:

什么是SelectStrategy呢？

先看下SelectStrategy中定义了哪些Strategy:

SelectStrategy中定义了3个strategy,分别是SELECT、CONTINUE和BUSY_WAIT。

我们知道一般情况下，在NIO中select操作本身是一个阻塞操作，也就是block操作，这个操作对应的strategy是SELECT,也就是select block状态。

如果我们想跳过这个block，重新进入下一个event loop,那么对应的strategy就是CONTINUE。

BUSY_WAIT是一个特殊的strategy，是指IO 循环轮询新事件而不阻塞,这个strategy只有在epoll模式下才支持，NIO和Kqueue模式并不支持这个strategy。

RejectedExecutionHandler是netty自己的类，和 java.util.concurrent.RejectedExecutionHandler类似，但是是特别针对SingleThreadEventExecutor来说的。这个接口定义了一个rejected方法，用来表示因为SingleThreadEventExecutor容量限制导致的任务添加失败而被拒绝的情况：

EventLoopTaskQueueFactory是一个接口，用来创建存储提交给EventLoop的taskQueue：

这个Queue必须是线程安全的，并且继承自java.util.concurrent.BlockingQueue.

讲解完这几个参数，接下来我们就可以详细查看NioEventLoop的具体NIO实现了。

首先NioEventLoop和DefaultEventLoop一样，都是继承自SingleThreadEventLoop：

表示的是使用单一线程来执行任务的EventLoop。

首先作为一个NIO的实现，必须要有selector，在NioEventLoop中定义了两个selector，分别是selector和unwrappedSelector：

在NioEventLoop的构造函数中，他们是这样定义的：

首先调用openSelector方法，然后通过返回的SelectorTuple来获取对应的selector和unwrappedSelector。

这两个selector有什么区别呢？

在openSelector方法中，首先通过调用provider的openSelector方法返回一个Selector，这个Selector就是unwrappedSelector：

然后检查DISABLE_KEY_SET_OPTIMIZATION是否设置，如果没有设置那么unwrappedSelector和selector实际上是同一个Selector：

DISABLE_KEY_SET_OPTIMIZATION表示的是是否对select key set进行优化:

如果DISABLE_KEY_SET_OPTIMIZATION被设置为false，那么意味着我们需要对select key set进行优化，具体是怎么进行优化的呢？

先来看下最后的返回：

最后返回的SelectorTuple第二个参数就是selector，这里的selector是一个SelectedSelectionKeySetSelector对象。

SelectedSelectionKeySetSelector继承自selector，构造函数传入的第一个参数是一个delegate,所有的Selector中定义的方法都是通过调用
delegate来实现的，不同的是对于select方法来说，会首先调用selectedKeySet的reset方法,下面是以isOpen和select方法为例观察一下代码的实现：

selectedKeySet是一个SelectedSelectionKeySet对象，是一个set集合，用来存储SelectionKey，在openSelector()方法中，使用new来实例化这个对象：

netty实际是想用这个SelectedSelectionKeySet类来管理Selector中的selectedKeys，所以接下来netty用了一个高技巧性的对象替换操作。

首先判断系统中有没有sun.nio.ch.SelectorImpl的实现：

SelectorImpl中有两个Set字段：

这两个字段就是我们需要替换的对象。如果有SelectorImpl的话，首先使用Unsafe类，调用PlatformDependent中的objectFieldOffset方法拿到这两个字段相对于对象示例的偏移量，然后调用putObject将这两个字段替换成为前面初始化的selectedKeySet对象：

如果系统设置不支持Unsafe，那么就用反射再做一次：

还记得前面我们提到的selectStrategy吗？run方法通过调用selectStrategy.calculateStrategy返回了select的strategy，然后通过判断
strategy的值来进行对应的处理。

如果strategy是CONTINUE，这跳过这次循环，进入到下一个loop中。

BUSY_WAIT在NIO中是不支持的，如果是SELECT状态，那么会在curDeadlineNanos之后再次进行select操作：

如果strategy > 0,表示有拿到了SelectedKeys,那么需要调用processSelectedKeys方法对SelectedKeys进行处理：

上面提到了NioEventLoop中有两个selector，还有一个selectedKeys属性，这个selectedKeys存储的就是Optimized SelectedKeys，如果这个值不为空，就调用processSelectedKeysOptimized方法，否则就调用processSelectedKeysPlain方法。

processSelectedKeysOptimized和processSelectedKeysPlain这两个方法差别不大，只是传入的要处理的selectedKeys不同。

处理的逻辑是首先拿到selectedKeys的key，然后调用它的attachment方法拿到attach的对象：

如果channel还没有建立连接，那么这个对象可能是一个NioTask,用来处理channelReady和channelUnregistered的事件。

如果channel已经建立好连接了，那么这个对象可能是一个AbstractNioChannel。

针对两种不同的对象，会去分别调用不同的processSelectedKey方法。

对第一种情况，会调用task的channelReady方法：

对第二种情况，会根据SelectionKey的readyOps()的各种状态调用ch.unsafe()中的各种方法，去进行read或者close等操作。

NioEventLoop虽然也是一个SingleThreadEventLoop,但是通过使用NIO技术，可以更好的利用现有资源实现更好的效率，这也就是为什么我们在项目中使用NioEventLoopGroup而不是DefaultEventLoopGroup的原因。