Netty：Netty为啥去掉支持AIO?

Posted 2021-04-30 匠心零度

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

疑惑

我们都知道bio nio 以及nio2(也就是aio)，如果不是特别熟悉可以看看我之前写的，那么netty为什么还经常看到类似下面的这段代码呢？

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

不选择bio模型我们知道，那么为什么不选择aio模式呢？而还是选择nio模式呢？这是一个值得思考的问题，我就一直很好奇，因为在里面介绍的，明显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 Channels 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都是这种模型的代表。

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主干，后续会继续回到这个话题上面。

---