傳統(tǒng)的 Java I/O API 在應(yīng)對(duì)不同的傳輸協(xié)議時(shí)需要使用不同的類型和方法。例如：java.net.Socket 和 java.net.DatagramSocket 它們并不具有相同的超類型，因此，這就需要使用不同的調(diào)用方式執(zhí)行 socket 操作。

這種模式上的不匹配使得在更換一個(gè)網(wǎng)絡(luò)應(yīng)用的傳輸協(xié)議時(shí)變得繁雜和困難。由于（Java I/O API）缺乏協(xié)議間的移植性，當(dāng)你試圖在不修改網(wǎng)絡(luò)傳輸層的前提下增加多種協(xié)議的支持，這時(shí)便會(huì)產(chǎn)生問(wèn)題。并且理論上講，多種應(yīng)用層協(xié)議可運(yùn)行在多種傳輸層協(xié)議之上例如TCP/IP,UDP/IP,SCTP和串口通信。

讓這種情況變得更糟的是，Java 新的 I/O（NIO）API與原有的阻塞式的I/O（OIO）API 并不兼容，NIO.2(AIO)也是如此。由于所有的API無(wú)論是在其設(shè)計(jì)上還是性能上的特性都與彼此不同，在進(jìn)入開(kāi)發(fā)階段，你常常會(huì)被迫的選擇一種你需要的API。

例如，在用戶數(shù)較小的時(shí)候你可能會(huì)選擇使用傳統(tǒng)的 OIO(Old I/O) API，畢竟與 NIO 相比使用 OIO 將更加容易一些。然而，當(dāng)你的業(yè)務(wù)呈指數(shù)增長(zhǎng)并且服務(wù)器需要同時(shí)處理成千上萬(wàn)的客戶連接時(shí)你便會(huì)遇到問(wèn)題。這種情況下你可能會(huì)嘗試使用 NIO，但是復(fù)雜的 NIO Selector 編程接口又會(huì)耗費(fèi)你大量時(shí)間并最終會(huì)阻礙你的快速開(kāi)發(fā)。

Netty 有一個(gè)叫做 Channel 的統(tǒng)一的異步 I/O 編程接口，這個(gè)編程接口抽象了所有點(diǎn)對(duì)點(diǎn)的通信操作。也就是說(shuō)，如果你的應(yīng)用是基于 Netty 的某一種傳輸實(shí)現(xiàn)，那么同樣的，你的應(yīng)用也可以運(yùn)行在 Netty 的另一種傳輸實(shí)現(xiàn)上。Netty 提供了幾種擁有相同編程接口的基本傳輸實(shí)現(xiàn)：

基于 NIO 的 TCP/IP 傳輸 (見(jiàn) io.netty.channel.nio),
基于 OIO 的 TCP/IP 傳輸 (見(jiàn) io.netty.channel.oio),
基于 OIO 的 UDP/IP 傳輸, 和
本地傳輸 (見(jiàn) io.netty.channel.local).

切換不同的傳輸實(shí)現(xiàn)通常只需對(duì)代碼進(jìn)行幾行的修改調(diào)整，例如選擇一個(gè)不同的 ChannelFactory 實(shí)現(xiàn)。

此外，你甚至可以利用新的傳輸實(shí)現(xiàn)沒(méi)有寫(xiě)入的優(yōu)勢(shì)，只需替換一些構(gòu)造器的調(diào)用方法即可，例如串口通信。而且由于核心 API 具有高度的可擴(kuò)展性，你還可以完成自己的傳輸實(shí)現(xiàn)。

上一篇：查看收到的數(shù)據(jù)下一篇：開(kāi)始