netty4 ServerBootstrap.bind(port) debug
代码是netty4自带的例子
我们在bind的行前加个断电，下面是ServerBootstrap.bind(port)方法所经历的一些步骤。
在AbstractBootstrap.initAndRegister()中实例化一个Channel并进行初始化配置。
（可以参考《Netty4 initAndRegister 解析》）
配置项为在初始化Bootstrap时我们传入的handlers和一些设置。
下面进行channel的初始化（可以参考《Netty 源码分析之 一 揭开 Bootstrap 神秘的红盖头 (客户端)》）
注意箭头所示，这里的channelFactory是ReflectiveChannelFacotry.
这里就返回一个NioServerSocketChannel类型的channel.
下面的init(channel）对刚生成的channel进行一些初始化配置。
接着往下看：
注意下面注释内容。这里有两个添加handler的动作，后面一个时延时的，为了确保所有的handler都被放置在ServerBootstrapAccepter之前。这时候就已经初始化完channle中的eventloop对象了，可以使用eventloop来执行该channel的一些工作。
初始化完channel之后：反回到initAndRegister()先看一下eventloop注册到channel。
EventLoop注册Channel
说白了就是获取一个线程来处理这个注册事件。
那么这个EventExecutor到底是什么？我们获得了这个EventExecutor之后我们进入它的register(channel)方法看看：
这里注意到，eventloop注册channel实际上是channel注册eventoloop。最终将当前的eventloop传入到channel中作为channel的属性。
下面的eventLoop.inEvenLoop()判断该eventloop线程是否当前线程。这里关于eventloop的内容要以《Netty4 initAndRegister 解析》为主，下面的内容总结的一般。
然后下面的doregister0调用的是AbstractChannel在子类中的实现。比如当前是NioServerSocketChannel.doBind()同样也是在这个子类中实现的。
下面这快是对EventLoop接口的分析。
最后我们进入这个loop线程的执行线程：
先到此为止我们继续上面的逻辑：
以上都是initAndRegister()方法中的逻辑。
接着往下走：
DefaultChannelPipeline{(LoggingHandler#0 = io.netty.handler.logging.LoggingHandler), (ServerBootstrap$ServerBootstrapAcceptor#0 = io.netty.bootstrap.ServerBootstrap$ServerBootstrapAcceptor)}
继续主流程：
这里同时要留意eventloop的用法。
Netty内部都是通过线程在处理各种数据，EventLoopGroup就是用来管理调度他们的，注册Channel，管理他们的生命周期，下面就来看看EventLoopGroup是怎样工作的。
最终还是到channel.bind(...)这个方法来绑定。
下面进入：final AbstractChannelHandlerContext next = findContextOutbound();
EventExecutor executor = next.executor();
前面将eventloop注册到channel中之后，这里取出channel的eventloop。
AbstractChannelHandlerContext这个东西有专门博文。
一直循环到ctx.outbound为true的时候，获取这个ctx。
还记得那个上行下行的图吗，这就是那里的感念。
下面进入到EventExecutor executor = next.executor();方法：有上图可知当前的executor属性为null。
我们进入channel().eventloop().这个地方需要返回一个EventExecutor类型的对象。
我们先看channel方法：
pipeline＝DefaultChannelPipeline{(LoggingHandler#0 = io.netty.handler.logging.LoggingHandler), (ServerBootstrap$ServerBootstrapAcceptor#0 = io.netty.bootstrap.ServerBootstrap$ServerBootstrapAcceptor)}
这里的(LoggingHandler#0 = io.netty.handler.logging.LoggingHandler)是什么鬼？
还记得上面的init(channel)吗，我们在那里添加了handler和ServerBootstrapAccepter。
下面我们还会涉及到这个handler。
先不管我们先进入pipeline.channel();方法
return channel().eventLoop();这里执行完channel()方法后我们进入eventloop()方法：
这里需要返回一个EventExecutor类型的对象。
然而这里返回的却是一个NioEventLoop类型的对象。我们在看一下关系图：
先不管我们接着看：下面进入父类的方法：
最终我们执行完了这个方法，返回一个EventLoop类型的对象。
NioEventLoop类型的对象怎么会是EventExecutor类型呢？
通过NioEventLoop类型检索我们发现
原来EventLoop继承了EventExecutor接口。没办法社区办idea功能比较简陋，就不画类型关系图了。
那么我们接着netty流程往下走：
在下面这个方法这里循环所有的handler的bind()方法。
这里的handler:LoggingHandler。还记得上面的疑问吗。答案在这里。
当前的handler是LoggingHandler那么我们就进入到：
这里又一个非常值得注意的地方。LoggingHandler的bind()方法并没有写什么业务逻辑，只打印了个日志：
18:33:33.694 [nioEventLoopGroup-2-1] INFO i.n.handler.logging.LoggingHandler - [id: 0x62c8b900] BIND: 0.0.0.0/0.0.0.0:8007
然后直接调用了下一个handler的bind()方法。
这个bind()方法是定义在ChannelOutboundHandler中的方法。
所有我们就行入到下一次循环中了：
开始循环了。
下一个handler：
到这里终于跳出netty框架到老nio层了！
但是到这的时候程序没进入bind直接跳出来了：
这里成功了？
我们专门打个断点到那个nio bind的地方。根据以上的流程分析我们知道最终的nio层bind就在我们非常熟悉的NioServerSocketChannel中实现。
我们手动进入这个类中找到bind方法：
这就和我们平时直接用nio写业务时一样了：
