最近在學習Java網路程式設計和Netty相關的知識，瞭解到Netty是NIO模式的網路框架，但是提供了不同的Channel來支援不同模式的網路通訊處理，包括同步、非同步、阻塞和非阻塞。學習要從基礎開始，所以我們就要先了解一下相關的基礎概念和Java原生的NIO。這裡，就將最近我學習的知識總結一下，以供大家瞭解。
為了節約你的時間，本文主要內容如下：
- 非同步，阻塞的概念
- 作業系統I/O的型別
- Java NIO的底層實現
非同步，同步，阻塞，非阻塞
同步和非同步關注的是訊息通訊機制，所謂同步就是呼叫者進行呼叫後，在沒有得到結果之前，該呼叫一直不會返回，但是一旦呼叫返回，就得到了返回值，同步就是指呼叫者主動等待呼叫結果；而非同步則相反，執行呼叫之後直接返回，所以可能沒有返回值，等到有返回值時，由被呼叫者通過狀態，通知來通知呼叫者．非同步就是指被呼叫者來通知呼叫者呼叫結果就緒*．*所以，二者在訊息通訊機制上有所不同，一個是呼叫者檢查呼叫結果是否就緒，一個是被呼叫者通知呼叫者結果就緒
阻塞和非阻塞關注的是程式在等待呼叫結果(訊息，返回值)時的狀態．阻塞呼叫是指在呼叫結果返回之前，當前執行緒會被掛起，呼叫執行緒只有在得到結果之後才會繼續執行．非阻塞呼叫是指在不能立刻得到結構之前，呼叫執行緒不會被掛起，還是可以執行其他事情．
兩組概念相互組合就有四種情況，分別是同步阻塞，同步非阻塞，非同步阻塞，非同步非阻塞．我們來舉個例子來分別類比上訴四種情況．
比如你要從網上下載一個1G的檔案，按下下載按鈕之後，如果你一直在電腦旁邊，等待下載結束，這種情況就是同步阻塞；如果你不需要一直呆在電腦旁邊，你可以去看一會書，但是你還是隔一段時間來檢視一下下載進度，這種情況就是同步非阻塞；如果你一直在電腦旁邊，但是下載器在下載結束之後會響起音樂來提醒你，這就是非同步阻塞；但是如果你不呆在電腦旁邊，去看書，下載器下載結束後響起音樂來提醒你，那麼這種情況就是非同步非阻塞．
Unix的I/O型別
知道上述兩組概念之後，我們來看一下Unix下可用的5種I/O模型：
- 阻塞I/O(bloking IO)
- 非阻塞I/O(nonblocking IO)
- 多路複用I/O(IO multiplexing)
- 訊號驅動I/O(signal driven IO)
- 非同步I/O(asynchronous IO)
前４種都是同步，只有最後一種是非同步I/O.需要注意的是***Java NIO依賴於Unix系統的多路複用I/O,對於I/O操作來說，它是同步I/O，但是對於程式設計模型來說，它是非同步網路呼叫***.下面我們就以系統read的呼叫來介紹不同的I/O型別．
當一個read發生時，它會經歷兩個階段:
- 1 等待資料準備
- 2 將資料從核心記憶體空間拷貝到程式記憶體空間中
不同的I/O型別，在這兩個階段中有不同的行為．但是由於這塊內容比較多，而且多為表述性的知識，所以這裡我們只給出幾張圖片來解釋，感覺興趣的同學可以去具體瞭解一下。
Java NIO的底層實現
我們都知道Netty通過JNI的方式提供了Native Socket Transport，為什麼Netty要提供自己的Native版本的NIO呢？明明Java NIO底層也是基於epoll呼叫(最新的版本)的．這裡，我們先不明說，大家想一想可能的情況．下列的原始碼都來自於OpenJDK-8u40-b25版本．
open方法
如果我們順著Selector.open()方法一個類一個類的找下去，很容易就發現Selector的初始化是由DefaultSelectorProvider根據不同作業系統平臺生成的不同的SelectorProvider，對於Linux系統，它會生成EPollSelectorProvider例項，而這個例項會生成EPollSelectorImpl作為最終的Selector實現．
class EPollSelectorImpl extends SelectorImpl
{
.....
// The poll object
EPollArrayWrapper pollWrapper;
.....
EPollSelectorImpl(SelectorProvider sp) throws IOException {
.....
pollWrapper = new EPollArrayWrapper();
pollWrapper.initInterrupt(fd0, fd1);
.....
}
.....
}
複製程式碼 EpollArrayWapper將Linux的epoll相關係統呼叫封裝成了native方法供EpollSelectorImpl使用．
private native int epollCreate();
private native void epollCtl(int epfd, int opcode, int fd, int events);
private native int epollWait(long pollAddress, int numfds, long timeout,
int epfd) throws IOException;
複製程式碼上述三個native方法就對應Linux下epoll相關的三個系統呼叫
//建立一個epoll控制程式碼，size是這個監聽的數目的最大值．
int epoll_create(int size);
//事件註冊函式，告訴核心epoll監聽什麼型別的事件，引數是感興趣的事件型別，回撥和監聽的fd
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
//等待事件的產生，類似於select呼叫，events引數用來從核心得到事件的集合
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);
複製程式碼 所以，我們會發現在EpollArrayWapper的建構函式中呼叫了epollCreate方法，建立了一個epoll的控制程式碼．這樣，Selector物件就算創造完畢了．
register方法
與open類似，ServerSocketChannel的register函式底層是呼叫了SelectorImpl類的register方法，這個SelectorImpl就是EPollSelectorImpl的父類．
protected final SelectionKey register(AbstractSelectableChannel ch,
int ops,
Object attachment)
{
if (!(ch instanceof SelChImpl))
throw new IllegalSelectorException();
//生成SelectorKey來儲存到hashmap中，一共之後獲取
SelectionKeyImpl k = new SelectionKeyImpl((SelChImpl)ch, this);
//attach使用者想要儲存的物件
k.attach(attachment);
//呼叫子類的implRegister方法
synchronized (publicKeys) {
implRegister(k);
}
//設定關注的option
k.interestOps(ops);
return k;
}
複製程式碼 EpollSelectorImpl的相應的方法實現如下，它呼叫了EPollArrayWrapper的add方法，記錄下Channel所對應的fd值,然後將ski新增到keys變數中．在EPollArrayWrapper中有一個byte陣列eventLow記錄所有的channel的fd值.
protected void implRegister(SelectionKeyImpl ski) {
if (closed)
throw new ClosedSelectorException();
SelChImpl ch = ski.channel;
//獲取Channel所對應的fd,因為在linux下socket會被當作一個檔案，也會有fd
int fd = Integer.valueOf(ch.getFDVal());
fdToKey.put(fd, ski);
//呼叫pollWrapper的add方法,將channel的fd新增到監控列表中
pollWrapper.add(fd);
//儲存到HashSet中，keys是SelectorImpl的成員變數
keys.add(ski);
}
複製程式碼 我們會發現,呼叫register方法並沒有涉及到EpollArrayWrapper中的native方法epollCtl的呼叫,這是因為他們將這個方法的呼叫推遲到Select方法中去了.
Select方法
和register方法類似,SelectorImpl中的select方法最終呼叫了其子類EpollSelectorImpl的doSelect方法
protected int doSelect(long timeout) throws IOException {
.....
try {
....
//呼叫了poll方法,底層呼叫了native的epollCtl和epollWait方法
pollWrapper.poll(timeout);
} finally {
....
}
....
//更新selectedKeys,為之後的selectedKeys函式做準備
int numKeysUpdated = updateSelectedKeys();
....
return numKeysUpdated;
}
複製程式碼 由上述的程式碼，可以看到，EPollSelectorImpl先呼叫EPollArrayWapper的poll方法,然後在更新SelectedKeys．其中poll方法會先呼叫epollCtl來註冊先前在register方法中儲存的Channel的fd和感興趣的事件型別，然後epollWait方法等待感興趣事件的生成,導致執行緒阻塞.
int poll(long timeout) throws IOException {
updateRegistrations(); ////先呼叫epollCtl,更新關注的事件型別
////導致阻塞，等待事件產生
updated = epollWait(pollArrayAddress, NUM_EPOLLEVENTS, timeout, epfd);
.....
return updated;
}
複製程式碼 等待關注的事件產生之後(或在等待時間超過預先設定的最大時間),epollWait函式就會返回.select函式從阻塞狀態恢復.
selectedKeys方法
我們先來看SelectorImpl中的selectedKeys方法.
//是通過Util.ungrowableSet生成的,不能新增,只能減少
private Set<SelectionKey> publicSelectedKeys;
public Set<SelectionKey> selectedKeys() {
....
return publicSelectedKeys;
}
複製程式碼 很奇怪啊,怎麼直接就返回publicSelectedKeys了,難道在select函式的執行過程中有修改過這個變數嗎?
publicSelectedKeys這個物件其實是selectedKeys變數的一份副本,你可以在SelectorImpl的建構函式中找到它們倆的關係,我們再回頭看一下select中updateSelectedKeys方法.
private int updateSelectedKeys() {
//更新了的keys的個數,或在說是產生的事件的個數
int entries = pollWrapper.updated;
int numKeysUpdated = 0;
for (int i=0; i<entries; i++) {
//對應的channel的fd
int nextFD = pollWrapper.getDescriptor(i);
//通過fd找到對應的SelectionKey
SelectionKeyImpl ski = fdToKey.get(Integer.valueOf(nextFD));
if (ski != null) {
int rOps = pollWrapper.getEventOps(i);
//更新selectedKey變數,並通知響應的channel來做響應的處理
if (selectedKeys.contains(ski)) {
if (ski.channel.translateAndSetReadyOps(rOps, ski)) {
numKeysUpdated++;
}
} else {
ski.channel.translateAndSetReadyOps(rOps, ski);
if ((ski.nioReadyOps() & ski.nioInterestOps()) != 0) {
selectedKeys.add(ski);
numKeysUpdated++;
}
}
}
}
return numKeysUpdated;
}
複製程式碼後記
看到這裡,詳細大家都已經瞭解到了NIO的底層實現了吧.這裡我想在說兩個問題.
一是為什麼Netty自己又從新實現了一邊native相關的NIO底層方法? 聽聽Netty的創始人是怎麼說的吧連結。因為Java的版本使用的epoll的level-triggered模式，而Netty則希望使用edge-triggered模式，而且Java版本沒有將epoll的部分配置項暴露出來，比如說TCP_CORK和SO_REUSEPORT。
二是看這麼多原始碼,花費這麼多時間有什麼作用呢?我感覺如果從非功利的角度來看,那麼就是純粹的希望瞭解的更多,有時候看完原始碼或在理解了底層原理之後,都會用一種恍然大悟的感覺,比如說AQS的原理.如果從目的性的角度來看,那麼就是你知道底層原理之後,你的把握性就更強了,如果出了問題,你可以更快的找出來,並且解決.除此之外,你還可以按照具體的現實情況,以原始碼為模板在自己造輪子,實現一個更加符合你當前需求的版本.
後續如果有時間,我希望好好了解一下epoll的作業系統級別的實現原理.
