开门见山
之前的文章我们分析了ServerBootstrap、ClientBootstrap、NioServerSocketChannelFactory，也知道了ServerBootstrap和ClientBootstrap都把相关重要逻辑实现都放在了响应的ChannelFactory中了。那么我们这次就来看看NioClientScoketChannelFactory到底有什么秘密，它到底帮助客户端做了一些什么事情。
话不多说，下面我来看下NioClientScoketChannelFactory的构造过程。
NioClientScoketChannelFactory构造过程：
- 初始化两个Pool，一个BossPool，一个WorkerPool，默认使用NioClientBossPool和NioWorkerPool；
- 初始化NioClientSocketPipelineSink
和NioServerSocketChannelFactory是一一对应的，一旦NioClientScoketChannelFactory被构造之后，就启动了BossPool和WorkerPool里面的Boss/Worker线程了。
一个简单的new操作，就启动了Boss和Worker。
ServerBossPool、ClientBossPool和WorkerPool
NioServerSocketChannelFactory和NioClientSocketChannelFactory一样，默认BossPool都是1、WorkerPool的数量都是CPU * 2。
ServerBoss、ClientBoss和Worker流程是一样的
看完ServerBoss、ClientBoss、Worker我们发现这三者流程都是一样的，都继承AbstractNioSelector，内部会打开一个Selector，然后被丢入线程池中运行。区别是每个的run方法执行不同逻辑。
NioServerSocketChannelFactory、NioClientSocketChannelFactory对比
NioServerSocketChannelFactory
- 创建NioServerBossPool，启动1个NioServerBoss
- 创建NioWorkerPool，启动CPU * 2个NioWorker
NioClientSocketChannelFactory
- 创建NioClientBossPool，启动1个NioClientBoss
- 创建NioWorkerPool，启动CPU * 2个NioWoker
生产NioClientSocketChannel来做什么
NioClientSocketChannel构造过程：创建NIO的SocketChannel，触发一个OPEN的Upstream Event，结束，就这样简单。
那么怎么启动客户端来连接服务端呢，那就是调用NioClientSocketChannel的connect()方法。
顺便一提Channel的一些列主动的方法，比如bind、connect等都是触发一个相同类型的Downstream Event，在Pipeline中流转完之后，最终交给ChannelSink去处理。
所有可以这么认为，Channel的一系列动词的方法，就直接去看对应的ChannelSink的处理逻辑。
NioClientSocketChannel对应的是NioClientSocketPipelineSink，NioClientSocketPipelineSink里处理的CONNECTED的Event。
NioClientSocketPipelineSink处理CONNECTED，是直接调用SocketChannel的connect()方法，但是根据执行结果进行两个逻辑：
- 连接成功，提交任务到NioWoker的任务队列
- 连接失败，提交任务给NioClientBoss任务队列，等待连接成功
NioWoker的RegisterTask向Selector注册OP_READ
NioClientBoss的RegisterTask向Selector注册OP_CONNECTED
同一个服务端或者客户端都不需要使用同一个Selector对象？？
总结一下
Channel的connect --------> ChannelSink ------> SocketChannel.connect() ------> NioWorker ------> RegisterTask -------> NIO注册逻辑