Netty服务端接收的新连接是如何绑定到worker线程池的？

前言

 

前面分析Netty服务端检测新连接的过程提到了NioServerSocketChannel读完新连接后会循环调用服务端Channel绑定的pipeline.fireChannelRead()方法，将每条新连接打包当做参数传入，然后通过这个方法将其沿着服务端Channel的pipeline传递下去，即在Channel的handler链条上流动，这部分细节后续会详细分解。 

下面看下，新连接在服务端Channel的pipeline的流动过程中，Netty配置的boss线程池和worker线程池是如何配合的。

 

服务器的新连接接入器源码分析

中分析了Netty服务端检测新连接的过程，回忆NioMessageUnsafe类的read()方法源码：

看最后的红色方框，是在循环中将新连接顺着Channel的pipeline传递下去，NioMessageUnsafe是前面说的Netty的Channel的内部接口——Unsafe的服务端的实现类。

那么这些新连接后续被传递时会发生什么呢？这也是重点问题——即Netty客户端新连接的Channel被封装后，如何与Netty的I/O线程关联。下面看之前提到的新连接接入器，关联的功能主要是这个接入器实现。

言归正传看ServerBootstrapAcceptor源码，它是一个内部类，继承了ChannelInboundHandlerAdapter（后面详解Netty的pipeline机制）。

现在先复习一下服务端启动流程。服务端启动的核心操作是绑定端口，即在用户代码中serverBootstrap.bind(xx);方法中启动，里面会调用ServerBootstrap的doBind方法，在doBind方法里调用了ServerBootstrap的initAndRegister()方法，这是一个初始化服务端Channel并注册I/O多路复用器的方法，如下图：

该方法通过反射创建了服务端的NioServerSocketChannel，并且创建保存了JDK的ServerSocketChannel以及一些组件，比如pipeline等，接着执行Channel的初始化操作——即ServerBootstrap的init(channel)方法（分析的是服务端代码，故只看ServerBootstrap类对init的实现），init方法里就有新连接接入器的创建逻辑。如下红框处，在init里配置服务端的pipeline时，默认添加了一个ServerBootstrapAcceptor handler：

先捋一捋完整过程：

1、首先ServerBootstrap的init方法为服务端Channel的pipeline添加了一个ChannelIn