使用Java NIO的高效读/写方法

Question

比方说，我们有SocketChannel（处于非阻塞模式），它已向Selector注册以获得读取兴趣。比方说select（）之后，Selector告诉我们这个通道已经准备好读取，并且我们有一些ByteBuffer。我们想从我们的通道读取一些字节到这个缓冲区（在读取之前，ByteBuffer被清除）。为此，我们使用channel的read（）方法返回实际读取的字节数。让我们假设从通道读取这个数字是正数，并且ByteBuffer的方法hasRemaining（）返回true。在这种情况下立即尝试从同一频道读取更多内容是否实用？ write（）的问题。如果write（）返回正值并且并非缓冲区的所有内容都已发送，那么在write（）返回0之前立即再次尝试是否可行？

Answer 1

如果您得到一个短读取结果，没有更多的数据要读取没有阻塞，所以你不能再读，直到存在。否则，下一次读取几乎肯定会返回零或-1。

如果读取填充缓冲区，从一个连接的角度来看，它可能是有意义的，直到它返回< = 0，但是您正在从其他通道中窃取周期。你也需要考虑公平。一般来说，你应该做一个阅读并继续迭代选定的键。如果有更多的数据，那么选择下次会告诉你。

使用大缓冲区。

这也意味着在每次读取之前清除缓冲区是错误的。您应该用flip/get/compact循环获取数据，然后缓冲区已准备好再次读取，您不会冒失去数据的风险。这反过来意味着您需要每个连接的缓冲区。

Answer 2

这一切都取决于数据到达的数据速率以及应用程序的延迟要求。如果您根本不关心延迟，那么您可能会延迟读取兴趣，直到您怀疑有足够的数据到达缓冲区，才会获得稍高的带宽。

虽然你必须小心。延迟读取可能会迫使内核缓冲更多数据，可能会填充缓冲区，并且必须开始丢弃数据包或以其他方式进行一些流量控制。这不仅会杀死最后一段的任何好处。

因此，一般来说，您希望尽可能早地阅读。批量读取的好处很少，最大的潜在缺陷可能很大。请记住，您看到的是非完整读取的事实意味着您正在处理数据的速度比进入的速度要快。换句话说，您处于有CPU刻录的状态，所以额外的较小读取的开销基本上是免费的。