Java NIO框架Mina、Netty、Grizzly介紹與對比

原文地址：https://blog.csdn.net/e765741668/article/details/45234711

Mina
Mina(Multipurpose Infrastructure for Network Applications) 是 Apache組織一個較新的項目，它為開發(fā)高性能和高可用性的網(wǎng)絡(luò)應(yīng)用程序提供了非常便利的框架。當(dāng)前發(fā)行的 Mina 版本2.04支持基于 JavaNIO 技術(shù)的 TCP/UDP 應(yīng)用程序開發(fā)、串口通訊程序，Mina 所支持的功能也在進(jìn)一步的擴(kuò)展中。目前，正在使用Mina的應(yīng)用包括：Apache Directory Project、AsyncWeb、AMQP（Advanced MessageQueuing Protocol）、RED5 Server（Macromedia? FlashMedia RTMP）、ObjectRADIUS、 Openfire等等。

Netty
Netty是一款異步的事件驅(qū)動的網(wǎng)絡(luò)應(yīng)用框架和工具，用于快速開發(fā)可維護(hù)的高性能、高擴(kuò)展性協(xié)議服務(wù)器和客戶端。也就是說，Netty是一個NIO客戶端/服務(wù)器框架，支持快速、簡單地開發(fā)網(wǎng)絡(luò)應(yīng)用，如協(xié)議服務(wù)器和客戶端。它極大簡化了網(wǎng)絡(luò)編程，如TCP和UDP套接字服務(wù)器。

Grizzly
Grizzly是一種應(yīng)用程序框架，專門解決編寫成千上萬用戶訪問服務(wù)器時候產(chǎn)生的各種問題。使用JAVANIO作為基礎(chǔ)，并隱藏其編程的復(fù)雜性。容易使用的高性能的API。帶來非阻塞socketd到協(xié)議處理層。利用高性能的緩沖和緩沖管理使用高性能的線程池。

結(jié)語
OK，我們現(xiàn)在可以看看三者的簡單對比了。

首先，從設(shè)計的理念上來看，Mina的設(shè)計理念是最為優(yōu)雅的。當(dāng)然，由于Netty的主導(dǎo)作者與Mina的主導(dǎo)作者是同一人，出自同一人之手的Netty在設(shè)計理念上與Mina基本上是一致的。而Grizzly在設(shè)計理念上就較差了點，幾乎是JavaNIO的簡單封裝。

其次，從項目的出身來看，Mina出身于開源界的大牛Apache組織，Netty出身于商業(yè)開源大亨Jboss，而Grizzly則出身于土鱉Sun公司。從其出身可以看到其應(yīng)用的廣泛程序，到目前為止，我見到業(yè)界還是使用Mina多一些，而Netty也在慢慢的應(yīng)用起來，而Grizzly則似乎只有Sun自已的項目使用了，如果還有其他的公司或開源項目在使用，那就算我孤陋寡聞。 最后，從入門的文檔來說，由于Mina見世時間相對較長，官方以及民間的文檔與入門示例都相當(dāng)?shù)亩唷etty的官方文檔也做得很好，而民間文檔就要相對于Mina少一些了。至于Grizzly，不管是官方還是民間，都很少見到其文檔。

Netty和mian比較報告
一、數(shù)據(jù)測試報告
簡述：1、啟動服務(wù)器，等到客戶端接入
2、客戶端發(fā)送鏈接請求。當(dāng)已經(jīng)鏈接，記錄當(dāng)前時間并向服務(wù)端發(fā)送約50m數(shù)據(jù)，每次1kb.
3、當(dāng)服務(wù)端接收到鏈接，第一次接收到數(shù)據(jù)后，記錄當(dāng)前時間
4、服務(wù)端將接收到的數(shù)據(jù)再返回給客戶端。當(dāng)服務(wù)端接收數(shù)據(jù)超過50m，則停止接收，并記錄當(dāng)前時間
5、當(dāng)客戶端接收數(shù)據(jù)量超過50m，記錄當(dāng)前時間。終止鏈接。
6、服務(wù)端和客戶端得到執(zhí)行時間。

備注：當(dāng)傳輸量達(dá)到100m時，mina拋異常：java.lang.OutOfMemoryError: Java heap space
結(jié)果：mina效率更快，netty性能更穩(wěn)。

二、codec和handler比較
以下只是個人實踐。可能會有其它辦法解決。
1、Codec比較
mina編碼解碼器(codec)創(chuàng)建實例可有以下選擇：
1) 每一次接收到的數(shù)據(jù)創(chuàng)建一次codec實例
2) 為所有client鏈接創(chuàng)建一次codec實例
netty編碼解碼器創(chuàng)建實例可有以下選擇：
1) 每一次鏈接創(chuàng)建一次codec實例
2) 為所有client鏈接創(chuàng)建一次codec實例

2、Handler比較
Mina的handler創(chuàng)建實例可有以下選擇：
1) 為所有client鏈接創(chuàng)建一次codec實例
Netty編碼解碼器創(chuàng)建實例可有以下選擇：
1) 每一次鏈接創(chuàng)建一次handler實例
2) 為所有client鏈接創(chuàng)建一次handler實例

三、文檔比較
1、netty和mina文檔都比較多，但mina文檔不齊全，netty文檔比較清晰

四、UDP協(xié)議傳輸
1、 netty將UDP無連接的特性暴露出來；而mina對UDP進(jìn)行了高級層次的抽象，可以把UDP當(dāng)成”面向連接”的協(xié)議，Netty需要手動處理順序、丟包檢測、重發(fā)等等。

五、協(xié)議支持
Netty架構(gòu)：

Mina架構(gòu)
沒有找到，但應(yīng)有類似技術(shù)支持。

網(wǎng)上評價：
1. mina將內(nèi)核和一些特性的聯(lián)系過于緊密，使得用戶在不需要這些特性的時候無法脫離，相比下性能會有所下降；netty解決了這個設(shè)計問題。
2. netty基本的架構(gòu)和mina幾乎完全一樣，使用時候思想上差不多；但是有很多細(xì)節(jié)的改進(jìn)（比如說mina的IoSession每次讀寫完要調(diào)用flip(),netty的channel則不用，并支持zero copy）。
3. netty比mina使用起來更簡單。
4. 關(guān)于UDP鏈接：mina把TCP和UDP一樣當(dāng)”有連接”的處理，一個UDP請求會按照address產(chǎn)生一個新的 IoSession，過期時間是1分鐘，這樣做的好處是顯然的，但是對于有性能要求的項目就不好了，對一個無連接的東西cache 1分鐘，大多數(shù)時候可能是白cache了，做無用功。 Mina這樣做可能還有個初衷是連續(xù)解碼用的，比如一個包太大了，分了兩次傳輸；但是這樣的設(shè)計應(yīng)該是udp大忌了

總結(jié)

以上是生活随笔為你收集整理的Java NIO框架Mina、Netty、Grizzly介绍与对比的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。