为什么 Java 中的 FileChannel 不是非阻塞的？答案

【问题标题】：Why FileChannel in Java is not non-blocking?为什么 Java 中的 FileChannel 不是非阻塞的？
【发布时间】：2010-10-17 20:55:28
【问题描述】：

我想写一个同时写入多个文件的程序；认为通过使用非阻塞模式可以使用一个线程。但 FileChannel 不支持非阻塞模式。有人知道为什么吗？

【问题讨论】：

标签： java nio

【解决方案1】：

UNIX 不支持文件的非阻塞 I/O，请参阅 Non-blocking I/O with regular files。由于 Java 应该（至少尝试）在所有平台上提供相同的行为，FileChannel 没有实现 SelectableChannel。

不过，Java 7 将包含一个新的AsynchronousFileChannel 类，该类支持异步文件 I/O，这是与非阻塞 I/O 不同的机制。

通常只有套接字和管道通过select() 机制真正支持非阻塞 I/O。

【讨论】：

这仍然有效吗？目前我们可以在从文件描述符读取时设置 O_NONBLOCKING。然后读取发现该文件没有数据，则立即返回。
你有任何证据表明这真的会发生吗？根据我链接到的文章，设置 O_NONBLOCKING 对常规文件没有影响。你有证据表明它确实有效果吗？也许是一个最小的可重复的例子？除非有人能提供明确的相反证据，否则我倾向于认为它仍然有效。

【解决方案2】：

简单地说，大多数操作系统不会将常规文件视为可以阻塞的东西 - 因此它们不允许您将它们显式设置为非阻塞状态。

【讨论】：

文件 I/O 只能是阻塞的，因为它们被认为是非阻塞的？你是什么意思？在编程中，每一个操作都是阻塞的。
@Val 我同意这里的措辞不是最好的。在编程中，并非每个操作都是阻塞的（从某种意义上说，它将进程或线程置于阻塞状态）。我的意思是，对于常规文件，操作系统级别的 API 假定 read()/write()/open() 和对常规文件的其他调用是非阻塞的——尽管这是一个错误的假设。常规/标准操作系统级 API 无法将文件句柄从阻塞更改为非阻塞。（这是你可以用套接字和管道句柄做的事情）。
@nos 操作系统级 API 假定 read()/write()/open() 和其他调用是阻塞。不清楚你在说什么。
@EJP 我不认为 read() write() 假设任何关于阻塞或不阻塞的事情。对于某些类型的设备，您当然可以使 read()/write() 成为非阻塞的。我只是说您不能在引用常规文件的文件描述符上设置或清除 O_NONBLOCK（或任何类似的属性）并观察任何差异。那例如select() 调用总是告诉您文件描述符是可读可写的。虽然 read() 或 write() 它可能在现实中阻塞，但操作系统仍然没有为程序员提供任何方式来控制、了解或通知它阻塞