基於Java NIO框架區別對比
一.通訊框架
流行基於Java NIO通訊框架有Mina、Netty、Grizzly等。接下來說下它們之間的對比。
二.它們的出身
- Mina出身於開源界的大牛Apache組織；
- Netty出身於商業開源大亨Jboss；
- Grizzly則出身於土鱉Sun公司。
三.它們的設計理念
1、Mina
Mina(Multipurpose Infrastructure for Network Applications) 是 Apache 組織一個較新的專案，它為開發高效能和高可用性的網路應用程式提供了非常便利的框架。當前發行的 Mina 版本2.04支援基於 Java NIO 技術的 TCP/UDP 應用程式開發、串列埠通訊程式，Mina 所支援的功能也在進一步的擴充套件中。
目前，正在使用
2、Netty
Netty是一款非同步的事件驅動的網路應用框架和工具，用於快速開發可維護的高效能、高擴充套件性協議伺服器和客戶端。也就是說，Netty是一個NIO客戶端/伺服器框架，支援快速、簡單地開發網路應用，如協議伺服器和客戶端。它極大簡化了網路程式設計，如TCP和UDP套接字伺服器。
3、Grizzly
Grizzly是一種應用程式框架，專門解決編寫成千上萬使用者訪問伺服器時候產生的各種問題。使用JAVA NIO作為基礎，並隱藏其程式設計的複雜性。容易使用的高效能的API。帶來非阻塞socketd到協議處理層。利用高效能的緩衝和緩衝管理使用高效能的執行緒池。
從設計的理念上來看，Mina的設計理念是最為優雅的。當然，由於Netty的主導作者與Mina的主導作者是同一人，出自同一人之手的Netty在設計理念上與Mina基本上是一致的。而Grizzly在設計理念上就較差了點，幾乎是JavaNIO的簡單封裝。
四.Netty為什麼這麼火？
Netty是目前最流行的由JBOSS提供的一個Java開源框架NIO框架，Netty提供非同步的、事件驅動的網路應用程式框架和工具，用以快速開發高效能、高可靠性的網路伺服器和客戶端程式
相比JDK原生NIO，Netty提供了相對十分簡單易用的API，非常適合網路程式設計。Netty是完全基於NIO實現的，所以Netty是非同步的。
作為一個非同步NIO框架，Netty的所有IO操作都是非同步非阻塞的，通過Future-Listener機制，使用者可以方便的主動獲取或者通過通知機制獲得IO操作結果。
Netty無疑是NIO的老大，它的健壯性、功能、效能、可定製性和可擴充套件性在同類框架都是首屈一指的。它已經得到成百上千的商業/商用專案驗證，如Hadoop的RPC框架Avro、RocketMQ以及主流的分散式通訊框架Dubbo等等。
為什麼這麼火，是有原因的。
Netty的優點可以總結如下：
- API使用簡單，開發門檻低；
- 功能強大，預置了多種編解碼功能，支援多種主流協議；
- 定製能力強，可以通過ChannelHandler對通訊框架進行靈活地擴充套件；
- 效能高，通過與其他業界主流的NIO框架對比，Netty的綜合性能最優；
- 成熟、穩定，Netty修復了已經發現的所有JDK NIO BUG，業務開發人員不需要再為NIO的BUG而煩惱；
- 社群活躍，版本迭代週期短，發現的BUG可以被及時修復，同時，更多的新功能會加入；
- 經歷了大規模的商業應用考驗，質量得到驗證。在網際網路、大資料、網路遊戲、企業應用、電信軟體等眾多行業得到成功商用，證明了它已經完全能夠滿足不同行業的商業應用了。
與Mina相比有什麼優勢：
- 都是Trustin Lee的作品，Netty更晚；
- Mina將核心和一些特性的聯絡過於緊密，使得使用者在不需要這些特性的時候無法脫離，相比下效能會有所下降，Netty解決了這個設計問題；
- Netty的文件更清晰，很多Mina的特性在Netty裡都有；
- Netty更新週期更短，新版本的釋出比較快；
- 它們的架構差別不大，Mina靠apache生存，而Netty靠jboss，和jboss的結合度非常高，Netty有對google protocal buf的支援，有更完整的ioc容器支援(spring,guice,jbossmc和osgi)；
- Netty比Mina使用起來更簡單，Netty裡你可以自定義的處理upstream events或/和downstream events，可以使用decoder和encoder來解碼和編碼傳送內容；
- Netty和Mina在處理UDP時有一些不同，Netty將UDP無連線的特性暴露出來；而Mina對UDP進行了高階層次的抽象，可以把UDP當成"面向連線"的協議，而要Netty做到這一點比較困難。
- 從任務排程粒度上看，mina會將有IO任務的session寫入佇列中，當迴圈執行任務時，則會輪詢所有的session，並依次把session中的所有任務取出來執行。這樣粗粒度的排程是不公平排程，會導致某些請求的延遲很高。