java - 为什么Java IO不能实现异步读取？

Question

在 Java IO 中，我们使用 Stream 和 Reader，而在 NIO 中，我们使用 Channel，Selector。

他们做同样的事情，但结构完全不同。

那么为什么他们不写一个像“AsyncStream”这样的新 Stream 或一个像“AsyncReader”这样的 Reader 来实现 NIO 已经实现的东西。如果是这样，我们只有一个结构，而且很漂亮。

那么Java IO为什么不能实现异步读取呢？ 使用Java IO实现异步读取有哪些难点？

或者写一个新的框架而不是使用现有的框架有什么好处？

Answer 1

我试图在上面的评论中理解你的想法，但恐怕没有足够的细节来理解它作为一个建议。没有它，就不可能判断它是否有效。

但是，有几点可以作为回应:

• 如果 Java 是一种崭新的(未发布的)语言，那么他们可以在几个方面改进 I/O API 设计。
• 此外，如果有人想出一个经过深思熟虑、充实的 API 设计，结合了同步和异步功能，那么可以考虑。

但是 Java 并不是一门 Shiny 的新语言。它是一种古老的编程语言，其中编写了数十亿行源代码。您正在考虑对中央 API 进行的那种更改会要么为 Oracle 的付费客户带来巨大的二进制兼容性问题，要么会导致巨大的遗留代码问题。它根本不会发生。

撇开这一点不谈，如果您试图将同步和异步功能合并到一个 API 中，您冒着造成以下情况的风险:

• 自定义流类型需要实现很多额外的功能，和/或
• 合并会导致无法预料的性能问题。

现在这些担忧可能没有根据。

但是，如果没有看到具体的 API 设计建议和用于尝试可用性和性能的实现，我们就无法判断。请记住，最初针对 I/O 流和(当时)读者/编写者的优雅 API 设计实际上结果存在各种问题。直到人们在生产代码中使用 API 时，这些才变得明显。例如:

• 字符编码问题导致在 Java 1.1 中引入了 Reader/Writer。
• 性能分析确定内存内存到内存复制是一个问题，导致引入 Buffer 等。

总而言之，设计一个好的 I/O API 真的很难......而且 Java 无论如何都不太可能改变。