服务端的boss线程是接收请求，work是处理对应每个连接的后续业务处理和IO操作。这块功能的处理机制源码分析如下：
（1）首先是用boss线程进行绑定端口并注册到从boss线程取出来的NioEventLoop对象上，然后NioEventLoop对象会在run方法里无限循环监听Selector的key。
（2）如果有客户端发起连接请求了，监听到连接成功或者读取事件，就会调用unsafe.read()方法，此时是是调用io.netty.channel.nio.AbstractNioMessageChannel.NioMessageUnsafe#read方法，此类对应的会调用实现类io.netty.channel.socket.nio.NioServerSocketChannel#doReadMessages方法。
（3）将接受到的客户端请求SocketChannel对象封装到msg消息里，然后执行pipeline.fireChannelRead方法进行管道传播处理，此时管道处理器里是放置了ServerBootstrapAcceptor方法来处理（此管道是服务端ServerBootstrap在初始化绑定监听时加入的）。
（4）ServerBootstrapAcceptor类的channelRead方法被触发调用，此方法会将接收到的客户端请求SocketChannel对象进行注册到子线程（即work线程池）childGroup.register(child)，后续此条客户端的连接处理都有此子线程的NioEventLoop对象进行调用和处理，直到连接关闭。从而实现了boss线程接受请求到转给work线程进行处理具体的业务逻辑。
附加：
默认情况下，当创建NioEventLoopGroup的时候，如果不指定线程数量，则线程数量默认为CPU核心数*2，基本能符合常规的场景使用，跟可以实际场景来进调试work线程（例如CPU*3、CPU*4）。同时boss线程池，如果只绑定一个端口和ip，一个线程就够用，线程多了只是浪费资源没使用到，故常规的线程池创建时可以这么定义：
EventLoopGroup bossGroup = new NioEventLoopGroup(1); EventLoopGroup workGroup = new NioEventLoopGroup();
