揭秘ServerBootstrap神秘面纱（服务端ServerBootstrap）

课前准备

我在读源码的过程中，有些问题会经常浮现在脑海里。根本原因是自己对于Netty的组件和运行过程不熟悉，所以我把这些问题贴在这里：

1. 服务端openServerSocketChannel()和客户端openSocketChannel()的区别？
2. 服务端newSafe()和客户端newSafe()有什么不一样？
3. Channel的传入参数是OP_ACCEPT,客户端是OP_READ。
4. EventLoopGroup和EventLoop之间的关系是什么？
5. 到底什么是多路复用？
6. reactor，redis 是reactor单线程模式？
7. reactor模式有三种，我们现在的demo用的是主从模式，还是多线程
8. bossGroup和workGroup分别是在哪关联的
9. ServerBootstrapAcceptor的作用？
10. childLoop如何绑定请求过来的channel
11. 我们知道selector轮询服务端是轮询的，客户端轮询吗？
12. 服务端特有参数：
    childHandler / childOption / childAttr 方法（只有服务端ServerBootstrap才有child类型的方法）。
    ——对于服务端而言，有两种通道需要处理， 一种是ServerSocketChannel：用于处理用户连接的accept操作， 另一种是SocketChannel，表示对应客户端连接。而对于客户端，一般都只有一种channel，也就是SocketChannel。客户端和服务端使用的都是NioEventLoop吗？服务端workGroup中的EventLoop是可以绑定客户端来的Channel，那客户端的EventLoop是用来干啥的？
13. 三种reactor模型的区别：
    单线程：acceptor和nio共用一个线程
    多线程:acceptor是单个线程，nio是一个线程池
    主从：acceptor是线程池，nio也是线程池
14. selector的for循环部分，是我们所说的select、epoll中的select模式的代码实现吗？

一、ServerBootstrap惊鸿一瞥

在客户端的代码中，我们对Bootstrap有了一个基本的了解，接下来我们来分析ServerBootstrap。ServerBootstrap和Bootstrap有很多地方是相同的，但我们要尤其注意两者不同的地方。首先来看看服务端的启动代码：

public class RpcRegistry {
    private int port;
    public RpcRegistry(int port) {
        this.port = port;
    }


    private void start() {
        //1.创建对象
        EventLoopGroup bossGroup = new NioEventLoopGroup();
        EventLoopGroup workerGroup = new NioEventLoopGroup();

        try {
            //2.配置参数
            ServerBootstrap server = new ServerBootstrap();
            server.group(bossGroup, workerGroup)
                    .channel(NioServerSocketChannel.class)
                    .childHandler(new ChannelInitializer() {
                        @Override
                        protected void initChannel(Channel ch) throws Exception {
                            //接收课客户端请求的处理流程
                            ChannelPipeline pipeline = ch.pipeline();

                            int fieldLength = 4;
                            //通用解码器设置
                            pipeline.addLast(new LengthFieldBasedFrameDecoder(Integer.MAX_VALUE,0,fieldLength,0,fieldLength));
                            //通用编码器
                            pipeline.addLast(new LengthFieldPrepender(fieldLength));
                            //对象编码器
                            pipeline.addLast("encoder",new ObjectEncoder());
                            //对象解码器
                            pipeline.addLast("decoder",new ObjectDecoder(Integer.MAX_VALUE, ClassResolvers.cacheDisabled(null)));

                            pipeline.addLast(new RegistryHandler());
                        }
                    })
                    .option(ChannelOption.SO_BACKLOG, 128)
                    .childOption(ChannelOption.SO_KEEPALIVE, true);
            //3.启动
            ChannelFuture future = server.bind(this.port).sync();
            System.out.println("GP RPC registry is start,listen at " + this.port);
            future.channel().closeFuture().sync();
        }catch (Exception e){
            e.printStackTrace();
        }finally {
            bossGroup.shutdownGracefully();
            workerGroup.shutdownGracefully();
        }
    }

    public static void main(String[] args) {
        new RpcRegistry(8080).start();
    }

}

