匠心零度 轉載請註明原創出處，謝謝！

疑惑

我們都知道bio nio 以及nio2(也就是aio)，如果不是特別熟悉可以看看我之前寫的網路 I/O模型，那麼netty為什麼還經常看到類似下面的這段程式碼呢？

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

不選擇bio模型我們知道，那麼為什麼不選擇aio模式呢？而還是選擇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都是這種模型的代表。

Netty為啥去掉支援AIO?

備註：總的來說可能支援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主幹，後續會繼續回到這個話題上面。

如果讀完覺得有收穫的話，歡迎點贊、關注、加公眾號【匠心零度】，查閱更多精彩歷史！！！