寫在開頭：Netty是個什么玩意？這里摘抄官網的一段話：Netty是由JBOSS提供的一個java開源框架。Netty提供異步的、事件驅動的網絡應用程序框架和工具，用以快速開發高性能、高可靠性的網絡服務器和客戶端程序。

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

總結一句話：Netty是用于開發客戶端、服務端通信系統的一套框架。

我們學習Netty能用來干什么呢？或者說有哪些我們常用的東西使用Netty開發的呢？舉兩個例子：Hadoop和dubbo，Hadoop底層使用netty做通信架構的，dubbo底層也是用netty寫的。netty在中間件系統開發中用的特別多，可能你會認為我用不到啊，我平時都是SofaMVC或者SpringMVC,Mybatis，Spring一類的，然后基本上都是和數據庫打交道，天天crud。對，說的沒錯，但是你別忘了，互聯網的技術本質其實就是通信，你操作數據庫其實也是在不斷和數據庫在通信，而且隨著系統規模增大，大到現有的框架已經不能滿足要求了，那么你就需要開發自己的通信系統。

在沒有Netty之前我們是怎么開發通信系統的，記得以前做過一個項目，是替有關部門做一個車輛監控系統，每個車上面有個GPS設備（與衛星通信的專業設備），他們希望能夠監控車輛的運行狀態。當時在做服務端的時候用的是BIO框架，也就是阻塞IO，采用一端一線程來解決，在開發的時候遇到了很多坑，比如說客戶端（GPS模塊）與服務端鏈接超時，網絡閃斷，板報讀寫，網絡擁塞等，并且一臺機器的線程數有限，還好當時只監控500輛車，當時遇到的最惡心的是GPS這個模塊他們用了一個廠家做的嵌入式設備，因為我以前是開發單片機的，對著還比較了解，當時他們的協議棧有問題，雖然客戶端與服務器連接斷了，但是服務器這邊還是現實連接著，后來發現是他們通過基站連接著服務器，總之，特別多的問題。基本上好多代碼都不是去解決業務本身而且在構建一個通信框架，這當然不是我想要的。

再后來，使用了NIO框架，好處不用多說，單機支撐上萬線程，采用linux的enpoll模型，多路io復用，但是在采用原生的NIO框架開發通信系統的時候，依舊大量代碼用于構建通信框架而不是業務本身。并且一直崩潰，不穩定，這其實也是NIO框架的問題所在，主要有以下幾點：

1. NIO的類庫和API繁雜。

2. 需要具備其他的額外技能做鋪墊。

3. 可靠性能力不齊，工作了和難度大。例如：客戶端斷線重連，網絡閃斷，半包讀寫，失敗緩存，網絡擁塞，異常碼流等。

4. JDK的BUG，例如：epoll的bug會導致selector空輪詢，導致CPU 100%，該問題到JDK1.7版本還是一直存在。

廢話不多說，先看一個簡單的采用原生NIO框架開發的服務器例子（簡單）。

看完之后什么感覺，是不是特別惡心，對吧，寫個簡單的接受字符串程序寫了這么多代碼，而且也沒有解決半包等問題，這豈不是要瘋的節奏，那么如何解決這個問題？Netty這個猶如救世主的框架給我們帶來了曙光！預知后事如何，待我下回分解。

參考書籍《netty權威指南》