在學習Java NIO和IO的API時,經常會出現以下疑問?
什麼時候我應該用IO,什麼時候我應該用NIO?
在這篇文章中我將發表我關於NIO與IO的區別的觀點,它們的使用案例,以及它們如何影響你程式碼的設計。
Java NIO與IO的主要區別
IO | NIO |
---|---|
面向流 | 面向緩衝 |
阻塞IO | 非阻塞IO |
無Selector | Selectors |
面向流與面向緩衝
Java NIO與IO最大的不同之處在IO是面向流的,而NIO是面向緩衝的。但是,這意味著什麼呢?
Java IO面向流意味著你一次會從流中讀取一個或多個位元組。對於讀取到的位元組怎麼處理由你自己決定。這些位元組是不會被快取的。更一步,流中的資料並不能前面移動。如果需要前後移動資料,需要先將資料進行快取。
而Java NIO面向快取的方式稍有不同。需要後續處理的資料是先放到快取中的。可以在快取中前後移動。這使得資料處理變得更加靈活。然而,你需要檢查快取裡是否包含了需要處理的完整資料。並且,也需要保證沒有處理過的資料在寫入新資料時不會被覆蓋。
阻塞與非阻塞
Java IO的各種流是阻塞的。這意味著,當一個執行緒呼叫read() 或 write()時,該執行緒被阻塞,直到有一些資料被讀取,或資料完全寫入。該執行緒在此期間不能再幹任何事情了。 Java NIO的非阻塞模式,使一個執行緒從某通道傳送請求讀取資料,但是它僅能得到目前可用的資料,如果目前沒有資料可用時,就什麼都不會獲取。而不是保持執行緒阻塞,所以直至資料變的可以讀取之前,該執行緒可以繼續做其他的事情。 非阻塞寫也是如此。一個執行緒請求寫入一些資料到某通道,但不需要等待它完全寫入,這個執行緒同時可以去做別的事情。 執行緒通常將非阻塞IO的空閒時間用於在其它通道上執行IO操作,所以一個單獨的執行緒現在可以管理多個輸入和輸出通道(channel)。
Selector
Java NIO Selector允許一個執行緒來控制多個輸入通道。可以用一個Selector註冊多個Channle。然後,用一個執行緒來選擇已經準備好資料處理的Channel或都那些準備好寫的Channel。選擇器的機制使得用一個執行緒來控制多個Channel變得非常容易。
NIO和IO如何影響應用程式的設計
無論你選擇NIO或IO工具箱,可能會影響你應用程式的以下幾個方面:
- 對NIO或IO類的API呼叫。
- 資料處理。
- 用來處理資料的執行緒數。
API呼叫
當然,在使用IO時,NIO與IO的API呼叫有點不同。這一點也不奇怪。並不是直接從InputStream中直接讀取資料,NIO必須先將資料讀入到快取中,再進行後續處理。
資料處理
使用純粹的NIO設計相較IO設計,資料處理也受到影響。
在IO設計時,資料是從InputStream或Reader中讀取的。假設你正在處理基於文字的資料,像這樣:
Name: Anna
Age: 25
Email: anna@mailserver.com
Phone: 1234567890
複製程式碼
文字行的流可以像這樣處理:
InputStream input = ... ; // get the InputStream from the client socket
BufferedReader reader = new BufferedReader(new InputStreamReader(input));
String nameLine = reader.readLine();
String ageLine = reader.readLine();
String emailLine = reader.readLine();
String phoneLine = reader.readLine();
複製程式碼
請注意處理狀態由程式執行多久決定。換句話說,一旦reader.readLine()方法返回,你就知道肯定文字行就已讀完, readline()阻塞直到整行讀完,這就是原因。你也知道此行包含名稱;同樣,第二個readline()呼叫返回的時候,你知道這行包含年齡等。 正如你可以看到,該處理程式僅在有新資料讀入時執行,並知道每步的資料是什麼。一旦正在執行的執行緒已處理過讀入的某些資料,該執行緒不會再回退資料(大多如此)。下圖也說明了這條原則:
在NIO實現中這將會變得有點不一樣,下面是一個簡單的例子。
ByteBuffer buffer = ByteBuffer.allocate(48);
int byteRead = inChannel.read(buf);
複製程式碼
注意到將Channel中的資料讀入到Buffer中的第二行。當那個方法返回時,其實並不知道所需要的資料是否都已經寫入到Buffer中了。僅僅知道的是一些資料已經寫入到Buffer中了。這使得資料處理變得有點麻煩。
想像一下,當呼叫完第一個read(buufer)方法時,僅有半行的資料被讀入到Buffer中。例如,“Name:An”。你量否可以處理這個資料?並不能。在有效處理資料之前必須等到至少有一行資料被讀入到Buffer中才行。
所以,如何能夠知道uffer中包含了能夠有效處理的足夠的資料呢?其實並不能。唯一的方法是檢查Buffer中的資料。這個結果是,你必須多次檢查Buffer中的資料來判斷資料是否完整。不僅效率低下,而且可以使程式設計方案雜亂不堪。例如:
ByteBuffer buffer = ByteBuffer.allocate(48);
int bytesRead = inChannel.read(buffer);
while(! bufferFull(bytesRead) ) {
bytesRead = inChannel.read(buffer);
}
複製程式碼
bufferFull()方法需要跟蹤讀入buffer中的位元組數並根據buffer是否滿了來返回true或false。換句話說,如果buffer已經準備好處理了,它將認為是full的。
bufferFull()方法掃描緩衝區,但必須保持在bufferFull()方法被呼叫之前狀態相同。如果沒有,下一個讀入緩衝區的資料可能無法讀到正確的位置。這是不可能的,但卻是需要注意的又一問題。
如果緩衝區已滿,它可以被處理。如果它不滿,並且在你的實際案例中有意義,你或許能處理其中的部分資料。但是許多情況下並非如此。下圖展示了“緩衝區資料迴圈就緒”:
總結
NIO可以讓你僅使用一個或少量的執行緒來管理多個通道(網路或檔案)。但是分析資料會比阻塞的IO流更加複雜。
如果你需要同時管理成千上萬個連線,並且這個連線只傳送少量的資料。比如,一個用NIO方式實現的聊天伺服器將變得非常有優勢。類似的,如果需要跟其他計算機保持大量的連線,如P2P網路。使用一個執行緒來管道外部連線可以也是一個優勢。單個線條,多個連線的方式如下圖所示:
如果只有少量連線,但每個連線都有佔用大量的頻寬,每次需要傳送大量的資料,也許採用阻塞的IO將會更加適合。下圖展示一個IO伺服器的設計: