Java IO編程全解（六）——4種I/O的對比與選型

　　轉載請註明出處：http://www.cnblogs.com/Joanna-Yan/p/7804185.html 

　　前面講到：Java IO編程全解（五）——AIO編程

　　爲了防止因爲對一些技術概念和術語的理解或者叫法不一致而引發歧義，這裏對涉及到的專業術語或者技術用語作下聲明：若是它們與其餘一些地方的稱呼不一致，請以本解釋爲準。

異步非阻塞I/O

　　不少人喜歡將JDK1.4提供的NIO框架成爲異步非阻塞I/O，可是，若是嚴格按照UNIX網絡編程模型和JDK的實現進行區分，實際上它只能被稱爲非阻塞I/O，不能叫異步非阻塞I/O。在早期的JDK1.4和1.5 update10版本以前，JDK的Selector基於select/poll模型實現，它是基於I/O複用技術的非阻塞I/O，不是異步I/O。在JDK1.5 update10和Linux core2.6以上版本，Sun優化了Selector實現，它在底層使用epoll替換了select/poll，上層的API並無變化，能夠認爲是JDK NIO的一次性能優化，可是它仍舊沒有改變I/O的模型。

　　由JDK1.7提供的NIO 2.0，新增了異步的套接字通道，它是真正的異步I/O，在異步I/O操做的時候能夠傳遞信號變量，當操做完成以後會回調相關的方法，異步I/O也被稱爲AIO。

　　NIO類庫支持非阻塞讀和寫操做，相比於以前的同步阻塞讀和寫，它是異步的，NIO類庫支持非阻塞讀和寫操做，相比於以前的同步阻塞讀和寫，它是一部的，所以不少人習慣稱NIO爲異步非阻塞I/O，包括不少介紹NIO編程的書籍也沿用了這個說法。爲了符合你們的習慣，這裏也會將NIO稱爲異步非阻塞I/O或者非阻塞I/O。請你們理解，不要過度糾結在一些技術術語的咬文嚼字上。

多路複用器Selector　

　　幾乎全部的中文技術書籍都將Selector翻譯爲選擇器，可是實際上我認爲這樣的翻譯並不恰當，選擇器僅僅是字面上的意思，體現不出Selector的功能和特色。

　　前面介紹過Java NIO的實現關鍵是多路複用I/O技術，多路複用的核心就是經過Selector來輪詢註冊在其上的Channel，當發現某個或者多個Channel處於就緒狀態後，從阻塞狀態返回就緒的Channel的選擇鍵集合，進行I/O操做。因爲多路複用器是NIO實現非阻塞I/O的關鍵，它又是主要經過Selector實現的，因此這裏將Selector翻譯爲多路複用器，與其餘技術書籍所說的選擇器是同一個東西，請你們瞭解。

僞異步I/O

　　僞異步的概念徹底來源於實現。在JDK NIO編程沒有流行以前，爲了解決Tomcat通訊線程同步I/O致使業務線程被掛住的問題，你們想到了一個辦法：在通訊線程和業務線程以前作個緩衝區，這個緩衝區用於隔離I/O線程和業務線程間的直接訪問，這樣業務線程就不會被I/O線程阻塞。而對於後端的業務側來講，將消息或者Task放到線程池後就返回了，它再也不直接訪問I/O線程或者進行I/O讀寫，這樣就不會被同步阻塞。相似的設計還包括前端啓動一組線程，將接收到的客戶端封裝成Task，放到後端的線程池執行，用於解決一鏈接一線程問題。像這樣經過線程池作緩衝區的作法，這裏習慣於稱它爲僞異步I/O，而官方並無僞異步I/O這種說法，請你們注意。

1. 不一樣I/O模型對比

　　不一樣的I/O模型因爲線程模型、API等差異很大，因此用法的差別也很是大。

　　實際開發中，具體選擇什麼樣的I/O模型或者NIO框架，徹底基於業務的實際應用場景和性能訴求，若是客戶端併發鏈接數很少，周邊對接的網元很少，服務器的負載也不重，那就徹底不必選擇NIO作服務器；若是是相反狀況，那就要考慮選擇合適的NIO框架進行開發。

