Netty服务端启动流程源码剖析

前记

哈喽，自从上篇《Netty之旅二：口口相传的高性能Netty到底是什么？》后，迟迟两周才开启明天的Netty源码系列。源码剖析的第一篇文章，下一篇我会分享客户端的启动过程源码剖析。通过源码的浏览，咱们将会晓得，Netty 服务端启动的调用链是十分长的，同时必定也会发现一些新的问题，随着咱们源码浏览的不断深入，置信这些问题咱们也会一一攻破。

废话不多说，间接上号！

一、从EchoServer示例动手

示例从哪里来？任何开源框架都会有本人的示例代码，Netty源码也不例外，如模块netty-example中就包含了最常见的EchoServer示例，上面通过这个示例进入服务端启动流程篇章。

public final class EchoServer {    static final boolean SSL = System.getProperty("ssl") != null;    static final int PORT = Integer.parseInt(System.getProperty("port", "8007"));    public static void main(String[] args) throws Exception {        // Configure SSL.        final SslContext sslCtx;        if (SSL) {            SelfSignedCertificate ssc = new SelfSignedCertificate();            sslCtx = SslContextBuilder.forServer(ssc.certificate(), ssc.privateKey()).build();        } else {            sslCtx = null;        }        // 1. 申明Main-Sub Reactor模式线程池:EventLoopGroup        // Configure the server.        EventLoopGroup bossGroup = new NioEventLoopGroup(1);        EventLoopGroup workerGroup = new NioEventLoopGroup();        // 创立 EchoServerHandler 对象        final EchoServerHandler serverHandler = new EchoServerHandler();        try {            // 2. 申明服务端启动疏导器,并设置相干属性            ServerBootstrap b = new ServerBootstrap();            b.group(bossGroup, workerGroup)             .channel(NioServerSocketChannel.class)             .option(ChannelOption.SO_BACKLOG, 100)             .handler(new LoggingHandler(LogLevel.INFO))             .childHandler(new ChannelInitializer<SocketChannel>() {                 @Override                 public void initChannel(SocketChannel ch) throws Exception {                     ChannelPipeline p = ch.pipeline();                     if (sslCtx != null) {                         p.addLast(sslCtx.newHandler(ch.alloc()));                     }                     //p.addLast(new LoggingHandler(LogLevel.INFO));                     p.addLast(serverHandler);                 }             });            // 3. 绑定端口即启动服务端，并同步期待            // Start the server.            ChannelFuture f = b.bind(PORT).sync();            // 4. 监听服务端敞开，并阻塞期待            // Wait until the server socket is closed.            f.channel().closeFuture().sync();        } finally {            // 5. 优雅地敞开两个EventLoopGroup线程池             // Shut down all event loops to terminate all threads.            bossGroup.shutdownGracefully();            workerGroup.shutdownGracefully();        }    }}
  1. [代码行18、19]申明Main-Sub Reactor模式线程池:EventLoopGroup

    创立两个 EventLoopGroup 对象。其中，bossGroup用于服务端承受客户端的连贯，workerGroup用于进行客户端的 SocketChannel 的数据读写。

    (<u>对于EventLoopGroup不是本文重点所以在后续文章中进行剖析</u>)

  2. [代码行23-39]申明服务端启动疏导器,并设置相干属性

    AbstractBootstrap是一个帮忙类，通过办法链（method chaining）的形式，提供了一个简略易用的形式来配置启动一个Channel。io.netty.bootstrap.ServerBootstrap ，实现 AbstractBootstrap 抽象类，用于 Server 的启动器实现类。io.netty.bootstrap.Bootstrap ，实现 AbstractBootstrap 抽象类，用于 Client 的启动器实现类。如下类图所示：

    (<u>在EchoServer示例代码中，咱们看到 ServerBootstrap 的 group、channel、option、childHandler 等属性链式设置都放到对于AbstractBootstrap体系代码中具体介绍。</u>)

  3. [代码行43]绑定端口即启动服务端，并同步期待

    先调用 #bind(int port) 办法，绑定端口，后调用 ChannelFuture#sync() 办法，阻塞期待胜利。对于bind操作就是本文要具体介绍的"服务端启动流程"。

  4. [代码行47]监听服务端敞开，并阻塞期待

