Netty（二）：Netty为啥去掉支持AIO?

匠心零度 转载请注明原创出处，谢谢！

疑惑

咱们都知道bio nio 以及nio2(也就是aio)，若是不是特别熟悉能够看看我以前写的网络 I/O模型，那么netty为何还常常看到相似下面的这段代码呢？

EventLoopGroup ……= new NioEventLoopGroup();
……
……
 b.group(……).channel(NioSocketChannel.class)……
……
……
ChannelFuture f = b.bind(PORT).sync();

不选择bio模型咱们知道，那么为何不选择aio模式呢？而仍是选择nio模式呢？这是一个值得思考的问题，我就一直很好奇，由于在网络 I/O模型里面介绍的，明显AIO要比NIO模型还要好。

那么为何Netty仍是选择的NIO模型呢？

Netty一些组件简单介绍

Netty中这样定义EventLoop的，本篇重点不在这里，后续继续介绍EventLoop。

Will handle all the I/O operations for a [Channel] once registered. One [EventLoop] instance will usually handle more than one [Channel] but this may depend on implementation details and internals.

Netty中这样定义EventLoopGroup的，本篇重点不在这里，后续继续介绍EventLoopGroup。

Special [EventExecutorGroup] which allows registering [Channel]s that get processed for later selection during the event loop.

Netty中这样定义Channel的，本篇重点不在这里，后续继续介绍Channel。

A nexus to a network socket or a component which is capable of I/O operations such as read, write, connect, and bind.

A channel provides a user:

• the current state of the channel (e.g. is it open? is it connected?),
• the [configuration parameters] of the channel (e.g. receive buffer size),
• the I/O operations that the channel supports (e.g. read, write, connect, and bind), and
• the [ChannelPipeline] which handles all I/O events and requests associated with the channel.

Netty中这样定义ChannelFuture的，本篇重点不在这里，后续继续介绍ChannelFuture。

The result of an asynchronous [Channel] I/O operation.

All I/O operations in Netty are asynchronous. It means any I/O calls will return immediately with no guarantee that the requested I/O operation has been completed at the end of the call. Instead, you will be returned with a [ChannelFuture] instance which gives you the information about the result or status of the I/O operation.

A [ChannelFuture] is either uncompleted or completed. When an I/O operation begins, a new future object is created. The new future is uncompleted initially - it is neither succeeded, failed, nor cancelled because the I/O operation is not finished yet. If the I/O operation is finished either successfully, with failure, or by cancellation, the future is marked as completed with more specific information, such as the cause of the failure. Please note that even failure and cancellation belong to the completed state.

Netty提供的网络传输实现

备注： 这个是参考netty实战书籍的。

看看RocketMQ里面的写法，等netty系列完成了，后续RocketMQ会继续分析的。

备注：
If you are running on linux you can use EpollEventLoopGroup and so get better performance, less GC and have more advanced features that are only available on linux.

epoll对文件描述符有两种操做模式--LT（level trigger水平模式）和ET（edge trigger边缘模式）

简单来说，LT是epoll的默认操做模式，当epoll_wait函数检测到有事件发生并将通知应用程序，而应用程序不必定必须当即进行处理，这样epoll_wait函数再次检测到此事件的时候还会通知应用程序，直到事件被处理。

而ET模式，只要epoll_wait函数检测到事件发生，通知应用程序当即进行处理，后续的epoll_wait函数将再也不检测此事件。所以ET模式在很大程度上下降了同一个事件被epoll触发的次数，所以效率比LT模式高。

解释为何epoll默认是LT的缘由（超哥解释，我的以为仍是很是不错的）
LT(level triggered)：LT是缺省的工做方式，而且同时支持block和no-block socket。在这种作法中，内核告诉你一个文件描述符是否就绪了，而后你能够对这个就绪的fd进行IO操做。若是你不做任何操做，内核仍是会继续通知你的，因此，这种模式编程出错误可能性要小一点。传统的select/poll都是这种模型的表明。

感谢超哥提供地址：https://github.com/netty/netty/commit/9330172f803f340df677c370464126cd6112204a#diff-67591dfc9d4c7ea8dbe03ab24ff1669c，EpollEventLoopGroup和NioEventLoopGroup二者之间细微的差距。欢迎继续留言进行补充。

Netty为啥去掉支持AIO?

根据这个疑问搜索了下，查看到github上面的说明：https://github.com/netty/netty/issues/2515。

备注：总的来讲可能支持AIO Not faster than NIO (epoll) on unix systems (which is true) 并且性价比不高，可能以为不值得，反正netty已经封装好，用户调用起来也很简单和底层用nio或者aio其实用户不须要关心的，只要快就行。

因为本身水平问题，可能不少理解不到位，欢迎你们积极在留言区进行留言讨论，感谢。在后面合适的机会咱们继续讨论，AIO Not faster than NIO (epoll) on unix systems (which is true) 这是为何呢？ 目前我仍是先学习netty主干，后续会继续回到这个话题上面。

---

若是读完以为有收获的话，欢迎点赞、关注、加公众号【匠心零度】，查阅更多精彩历史！！！