java套接字/输出流写入: do they block?

Question

如果我只是在输出流上写入套接字，它会阻塞吗？只有读取可以阻塞，对吗？有人告诉我写可以阻塞，但我只看到套接字读取方法的超时功能 - Socket.setSoTimeout()。

对我来说，写可能会阻塞是没有意义的。

Answer 1

对 Socket 的写入也可能会阻塞，尤其是在它是 TCP Socket 的情况下。操作系统只会缓冲一定数量的未传输(或传输但未确认)的数据。如果你写东西的速度比远程应用程序读取的速度快，套接字最终会备份，你的 write 调用将阻塞。

回答这些后续问题:

So is there a mechanism to set a timeout for this? I'm not sure what behavior it'd have...maybe throw away data if buffers are full? Or possibly delete older data in the buffer?

没有在 java.net.Socket 上设置写入超时的机制。有一个 Socket.setSoTimeout() 方法，但它影响 accept() 和 read() 调用...而不是 write() 调用。显然，如果您使用 NIO、非阻塞模式和 Selector，您可以获得写入超时，但这并不像您想象的那么有用。

除非连接关闭，否则正确实现的 TCP 堆栈不会丢弃缓冲的数据。但是，当您收到写入超时时，不确定当前位于操作系统级缓冲区中的数据是否已被另一端接收......另一个问题是您不知道上一次 write 中的数据有多少实际传输到了操作系统级别的 TCP 堆栈缓冲区。缺少一些用于重新同步流的应用程序级协议(protocol)^*，在 write 超时后唯一安全的做法是关闭连接。

相比之下，如果您使用 UDP 套接字，则 write() 调用不会阻塞很长时间。但不利的一面是，如果出现网络问题或远程应用程序跟不上，消息将被丢弃在地板上，而不会通知任何一方。此外，您可能会发现消息有时会乱序传递到远程应用程序。由您(开发者)来处理这些问题。

^{* 理论上可以做到这一点，但是对于大多数应用程序来说，在已经可靠(到一定程度)的 TCP/IP 流之上实现额外的重新同步机制是没有意义的。如果它确实有意义，您还需要处理连接关闭的可能性......所以假设它关闭会更简单。}