    先调用 #closeFuture() 办法，监听服务器敞开，后调用 ChannelFuture#sync() 办法，阻塞期待胜利。 留神，此处不是敞开服务器，而是channel的监听敞开。

  5. [代码行51、52]优雅地敞开两个EventLoopGroup线程池

    finally代码块中执行阐明服务端将最终敞开，所以调用 EventLoopGroup#shutdownGracefully() 办法，别离敞开两个 EventLoopGroup 对象，终止所有线程。

二、服务启动过程

在服务启动过程的源码剖析之前，这里回顾一下咱们在通过JDK NIO编程在服务端启动初始的代码：

 serverSocketChannel = ServerSocketChannel.open(); serverSocketChannel.configureBlocking(false); serverSocketChannel.socket().bind(new InetSocketAddress(port), 1024); selector = Selector.open(); serverSocketChannel.register(selector, SelectionKey.OP_ACCEPT);

这5行代码标示一个最为相熟的过程：

  • 关上serverSocketChannel
  • 配置非阻塞模式
  • 为channel的socket绑定监听端口
  • 创立Selector
  • 将serverSocketChannel注册到 selector

前面等剖析完Netty的启动过程后，会对这些步骤有一个新的意识。在EchoServer示例中，进入 #bind(int port) 办法，AbstractBootstrap#bind()其实有多个办法，不便不同地址参数的传递，理论调用的办法是AbstractBootstrap#doBind(final SocketAddress localAddress) 办法，代码如下：

private ChannelFuture doBind(final SocketAddress localAddress) {        final ChannelFuture regFuture = initAndRegister();        final Channel channel = regFuture.channel();        if (regFuture.cause() != null) {            return regFuture;        }        if (regFuture.isDone()) {            // At this point we know that the registration was complete and successful.            ChannelPromise promise = channel.newPromise();            doBind0(regFuture, channel, localAddress, promise);            return promise;        } else {            // Registration future is almost always fulfilled already, but just in case it's not.            final PendingRegistrationPromise promise = new PendingRegistrationPromise(channel);            regFuture.addListener(new ChannelFutureListener() {                @Override                public void operationComplete(ChannelFuture future) throws Exception {                    Throwable cause = future.cause();                    if (cause != null) {                        // Registration on the EventLoop failed so fail the ChannelPromise directly to not cause an                        // IllegalStateException once we try to access the EventLoop of the Channel.                        promise.setFailure(cause);                    } else {                        // Registration was successful, so set the correct executor to use.                        // See https://github.com/netty/netty/issues/2586                        promise.registered();                        doBind0(regFuture, channel, localAddress, promise);                    }                }            });            return promise;        }}
  • [代码行2] ：调用 #initAndRegister() 办法，初始化并注册一个 Channel 对象。因为注册是异步的过程，所以返回一个 ChannelFuture 对象。具体解析，见 「initAndRegister()」。
  • [代码行4-6]]：若产生异样，间接进行返回。

  • [代码行9-34]：因为注册是异步的过程，有可能已实现，有可能未实现。所以实现代码分成了【第 10 至 14 行】和【第 15 至 36 行】别离解决已实现和未实现的状况。

    • 外围在[第 11 、29行]，调用 #doBind0(final ChannelFuture regFuture, final Channel channel, final SocketAddress localAddress, final ChannelPromise promise) 办法，绑定 Channel 的端口，并注册 Channel 到 SelectionKey 中。
    • 如果异步注册对应的 ChanelFuture 未实现，则调用 ChannelFuture#addListener(ChannelFutureListener) 办法，增加监听器，在注册实现后，进行回调执行 #doBind0(...) 办法的逻辑。

通过doBind办法能够晓得服务端启动流程大抵如下几个步骤：

1. 创立Channel

从#doBind(final SocketAddress localAddress)进入到initAndRegister():

 final ChannelFuture initAndRegister() {     Channel channel = null;     try {         channel = channelFactory.newChannel();         init(channel);     } catch (Throwable t) {         if (channel != null) {             // channel can be null if newChannel crashed (eg SocketException("too many open files"))             channel.unsafe().closeForcibly();             // as the Channel is not registered yet we need to force the usage of the GlobalEventExecutor             return new DefaultChannelPromise(channel, GlobalEventExecutor.INSTANCE).setFailure(t);         }         // as the Channel is not registered yet we need to force the usage of the GlobalEventExecutor         return new DefaultChannelPromise(new FailedChannel(), GlobalEventExecutor.INSTANCE).setFailure(t);     }     ChannelFuture regFuture = config().group().register(channel);     if (regFuture.cause() != null) {         if (channel.isRegistered()) {             channel.close();         } else {             channel.unsafe().closeForcibly();         }     }     return regFuture;}

[代码行4]调用 ChannelFactory#newChannel() 办法，创立 Channel 对象。 ChannelFactory类继承如下：

能够在ChannelFactory正文看到@deprecated Use {@link io.netty.channel.ChannelFactory} instead.，这里只是包名的调整，对于继承构造不变。netty默认应用ReflectiveChannelFactory，咱们能够看到重载办法：

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

很显著，正如其名是通过反射机制结构Channel对象实例的。constructor是在其构造方法初始化的：this.constructor = clazz.getConstructor();这个clazz按理说应该是咱们要创立的Channel的Class对象。那Class对象是什么呢？咱们接着看channelFactory是怎么初始化的。

首先在AbstractBootstrap找到如下代码：

@Deprecatedpublic B channelFactory(ChannelFactory<? extends C> channelFactory) {    ObjectUtil.checkNotNull(channelFactory, "channelFactory");    if (this.channelFactory != null) {        throw new IllegalStateException("channelFactory set already");    }    this.channelFactory = channelFactory;    return self();}

调用这个办法的递推向上看到：

public B channel(Class<? extends C> channelClass) {    return channelFactory(new ReflectiveChannelFactory<C>(        ObjectUtil.checkNotNull(channelClass, "channelClass")    ));}

这个办法正是在EchoServer中ServerBootstrap链式设置时调用.channel(NioServerSocketChannel.class)的办法。咱们看到，channelClass就是NioServerSocketChannel.class，channelFactory也是以ReflectiveChannelFactory作为具体实例，并且将NioServerSocketChannel.class作为结构参数传递初始化的，所以这答复了反射机制结构的是io.netty.channel.socket.nio.NioServerSocketChannel对象。

持续看NioServerSocketChannel构造方法逻辑做了什么事件，看之前先给出NioServerSocketChannel类继承关系：

NioServerSocketChannel与NioSocketChannel别离对应服务端和客户端，公共父类都是AbstractNioChannel和AbstractChannel，上面介绍创立过程能够参照这个Channel类继承图。进入NioServerSocketChannel构造方法：

/**  * Create a new instance  */public NioServerSocketChannel() {    this(newSocket(DEFAULT_SELECTOR_PROVIDER));}

点击newSocket进去：

private static ServerSocketChannel newSocket(SelectorProvider provider) {    try {        /**          *  Use the {@link SelectorProvider} to open {@link SocketChannel} and so remove condition in          *  {@link SelectorProvider#provider()} which is called by each ServerSocketChannel.open() otherwise.          *          *  See <a href="https://github.com/netty/netty/issues/2308">#2308</a>.          */        return provider.openServerSocketChannel();    } catch (IOException e) {        throw new ChannelException(            "Failed to open a server socket.", e);    }}

以上传进来的provider是DEFAULT_SELECTOR_PROVIDER即默认的java.nio.channels.spi.SelectorProvider，[代码行9]就是相熟的jdk nio创立ServerSocketChannel。这样newSocket(DEFAULT_SELECTOR_PROVIDER)就返回了后果ServerSocketChannel，回到NioServerSocketChannel()#this()点进去：

/**  * Create a new instance using the given {@link ServerSocketChannel}.  */public NioServerSocketChannel(ServerSocketChannel channel) {    super(null, channel, SelectionKey.OP_ACCEPT);    config = new NioServerSocketChannelConfig(this, javaChannel().socket());}

以上super代表父类AbstractNioMessageChannel构造方法，点进去看到：

 /**   * @see AbstractNioChannel#AbstractNioChannel(Channel, SelectableChannel, int)   */protected AbstractNioMessageChannel(Channel parent, SelectableChannel ch, int readInterestOp) {    super(parent, ch, readInterestOp);}

以上super代表父类AbstractNioChannel构造方法，点进去看到：

 protected AbstractNioChannel(Channel parent, SelectableChannel ch, int readInterestOp) {     super(parent);     this.ch = ch;     this.readInterestOp = readInterestOp;     try {         ch.configureBlocking(false);     } catch (IOException e) {         try {             ch.close();         } catch (IOException e2) {             if (logger.isWarnEnabled()) {                 logger.warn("Failed to close a partially initialized socket.", e2);             }         }         throw new ChannelException("Failed to enter non-blocking mode.", e);     }}

以上[代码行3]将ServerSocketChannel保留到了AbstractNioChannel#ch成员变量，在下面提到的NioServerSocketChannel构造方法的[代码行6]javaChannel()拿到的就是ch保留的ServerSocketChannel变量。

以上[代码行6]就是相熟的jdk nio编程设置ServerSocketChannel非阻塞形式。这里还有super父类构造方法，点击进去看到：

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

以上构造方法中：

  • parent 属性，代表父 Channel 对象。对于 NioServerSocketChannel 的 parent 为null。
  • id 属性，Channel 编号对象。在构造方法中，通过调用 #newId() 办法进行创立。（<u>这里不细开展Problem-1</u>）
  • unsafe 属性，Unsafe 对象。因为Channel 真正的具体操作，是通过调用对应的 Unsafe 对象施行。所以须要在构造方法中，通过调用 #newUnsafe() 办法进行创立。这里的 Unsafe 并不是咱们常说的 jdk自带的sun.misc.Unsafe ，而是 io.netty.channel.Channel#Unsafe。（<u>这里不细开展Problem-2</u>）
  • pipeline属性默认是DefaultChannelPipeline对象，赋值后在前面为channel绑定端口的时候会用到

通过以上创立channel源码过程剖析，总结的流程时序图如下：

2. 初始化Channel

回到一开始创立Channel的initAndRegister()入口办法，在创立Channel后紧接着init(channel)进入初始化流程，因为是服务端初始化，所以是ServerBootstrap#init(Channel channel)，代码如下：

@Overridevoid init(Channel channel) throws Exception {    final Map<ChannelOption<?>, Object> options = options0();    synchronized (options) {        setChannelOptions(channel, options, logger);    }    final Map<AttributeKey<?>, Object> attrs = attrs0();    synchronized (attrs) {        for (Entry<AttributeKey<?>, Object> e: attrs.entrySet()) {            @SuppressWarnings("unchecked")            AttributeKey<Object> key = (AttributeKey<Object>) e.getKey();            channel.attr(key).set(e.getValue());        }    }    ChannelPipeline p = channel.pipeline();    final EventLoopGroup currentChildGroup = childGroup;    final ChannelHandler currentChildHandler = childHandler;    final Entry<ChannelOption<?>, Object>[] currentChildOptions;    final Entry<AttributeKey<?>, Object>[] currentChildAttrs;    synchronized (childOptions) {        currentChildOptions = childOptions.entrySet().toArray(newOptionArray(0));    }    synchronized (childAttrs) {        currentChildAttrs = childAttrs.entrySet().toArray(newAttrArray(0));    }    p.addLast(new ChannelInitializer<Channel>() {        @Override        public void initChannel(final Channel ch) throws Exception {            final ChannelPipeline pipeline = ch.pipeline();            ChannelHandler handler = config.handler();            if (handler != null) {                pipeline.addLast(handler);            }            ch.eventLoop().execute(new Runnable() {                @Override                public void run() {                    pipeline.addLast(new ServerBootstrapAcceptor(                        ch, currentChildGroup, currentChildHandler, currentChildOptions, currentChildAttrs));                }            });        }    });}
  • [代码 3 - 6 行]： options0()办法返回的options保留了用户在EchoServer中设置自定义的可选项汇合，这样ServerBootstrap将配置的选项汇合，设置到了 Channel 的可选项汇合中。
  • [代码 8 - 15 行]： attrs0()办法返回的attrs保留了用户在EchoServer中设置自定义的属性汇合，这样ServerBootstrap将配置的属性汇合，设置到了 Channel 的属性汇合中。
  • [代码21-28行]：通过局部变量currentChildOptions和currentChildAttrs保留了用户自定义的childOptions和childAttrs，用于[代码43行] ServerBootstrapAcceptor 构造方法。

  • [代码30-47]]：创立ChannelInitializer 对象，增加到 pipeline 中，用于后续初始化 ChannelHandler 到 pipeline 中,包含用户在EchoServer配置的LoggingHandler和创立的创立 ServerBootstrapAcceptor 对象。

    • [代码行34-37]：增加启动器配置的 LoggingHandler到pipeline 中。
    • [代码行39-45]：创立 ServerBootstrapAcceptor 对象，增加到 pipeline 中。从名字上就可以看进去，ServerBootstrapAcceptor 也是一个 ChannelHandler 实现类，专门用于承受客户端的新连贯申请，把新的申请扔给某个事件循环器，咱们先不做过多剖析。咱们发现是应用EventLoop.execute 执行增加的过程，这是为什么呢？同样记录问题(<u>Problem-</u>3)
    • 须要阐明的是pipeline 在之前介绍Netty外围组件的时候提到是一个蕴含ChannelHandlerContext的双向链表，每一个context对于惟一一个ChannelHandler，这里初始化后，ChannelPipeline里就是如下一个构造：

3. 注册Channel

初始化Channel一些根本配置和属性结束后，回到一开始创立Channel的initAndRegister()入口办法，在初始化Channel后紧接着[代码行17] ChannelFuture regFuture = config().group().register(channel);显著这里是通过EventLoopGroup进入注册流程(EventLoopGroup体系将在后续文章解说)

在EchoServer中启动器同样通过ServerBootstrap#group()设置了NioEventLoopGroup，它继承自MultithreadEventLoopGroup，所以注册流程会进入MultithreadEventLoopGroup重载的register(Channel channel)办法，代码如下：

@Overridepublic ChannelFuture register(Channel channel) {    return next().register(channel);}

这里会调用 next() 办法抉择进去一个 EventLoop 来注册 Channel，外面实际上应用的是一个叫做 EventExecutorChooser 的货色来抉择，它实际上又有两种实现形式 ——PowerOfTwoEventExecutorChooser 和 GenericEventExecutorChooser，实质上就是从 EventExecutor 数组中抉择一个 EventExecutor，咱们这里就是 NioEventLoop，那么，它们有什么区别呢？（<u>Problem-4:在介绍EventLoopGroup体系的后续文章中将会具体解说，这里简略地提一下，实质都是按数组长度取余数 ，不过，2 的 N 次方的模式更高效。</u>）

接着，来到 NioEventLoop 的 register(channel) 办法，你会不会问找不到该办法？提醒NioEventLoop 继承SingleThreadEventLoop，所以父类办法：

@Overridepublic ChannelFuture register(Channel channel) {    return register(new DefaultChannelPromise(channel, this));}@Overridepublic ChannelFuture register(final ChannelPromise promise) {    ObjectUtil.checkNotNull(promise, "promise");    promise.channel().unsafe().register(this, promise);    return promise;}

能够看到，先创立了一个叫做 ChannelPromise 的货色，它是 ChannelFuture 的子类。[代码行9]又调回了 Channel 的 Unsafe 的 register () 办法，这里第一个参数是 this，也就是 NioEventLoop，第二个参数是刚创立的 ChannelPromise。

点击 AbstractUnsafe#register(EventLoop eventLoop, final ChannelPromise promise) 办法进去，代码如下：

 public final void register(EventLoop eventLoop, final ChannelPromise promise) {     if (eventLoop == null) {         throw new NullPointerException("eventLoop");     }     if (isRegistered()) {         promise.setFailure(new IllegalStateException("registered to an event loop already"));         return;     }     if (!isCompatible(eventLoop)) {         promise.setFailure(             new IllegalStateException("incompatible event loop type: " + eventLoop.getClass().getName()));         return;     }     AbstractChannel.this.eventLoop = eventLoop;     if (eventLoop.inEventLoop()) {         register0(promise);     } else {         try {             eventLoop.execute(new Runnable() {                 @Override                 public void run() {                     register0(promise);                 }             });         } catch (Throwable t) {             logger.warn(                 "Force-closing a channel whose registration task was not accepted by an event loop: {}",                 AbstractChannel.this, t);             closeForcibly();             closeFuture.setClosed();             safeSetFailure(promise, t);         }     }}

[代码行15]这行代码是设置 Channel 的 eventLoop 属性。这行后面的代码次要是在校验传入的 eventLoop 参数非空，校验是否有注册过以及校验 Channel 和 eventLoop 类型是否匹配。

[代码18、24]接着，跟踪到 AbstractUnsafe#register0(ChannelPromise promise) 办法中：

private void register0(ChannelPromise promise) {    try {        // check if the channel is still open as it could be closed in the mean time when the register        // call was outside of the eventLoop        if (!promise.setUncancellable() || !ensureOpen(promise)) {            return;        }        boolean firstRegistration = neverRegistered;        doRegister();        neverRegistered = false;        registered = true;        // Ensure we call handlerAdded(...) before we actually notify the promise. This is needed as the        // user may already fire events through the pipeline in the ChannelFutureListener.        pipeline.invokeHandlerAddedIfNeeded();        safeSetSuccess(promise);        pipeline.fireChannelRegistered();        // Only fire a channelActive if the channel has never been registered. This prevents firing        // multiple channel actives if the channel is deregistered and re-registered.        if (isActive()) {            if (firstRegistration) {                pipeline.fireChannelActive();            } else if (config().isAutoRead()) {                // This channel was registered before and autoRead() is set. This means we need to begin read                // again so that we process inbound data.                //                // See https://github.com/netty/netty/issues/4805                beginRead();            }        }    } catch (Throwable t) {        // Close the channel directly to avoid FD leak.        closeForcibly();        closeFuture.setClosed();        safeSetFailure(promise, t);    }}

[代码行9]进入 AbstractNioChannel#doRegister() 办法：

protected void doRegister() throws Exception {    boolean selected = false;    for (;;) {        try {            selectionKey = javaChannel().register(eventLoop().unwrappedSelector(), 0, this);            return;        } catch (CancelledKeyException e) {            if (!selected) {                // Force the Selector to select now as the "canceled" SelectionKey may still be                // cached and not removed because no Select.select(..) operation was called yet.                eventLoop().selectNow();                selected = true;            } else {                // We forced a select operation on the selector before but the SelectionKey is still cached                // for whatever reason. JDK bug ?                throw e;            }        }    }}

[代码行5]要害一行代码，将 Java 原生 NIO Selector 与 Java 原生 NIO 的 Channel 对象(ServerSocketChannel) 绑定在一起，并将以后 Netty 的 Channel 通过 attachment 的模式绑定到 SelectionKey 上:

  • 调用 #unwrappedSelector() 办法，返回 Java 原生 NIO Selector 对象，而且每个 NioEventLoop 与 Selector 唯一一对应。
  • 调用 SelectableChannel#register(Selector sel, int ops, Object att) 办法，注册 Java 原生NIO 的 Channel 对象到 NIO Selector 对象上。

通过以上注册channel源码剖析，总结流程的时序图如下：

4. 绑定端口

注册完Channel最初回到AbstractBootstrap#doBind() 办法，剖析 Channel 的端口绑定逻辑。进入doBind0代码如下：

private static void doBind0(    final ChannelFuture regFuture, final Channel channel,    final SocketAddress localAddress, final ChannelPromise promise) {    // This method is invoked before channelRegistered() is triggered.  Give user handlers a chance to set up    // the pipeline in its channelRegistered() implementation.    channel.eventLoop().execute(new Runnable() {        @Override        public void run() {            if (regFuture.isSuccess()) {                channel.bind(localAddress, promise).addListener(ChannelFutureListener.CLOSE_ON_FAILURE);            } else {                promise.setFailure(regFuture.cause());            }        }    });}
  • [代码行7]：在后面Channel 注册胜利的条件下，调用 EventLoop执行 Channel 的端口绑定逻辑。然而，实际上以后线程曾经是 EventLoop所在的线程了，为何还要这样操作呢？答案在【第 5 至 6 行】的英语正文，这里作为一个问题记着(<u>Problem-5</u>)。
  • [代码行11]：进入AbstractChannel#bind(SocketAddress localAddress, ChannelPromise promise)，同样立刻异步返回并增加ChannelFutureListener.CLOSE_ON_FAILURE监听事件。
  • [代码行13]：如果绑定端口之前的操作并没有胜利，天然也就不能进行端口绑定操作了，通过promise记录异样起因。

AbstractChannel#bind(SocketAddress localAddress, ChannelPromise promise)办法如下：

 public ChannelFuture bind(SocketAddress localAddress, ChannelPromise promise) {        return pipeline.bind(localAddress, promise); }

pipeline是之前创立channel的时候创立的DefaultChannelPipeline，进入该办法：

 public final ChannelFuture bind(SocketAddress localAddress, ChannelPromise promise) {        return tail.bind(localAddress, promise); }

[在剖析初始化流程的时候最初画一个DefaultChannelPipeline外部的构造，可能便于剖析前面进入DefaultChannelPipeline一系列bind办法。]

首先，tail代表TailContext，进入AbstractChannelHandlerContext# bind(final SocketAddress localAddress, final ChannelPromise promise)办法：

 public ChannelFuture bind(final SocketAddress localAddress, final ChannelPromise promise) {     //省略局部代码     final AbstractChannelHandlerContext next = findContextOutbound(MASK_BIND);     EventExecutor executor = next.executor();     if (executor.inEventLoop()) {         next.invokeBind(localAddress, promise);     } else {         safeExecute(executor, new Runnable() {             @Override             public void run() {                 next.invokeBind(localAddress, promise);             }         }, promise, null);     }     return promise;}

[代码行3]：findContextOutbound办法里次要是执行ctx = ctx.prev;那么失去的next就是绑定LoggingHandler的context

[代码行6]：进入invokeBind(localAddress, promise)办法并间接执行LoggingHandler#bind(this, localAddress, promise)，进入后的办法如下：

 public void bind(ChannelHandlerContext ctx, SocketAddress localAddress, ChannelPromise promise) throws Exception {     if (logger.isEnabled(internalLevel)) {         logger.log(internalLevel, format(ctx, "BIND", localAddress));     }     ctx.bind(localAddress, promise); }

设置了LoggingHandler的日志根本级别为默认的INFO后，进行绑定操作的信息打印。接着，持续循环到AbstractChannelHandlerContext# bind(final SocketAddress localAddress, final ChannelPromise promise)办法执行ctx = ctx.prev取出HeadContext进入到bind办法：

 public void bind(ChannelHandlerContext ctx, SocketAddress localAddress, ChannelPromise promise) {     unsafe.bind(localAddress, promise); }

兜兜转转，最终跳出了pipeline轮回到AbstractUnsafe#bind(final SocketAddress localAddress, final ChannelPromise promise) 办法，Channel 的端口绑定逻辑。代码如下：

public final void bind(final SocketAddress localAddress, final ChannelPromise promise) {    //此处有省略...    boolean wasActive = isActive();    try {        doBind(localAddress);    } catch (Throwable t) {        safeSetFailure(promise, t);        closeIfClosed();        return;    }    //此处有省略...}

做实事办法doBind进入后如下：

@Overrideprotected void doBind(SocketAddress localAddress) throws Exception {    if (PlatformDependent.javaVersion() >= 7) {        javaChannel().bind(localAddress, config.getBacklog());    } else {        javaChannel().socket().bind(localAddress, config.getBacklog());    }}

到了此处，服务端的 Java 原生 NIO ServerSocketChannel 终于绑定上了端口。

三、问题演绎

  • Problem-1: 创立Channel流程中AbstractChannel构造函数中为channel调配ID的算法如何实现？
  • Problem-2: AbstractChannel外部类AbstractUnsafe的作用？
  • Problem-3: 初始化channel流程中pipeline 增加ServerBootstrapAcceptor 是通过EventLoop.execute 执行增加的过程，这是为什么呢？
  • Problem-4：注册channel流程中PowerOfTwoEventExecutorChooser 和 GenericEventExecutorChooser的区别和优化原理？
  • Problem-5：绑定端口流程中调用 EventLoop执行 Channel 的端口绑定逻辑。然而，实际上以后线程曾经是 EventLoop所在的线程了，为何还要这样操作呢？

小结

通过对Netty服务端启动流程源码剖析，咱们发现了在应用NIO的模式下，服务端启动流程其实就是封装了JDK NIO编程在服务端启动的流程。只不过对原生JDK NIO进行了加强和优化，同时从架构设计上简化了服务端流程的编写。

最重要的是感激彤哥、艿艿和俞超-闪电侠这些大佬后期的分享，可能让更多人学习源码的旅途少走很多弯路，谢谢！

欢送关注：