和客户端的启动代码相比, 区别不大, 基本上也是进行了如下几个部分的初始化:

1. EventLoopGroup: 不论是服务器端还是客户端, 都必须指定 EventLoopGroup. 在这个例子中, 指定了 NioEventLoopGroup, 表示一个 NIO 的EventLoopGroup, 不过服务器端需要指定两个 EventLoopGroup, 一个是 bossGroup, 用于处理客户端的连接请求; 另一个是 workerGroup, 用于处理与各个客户端连接的 IO 操作.
2. ChannelType: 指定 Channel 的类型. 因为是服务器端, 因此使用了 NioServerSocketChannel.
3. Handler: 设置数据的处理器。

二、NioServerSocketChannel的创建

我们在分析客户端的 Channel 初始化过程时, 已经提到, Channel 是对 Java 底层 Socket 连接的抽象, 并且知道了客户端的 Channel 的具体类型是 NioSocketChannel, 那么自然的, 服务器端的 Channel 类型就是 NioServerSocketChannel 了。接下来我们分析一下服务端启动代码，顺便对比一下服务器端和客户端有哪些不一样的地方。

 我们已经知道了, 在客户端中, Channel 的类型其实是在初始化时, 通过 Bootstrap.channel() 方法设置的, 服务器端自然也不例外.在服务器端, 我们调用了 ServerBootstarap.channel(NioServerSocketChannel.class), 传递了一个 NioServerSocketChannel Class 对象. 这样的话, 按照和分析客户端代码一样的流程, 我们就可以确定, NioServerSocketChannel 的实例化是通过 BootstrapChannelFactory 工厂类来完成的, 而 BootstrapChannelFactory 中的 clazz 字段被设置为了 NioServerSocketChannel.class, 因此当调用 BootstrapChannelFactory.newChannel() 时:

@Override
    public T newChannel() {
        try {
            return clazz.newInstance();
        } catch (Throwable t) {
            throw new ChannelException("Unable to create Channel from class " + clazz, t);
        }
    }

我们来总结一下：

1.  ServerBoostrap的ChannelFactory的实现类是ReflectiveChannelFactory类。
2. 创建的Channel的具体类型是NioServerSocketChannel。

和客户端的代码一样，Channel的实例过程其实就是调用ChannelFactory.newChannel()方法，而实例化的具体类型就是初始化过程中我们传给channel()方法的实参。因此上面服务端实例化出来的Channel类型是NioServerSocketChannel实例。具体过程可以参考前面一篇客户端代码分析。

三、服务端Channel（NioServerSocketChannel）的初始化

在分析NioServerSocketChannel初始化之前，先看下NioServerSocketChannel的类图：

首先，我们在追踪NioServerSocketChannel的默认构造，和NioSocketChannel类似，构造器都是构造newSocket()来打开一个Java的NIO Socket。不过不同的是：客户端的newSocket()调用的是openSocketChannel()，而服务端的newSocket()调用的是openServerSocketChannel()。我们来看看代码：

 

接着调用调用构造方法的重载方法：

我们可以看到在上述方法中，传入的参数是SelectionKey.OP_ACCEPT。还记得客户端传的是什么吗？——是SelectionKey.OP_READ。在服务启动后需要监听客户端连接请求，因此在这里我们设置SelectionKey.OP_ACCEPT，也就是通知selector我们对客户端的连接请求感兴趣。

接着和客户端的分析一下, 会逐级地调用父类的构造器 NioServerSocketChannel <- AbstractNioMessageChannel <- AbstractNioChannel <- AbstractChannel.同样的, 在 AbstractChannel 中会实例化一个 unsafe 和 pipeline：

protected AbstractChannel(Channel parent) {
        this.parent = parent;
        id = newId();
        unsafe = newUnsafe();
        pipeline = newChannelPipeline();
    }

不过, 这里有一点需要注意的是, 客户端的 unsafe 是一个 AbstractNioByteChannel#NioByteUnsafe 的实例, 而在服务器端时, 因为 AbstractNioMessageChannel 重写了newUnsafe 方法:

@Override
    protected AbstractNioUnsafe newUnsafe() {
        return new NioMessageUnsafe();
    }

 因此在服务器端, unsafe 字段其实是一个 AbstractNioMessageChannel#AbstractNioUnsafe 的实例。

最后总结一下，在NioServerSocketChannel实例化过程中的执行逻辑：

1. 调用 NioServerSocketChannel.newSocket(DEFAULT_SELECTOR_PROVIDER) 打开一个新的 Java NIO ServerSocketChannel

2. AbstractChannel(Channel parent) 中初始化 AbstractChannel 的属性：
   parent：属性置为 null
   unsafe：通过newUnsafe() 实例化一个 unsafe 对象, 它的类型是 AbstractNioMessageChannel#AbstractNioUnsafe 内部类

3. AbstractNioChannel 中的属性：
   ch：赋值为Java NIO的ServerSocketChannel，调用NioServerSocketChannel的newSocket()方法获取。
   readInterestOp：默认赋值为SelectionKey.OP_ACCEPT。
   ch设置为非阻塞，调用ch.configureBlocking(false)方法。

4. NioSeverSocketChannel中被赋值的属性：
   ServerSocketChannelConfig config = new NioServerSocketChannelConfig(this, javaChannel().socket())

四、ChannelPipeline初始化

服务器端和客户端的 ChannelPipeline 的初始化一致, 此处不作单独分析了。

五、服务端注册到Selector

服务器端和客户端的 Channel 的注册过程一致, 此处不作单独分析了。

六、bossGroup与workGroup

在客户端的时候，我们只初始化了一个EventLoopGroup 对象，但是在服务端，我们设置了两个EventLoopGroup对象，一个bossGroup，一个workrGroup。他们两个的作用分别是什么呢？我们接下来分析一下。

bossGroup只用于服务端的accept，也就是用于处理客户端的连接请求。下面我们看一下bossGroup和workerGroup之间的关系，如下图：

首先, 服务器端 bossGroup 不断地监听是否有客户端的连接, 当发现有一个新的客户端连接到来时, bossGroup 就会为此连接初始化各项资源, 然后从 workerGroup 中选出一个 EventLoop 绑定到此客户端连接中. 那么接下来的服务器与客户端的交互过程就全部在此分配的 EventLoop 中了。接下来看源码。

首先在ServerBootstrap 初始化时, 调用了 b.group(bossGroup, workerGroup) 设置了两个 EventLoopGroup, 我们跟踪进去看一下:

 显然, 这个方法初始化了两个字段, 一个是 group = parentGroup, 它是在 super.group(parentGroup) 也就是上图中AbstractBootstrap中初始化的, 另一个是childGroup = childGroup。接着从应用程序的启动代码来看，调用了 b.bind()方法来监听一个本地端口。bind()方法会触发如下的调用链：

AbstractBootstrap.bind -> AbstractBootstrap.doBind -> AbstractBootstrap.initAndRegister

 AbstractBootstrap#initAndRegister方法我们已经很熟悉了，在分析客户端代码的时候就跟他打过交道，现在再回顾下吧：

final ChannelFuture initAndRegister() {
    final Channel channel = channelFactory().newChannel();
    ... 省略异常判断
    init(channel);
    ChannelFuture regFuture = group().register(channel);
    return regFuture;
}

这里 group() 方法返回的是上面我们提到的 bossGroup, 而这里的 channel 我们也已经分析过了, 它是一个NioServerSocketChannel 实例, 因此我们可以知道，group().register(channel) 将 bossGroup 和 NioServerSocketChannsl 关联起来了.
那么 workerGroup 是在哪里与 NioSocketChannel 关联的呢?

我们继续看 init(channel) 方法: 

@Override
    void init(Channel channel) throws Exception {
        final Map, Object> options = options0();
        synchronized (options) {
            channel.config().setOptions(options);
        }

        final Map, Object> attrs = attrs0();
        synchronized (attrs) {
            for (Entry, Object> e: attrs.entrySet()) {
                @SuppressWarnings("unchecked")
                AttributeKey