Java NIO：何时正确切换OP_WRITE和OP_READ

Question

作为一些背景：

我有一个连接到一个服务器的SocketChannel、SelectionKey...等等。在客户端，如果我想向服务器发送一些东西，我只需将我的数据写入一个ByteBuffer中，并通过套接字通道发送。如果全部都写好了，我就完成了，可以返回到op_read。如果没有写完，我就取剩下的字节，将它们存储在某个地方的“发送”缓冲区中，并在密钥上标记OP_WRITE（替换OP_READ，使其仅写是一个好主意吗？）。

• 我是否应该将它保留在OP_WRITE中，直到所有的数据都被刷新完？还是应该更改为OP_READ，并尝试在两者之间进行任何读取？

如果写入通道已经满了，我不能写了，我是不是一直循环直到我可以开始写东西？如果连接突然阻塞，我不确定是否应该只写我能写的，翻转回OP_READ，尝试读取，然后翻转回op_write。从我读到的内容来看，这似乎不是一种正确的做事方式（并且可能会导致大量的开销不断地来回切换？）。

• 当缓冲区都可能满时，处理大容量数据的读写的最佳方法是什么？

Answer 1

我是不是应该把它留在OP_WRITE中直到所有的数据都被刷新完？或者我应该更改为OP_READ，并尝试在两者之间进行任何读取？

对此有不同的看法。我的观点是，同伴应该在发送新请求之前阅读你发送的响应的每一部分，如果他没有阅读，他只是行为不端，你不应该提前阅读。否则，您最终只会耗尽内存，而您不应该让客户机对您这样做。当然，这假设您是请求-响应协议中的服务器。其他情况有各自的要求。

如果写入通道已经满了，我不能写了，我是不是一直循环直到我可以开始写东西？

如果连接突然阻塞，我不确定是否应该只写我能写的，翻转回OP_READ，尝试读取，然后翻转回op_write。从我读到的内容来看，这似乎不是一种正确的做事方式（并且可能会导致大量的开销不断地来回切换？）。

开销并不是很大，但在我上面描述的情况下，这样做是错误的。

当缓冲区都可能变满时，处理大容量数据读写的最佳方法是什么？

是的，否则你只是抽CPU。