通道是否包裝IO流？

Question

我想知道區分，以清除概念差異，因爲我已經看到SocketChannel,FileChannel等類。與Socket和文件I/O流

相比，我知道，I/O流必須被順序訪問，即它們是可以讀取和寫入的字節序列。您還可以使用緩衝流來提高I/O的效率。

因此，與Streams相比，「Channels」是一個全新的概念還是僅僅是Streams的包裝？

是的，如果我們說「流是一個字節序列」，那麼如果兩者都不相同，那麼Channel是什麼意思？

Answer 1

也沒有。頻道不是流媒體周圍的包裝（除非您明確地通過Channels.newChannel(InputStream)或Channels.newChannel(OutputStream)包裝流），它們不是「全新的概念」。

根據具體的類型，通道仍然代表可以順序讀取或寫入的一系列字節。您可以通過Channels類中的工廠方法在這些API之間進行翻譯，這一事實表明存在關係。

但是，NIO API解決了某些設計問題，這些問題無法通過重構舊的流類（以兼容的方式）來解決。例如。基礎類型現在是接口，它允許某些通道同時實現多種類型，如ReadableByteChannel和WritableByteChannel。此外，沒有讀取單個字節的方法，這是擺脫「您可以使用BufferedStream來提高效率」的神話的好方法。如果緩衝區大小不足是造成I/O性能瓶頸的原因，那麼首先要提供一個更大的緩衝區來解決它，而不是將流或通道封裝到另一個緩衝區，迫使它在緩衝區之間複製所有數據。因此，沒有BufferedChannel。

某些實現（如FileChannel）除了順序訪問外，還提供了允許隨機訪問底層資源的其他方法。這樣，您就可以使用統一的界面，而不是處理完全不同的API，例如與關係相關的RandomAccessFile/InputStream/關係。

此外，當引入NIO時，還添加了許多以前丟失的I/O功能。它們中的一些可能已經在舊類的基礎上實現了，沒有任何問題，但是設計人員明顯青睞使用新的API，因爲這些功能從一開始就可以在設計中考慮到。

但是，如上所述，通常情況下，與流相比，渠道並不是一個全新的概念。