在Java IO中，我们使用Stream和Reader，而在NIO中使用Channel，Selector。
它们都做同样的事情，但结构完全不同。
那么为什么他们不编写像"AsyncStream"这样的新Stream或像"AsyncReader"这样的阅读器来实现NIO已经实现的东西。如果是这样，我们只有一个结构，它很漂亮。
那么为什么Java IO不能实现异步读取呢？ 使用 Java IO 实现异步读取有哪些困难？
或者编写新框架而不是使用现有框架有什么优势？
我试图在上面的评论中理解你的想法，但恐怕没有足够的细节来理解它作为一个建议。 没有这一点，就不可能判断它是否有效。
但是，有几点可以作为回应：
- 如果Java是一种闪亮的新(和未发布的(语言，那么他们可以在几个方面改进I/O API设计。
- 此外，如果有人想出了一个经过深思熟虑的、充实的 API 设计，结合了同步和异步功能，那么可以考虑。
但是Java并不是一门闪亮的新语言。 它是一种古老的编程语言，其中编写了数十亿行源代码。 您正在考虑在中央API上进行的更改可能会给Oracle的付费客户带来巨大的二进制兼容性问题，或者会导致巨大的遗留代码问题。 它根本不会发生。
撇开这一点不谈，如果您尝试将同步和异步功能合并到单个 API 中，则可能会造成以下情况：
- 自定义流类型需要实现许多额外的功能，和/或
- 合并会导致意想不到的性能问题。
现在，这些担忧可能没有根据。
但是，如果没有具体的 API 设计提案和尝试可用性和性能的实现，我们就无法判断。 请记住，I/O 流和(当时(读取器/写入器的原始优雅 API 设计实际上存在各种问题。 直到人们在生产代码中使用 API，这些才变得明显。 例如：
- 字符编码问题导致在Java 1.1中引入了
Reader/Writer。 - 性能分析发现内存到内存复制是一个问题，导致引入
Buffer等等。
综上所述，设计一个好的 I/O API 真的很难......无论如何，Java都不太可能改变。