netty nio模型

由于littleproxy 使用netty nio作为网络框架，线程模型令人眼花缭乱，不得不好好分析一下，其实和glib的gmainlooper以及Android 的threadLooper基本上是一个思路，就是使用任务队列，poll模型来派发运行任务和io事件处理。

整体模型如下图。

线程模型的最顶层是NIOEventLoopGroup数据结构， 该结构通过children数组维护多个EventLooper, 在nio模型中为NIOEventLooper, 每一个NIOEventLooper对应一个线程，所以可以理解NIOEventLoopGroup为一个线程池。

NIOEventLooper作为一个线程，所做的操作就是最最核心的部分，在介绍这部分工作之前先介绍下它的核心数据结构。 其中scheduletTaskQueue用于维护用户定时任务，taskQueue用于维护非定时任务， poll channel则为用户关心的io通道（java使用通道来表示一个可读写的文件描述符）。所以NIOEventLooper线程的核心工作就是运行scheduletTaskQueue，taskQueue中的任务，以及poll channels。 poll channels的过程要关注定时任务的超时和是否taskqueue中是否有新任务。 另外外部采用java的selector.weakup()来进行唤醒。

再介绍一下NIOChannel,对应图中AbstraceNIOChannel, 一个NIOChannel 对应一个IOChannel （java的NIOChannel，方便区分后面写作javachannel）,以及一个绑定的NIOEventLooper。也就是说该NIOChannel中的javachannel的poll操作都由该NIOEventLooper完成。

另外NIOChannel里面有一个ChannelPipe数据结构，用于javachannel的读写链接等io事件的处理。

ChannelPipe里面维护一个链表，每一项为一个ChannelHandlerContext结构，该结构中的ChannelHandler用于执行具体的io事件处理。ChannelHandlerContext的EventLooper则是用于绑定处理该事件的线程，也就是在ChannelHandlerContext的EventLooper线程中使用ChannelHandler处理NIOChannel中javachannel的具体io事件。

默认pipe中都有两个ChannelHandler， 一个用于从javachannel中读出原始数据，一个则用于写入最终数据，这两个ChannelHandler分别位于pipe的两端

这就是netty nio的整体模型。该模型更偏向线程模型的角度。

具体的使用还要和协议相关。