2.選擇Netty的理由

　　開發出高質量的NIO程序並非一件簡單的事情，除去NIO固有的複雜性和BUG不談，做爲一個NIO服務器，須要可以處理網絡的閃斷、客戶端的重複接入、客戶端的安全認證、消息的編解碼、半包讀寫等狀況，若是你沒有足夠的NIO編程經驗積累，一個NIO框架的穩定每每須要半年甚至更長的時間。更爲糟糕的是，一旦在生產環境中發生問題，每每會致使跨節點的服務調用中斷，嚴重的可能會致使整個集羣環境都不可用，須要重啓服務器，這種非正常停機會帶來巨大的損失。

　　從可維護性角度看，因爲NIO採用了異步非阻塞編程模型，並且是一個I/O線程處理多條鏈路，它的調試和跟蹤很是麻煩，特別是生產環境中的問題，咱們沒法進行有效的調試和跟蹤，每每只能靠一些日誌來輔助分析，定位難度很大。

2.1不選擇Java原生NIO編程的緣由

　　如今咱們總結一下咱們不建議開發者直接使用JDK的NIO類庫進行開發，具體緣由以下。

1. NIO的類庫和API繁雜，使用麻煩，你須要熟練掌握Selector、ServerSocketChannel、SocketChannel、ByteBuffer等。
2. 須要具有其餘的額外技能作鋪墊，例如熟悉Java多線程編程。這是由於NIO編程設計到Reactor模式，你必須對多線程和網絡編程很是熟悉，才能編寫出高質量的NIO程序。
3. 可靠性能力補齊，工做量和難度都很是大。例如客戶端面臨斷連重連、網絡閃斷、半包讀寫、失敗緩存、網絡擁塞和異常碼流的處理等問題，NIO編程的特色是功能開發相對容易，可是可靠性能力補齊的工做量和難度都很是大。
4. JDK NIO的BUG，例如臭名昭著的epoll bug，它會致使Selector空輪詢，最終致使CPU100%，官方聲稱在JDK1.6版本的update18修復了該問題，可是直到JDK1.7版本該問題仍舊存在，只不過該BUG發生頻率下降了一些而已，它並無被根本解決。

　　因爲上述緣由，在大多數場景下，不建議你們直接使用JDK的NIO類庫，除非你精通NIO編程或者有特殊的需求。在絕大多數的業務場景中，咱們可使用NIO框架Netty來進行NIO編程，它既能夠做爲客戶端也能夠做爲服務端，同時支持UDP和異步文件傳輸，功能很是強大。

2.2爲何選擇Netty

　　Netty是業界最流行的NIO框架之一，它的健壯性、功能、性能、可定製性和可擴展性在同類框架中都是數一數二的，它已經獲得成百上千的商業項目驗證，例如Hadoop的RPC框架avro使用Netty做爲底層通訊框架；不少其餘業界主流的RPC框架，也使用Netty來構建高性能的異步通訊能力。

　　Netty的優勢總結以下：

• API使用簡單，開發門檻低；
• 功能強大，預置了多種編解碼功能，支持多種主流協議；
• 定製能力強，能夠經過ChannelHandler對通訊框架進行靈活地擴展；
• 性能高，經過與其餘業界主流的NIO框架對比，Netty的綜合性能最優；
• 成熟、穩定，Netty修復了已經發現的全部JDK NIO BUG，業務開發人員不須要再爲NIO的BUG而煩惱；
• 社區活躍，版本迭代週期短，發現的BUG能夠被及時修復，同時，更多的新功能會加入；
• 經歷了大規模的商業應用考驗，質量獲得驗證。在互聯網、大數據、網絡遊戲、企業應用、電信軟件等衆多行業獲得成功商用，證實了它已經徹底可以知足不一樣行業的商業應用了。

　　正是由於這些優勢，Netty逐漸成爲Java NIO編程的首選框架。

Netty（一）——Netty入門程序

若是此文對您有幫助，微信打賞我一下吧~