爲何選擇Netty做爲基礎通訊組件？

如下內容根據網上資料和本身整理總結而成

1、什麼是Netty？

Netty是一個高性能 事件驅動、異步非堵塞的IO(NIO)Java開源框架，Jboss提供，用於創建TCP等底層的鏈接，基於Netty能夠創建高性能的Http服務器，快速開發高性能、高可靠性的網絡服務器和客戶端程序。支持HTTP、 WebSocket 、Protobuf、 Binary TCP |和UDP，Netty已經被不少高性能項目做爲其Socket底層基礎，如HornetQ Infinispan Vert.x Play Framework Finangle和 Cassandra。其競爭對手是：Apache MINA和 Grizzly。

也就是說，Netty 是一個基於NIO的客戶，服務器端編程框架，使用Netty 能夠確保你快速和簡單的開發出一個網絡應用，例如實現了某種協議的客戶，服務端應用。Netty至關簡化和流線化了網絡應用的編程開發過程，例如，TCP和UDP的socket服務開發。

「快速」和「簡單」並不意味着會讓你的最終應用產生維護性或性能上的問題。Netty 是一個吸取了多種協議的實現經驗，這些協議包括FTP,SMTP,HTTP，各類二進制，文本協議，並通過至關精心設計的項目，最終，Netty 成功的找到了一種方式，在保證易於開發的同時還保證了其應用的性能，穩定性和伸縮性。

 

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

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

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

 

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

1）跨平臺與兼容性：NIO算是底層的APIs需依賴系統的IO APIs。但Java NIO發如今不一樣系統平臺會出現問題。大量測試也耗很多時間；NIO2只支持JDK1.7+，並且沒提供DatagramSocket，故NIO2不支持UDP協議。而Netty提供統一接口，同一語句不管在JDK6.X 仍是JDK7.X 均可運行，無需關心底層架構功能！

2）JAVA NIO的ByteBuffer構造函數私有，沒法擴展。Netty提供了本身的ByteBuffer實現，經過簡單APIs對其進行構造、使用和操做，一此解決NIO的一些限制。

3）NIO對緩衝區的聚合與分散操做可能會致使內存泄漏。直到JDK1.7才解決此問題。

4）NIO的類庫和API繁雜，使用麻煩，你須要熟練掌握Selector、ServerSocketChannel、SocketChannel、ByteBuffer等。

5）使用JAVA NIO須要具有其餘的額外技能作鋪墊，例如熟悉Java多線程編程。這是由於NIO編程涉及到Reactor模式，你必須對多線程和網路編程很是熟悉，才能編寫出高質量的NIO程序。

6）可靠性能力補齊，工做量和難度都很是大。例如客戶端面臨斷連重連、網絡閃斷、半包讀寫、失敗緩存、網絡擁塞和異常碼流的處理等問題。

7）JDK NIO的BUG，例如臭名昭著的epoll bug，它會致使Selector空輪詢，最終致使CPU 100%。官方聲稱在JDK 1.6版本的update18修復了該問題，可是直到JDK 1.7版本該問題仍舊存在，只不過該BUG發生機率下降了一些而已，它並無獲得根本性解決。該BUG以及與該BUG相關的問題單能夠參見如下連接內容。

◎    http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6403933

◎    http://bugs.java.com/bugdatabase/view_bug.do?bug_id=2147719

異常堆棧以下。

java.lang.Thread.State: RUNNABLE

        at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)

        at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210)

        at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65)

        at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)

        - locked <0x0000000750928190> (a sun.nio.ch.Util$2)

        - locked <0x00000007509281a8> (a java.util.Collections$ UnmodifiableSet)

        - locked <0x0000000750946098> (a sun.nio.ch.EPollSelectorImpl)

        at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)

        at net.spy.memcached.MemcachedConnection.handleIO(Memcached Connection.java:217)

        at net.spy.memcached.MemcachedConnection.run(MemcachedConnection. java:836)

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

 

3、選擇Netty做爲基礎通訊框架的緣由

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

經過對Netty的分析，咱們將它的優勢總結以下。

◎    API使用簡單，開發門檻低；

◎    功能強大，預置了多種編解碼功能，支持多種主流協議；

◎    定製能力強，能夠經過ChannelHandler對通訊框架進行靈活地擴展；

◎    性能高，經過與其餘業界主流的NIO框架對比，Netty的綜合性能最優；

◎    成熟、穩定，Netty修復了已經發現的全部JDK NIO BUG，業務開發人員不須要再爲NIO的BUG而煩惱；

◎    社區活躍，版本迭代週期短，發現的BUG能夠被及時修復，同時，更多的新功能會加入；

◎    經歷了大規模的商業應用考驗，質量獲得驗證。Netty在互聯網、大數據、網絡遊戲、企業應用、電信軟件等衆多行業已經獲得了成功商用，證實它已經徹底可以知足不一樣行業的商業應用了。

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

感謝做者最原始出處連接：http://blog.csdn.net/broadview2006/article/details/46041995