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的属性。

这里返回unsafe对象。其实 unsafe 特别关键, 它封装了对 Java 底层 Socket 的操作, 因此实际上是沟通 Netty 上层和 Java 底层的重要的桥梁









下面的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是怎样工作的。

EventLoops的目的是为Channel处理IO操作，一个EventLoop可以为多个Channel服务。
EventLoopGroup会包含多个EventLoop。
参考：http://www.tuicool.com/articles/mEJvYb
最终还是到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写业务时一样了：