2017年春季開源中國要說最火的開源專案，即時通訊框架敢說第一，沒人敢說第二，當然現在是3月10日，它還能否火熱一年讓我們拭目以待。

   雖然我不是talent-aio的作者，但也是掛名的開發者，所以好歹也得給它做點事情，寫個部落格給大家介紹它的使用，也不枉talent-aio作者對我的教誨。之所以talent-aio會開源，其實也有我的功勞，哈哈，因為當初我和作者是同事並住同一個小區，某一個散步的路上，作者一面感慨時光荏苒，一面覺得事業到了瓶頸，需要一個突破口，準備把精心打造的

talent-aio開源出去以尋找新突破口；當時聽他的想法後，我非常贊同他的想法，並表示，一個人的身價往往和名氣成正比，幹同一件事情，名氣不一樣，價錢也不一樣，因此讓他感覺開源，並推廣。好吧，我意淫了。

   迴歸正題，talent-aio從名字上開就知道，它的核心就是aio，非同步通訊，大家都知道，io模型現在分三類，bio、nio、aio；

bio 顧名思意，就是堵塞io，它的io模型如下圖：

伺服器接受客戶端的請求後要指派或者新建一個執行緒資源去處理客戶端的io事件，直到接收到斷開連線的指令。這樣

的弊端在併發情況下，愈發明顯，它是同步堵塞的模型，作業系統在沒處理完一個Io事件時會一直堵塞在一個連線上，其他socket連線就會被堵塞掛起，當併發量特別大時，一方面會造成大量連線掛起，另一方面會造成執行緒資源的不足，因為針對一個socket連線，伺服器要新建一個執行緒進行處理，哪怕使用執行緒池也會造成大量上下文切換開銷。

nio 是非堵塞io 使用的是Reactor模型 如下圖所示：

此圖來著:http://www.cnblogs.com/jasongj/p/5797863.html

如上圖所示，nio只有acceptor的服務執行緒是堵塞進行的，其它讀寫執行緒是通過註冊事件的方式，有讀寫事件啟用時

才呼叫執行緒資源去執行，不會一直堵塞等著讀寫操作。Preactor的瓶頸主要是在accepotr的執行，所有的讀寫事件是在他這一塊了分發。

AIO 是非同步非堵塞IO模型，如下圖所示：

與NIO不同，aio需要一個連線註冊讀寫事件和回撥方法，當進行讀寫操作時，只須直接呼叫API的read或write方法即可。這兩種方法均為非同步的，對於讀操作而言，當有流可讀取時，作業系統會將可讀的流傳入read方法的緩衝區，並通知應用程式；對於寫操作而言，當作業系統將write方法傳遞的流寫入完畢時，作業系統主動通知應用程式。 
即可以理解為，read/write方法都是非同步的，完成後會主動呼叫回撥函式。

以上是BIO、NIO、AIO的區別，AIO不管是在效能上還是穩定性上都優於BIO和NIO，但API使用複雜度都高於NIO和BIO，包括除錯難度，所以Talent-aio的出現就是為了解決這兩個問題，封裝AIO的API並提供更友好的介面，同時talent-aio內部把執行緒池和多執行緒發揮到極致，幫我們把aio的效能發揮到最佳，我們只需要簡單的使用即可，也不用考慮tcp的沾包粘包等問題。

talent-AIo的使用案例將在下一篇給出！