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主幹，後續會繼續回到這個話題上面。

---

若是讀完以爲有收穫的話，歡迎點贊、關注、加公衆號【匠心零度】，查閱更多精彩歷史！！！