两者都不。通道不是流的包装器（除非您通过Channels.newChannel(InputStream)或显式包装流Channels.newChannel(OutputStream)）并且它们不是“全新的概念”。
根据特定的类型，通道仍然表示可以顺序读取或写入的字节序列。您可以通过Channels类中的工厂方法在这些 API 之间进行转换这一事实表明存在一种关系。
但是 NIO API 解决了某些设计问题，这些问题无法通过重构旧的流类（以兼容的方式）来解决。例如，基本类型是现在的接口，它允许某些信道，以实现多种类型的，如ReadableByteChannel与WritableByteChannel在相同的时间。此外，没有读取单个字节的方法，这是摆脱“您可以使用 BufferedStream 来提高效率”神话的好方法。如果缓冲区大小不足是导致 I/O 性能瓶颈的原因，您首先可以通过提供更大的缓冲区来解决它，而不是将一个流或通道包装到另一个中，迫使它在缓冲区之间复制所有数据。因此，没有BufferedChannel.
FileChannel除了顺序访问之外，某些实现还提供允许随机访问底层资源的其他方法。这样，你可以使用一个统一的接口，而不是用完全不同的API处理，如用RandomAccessFile/ InputStream/OutputStream关系。
此外，在引入 NIO 时添加了许多以前缺少的 I/O 功能。其中一些本可以在旧类之上实现而不会出现问题，但设计人员显然更喜欢为所有这些类使用新的 API，从一开始就可以在设计中考虑这些功能。
但总的来说，如上所述，与流相比，通道并不是一个全新的概念。