java套接字/输出流写入：它们会阻塞吗？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1338885/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
java socket / output stream writes : do they block?
提问by jbu
If I am only WRITING to a socket on an output stream, will it ever block? Only reads can block, right? Someone told me writes can block but I only see a timeout feature for the read method of a socket - Socket.setSoTimeout().
如果我只是在输出流上写入套接字，它会阻塞吗？只有读取可以阻塞，对吗？有人告诉我写可以阻塞，但我只看到套接字读取方法的超时功能 - Socket.setSoTimeout().
It doesn't make sense to me that a write could block.
写可能会阻塞对我来说没有意义。
回答by Stephen C
A write on a Socket can block too, especially if it is a TCP Socket. The OS will only buffer a certain amount of untransmitted (or transmitted but unacknowledged) data. If you write stuff faster than the remote app is able to read it, the socket will eventually back up and your writecalls will block.
对 Socket 的写入也会阻塞，特别是如果它是 TCP Socket。操作系统只会缓冲一定数量的未传输（或传输但未确认）的数据。如果你写东西的速度比远程应用程序能够读取的速度快，套接字最终会备份并且你的write调用将被阻塞。
Responding to these followup questions:
回答这些后续问题：
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?
那么是否有为此设置超时的机制？我不确定它会有什么行为……如果缓冲区已满，可能会丢弃数据？或者可能删除缓冲区中的旧数据？
There is no mechanism to set a write timeout on a java.net.Socket. There is a Socket.setSoTimeout()method, but it affects accept()and read()calls ... and not write()calls. Apparently, you can get write timeouts if you use NIO, non-blocking mode, and a Selector, but this is not as useful as you might imagine.
没有在 java.net.Socket 上设置写入超时的机制。有一种Socket.setSoTimeout()方法，但它影响accept()和read()调用......而不是write()调用。显然，如果您使用 NIO、非阻塞模式和选择器，您可以获得写入超时，但这并不像您想象的那么有用。
A properly implemented TCP stack does not discard buffered data unless the connection is closed. However, when you get a write timeout, it is uncertain whether the data that is currently in the OS-level buffers has been received by the other end ... or not. The other problem is that you don't know how much of the data from your last writewas actually transferred to OS-level TCP stack buffers. Absent some application level protocol for resyncing the stream*, the only safe thing to do after a timeout on writeis to shut down the connection.
除非连接关闭，否则正确实现的 TCP 堆栈不会丢弃缓冲数据。但是，当您遇到写入超时时，不确定当前在 OS 级缓冲区中的数据是否已被另一端接收……。另一个问题是您不知道上次write有多少数据实际传输到操作系统级 TCP 堆栈缓冲区。缺少一些用于重新同步流* 的应用程序级协议，超时后唯一安全的做法write是关闭连接。
By contrast, if you use a UDP socket, write()calls won't block for any significant length of time. But the downside is that if there are network problems or the remote application is not keeping up, messages will be dropped on the floor with no notification to either end. In addition, you may find that messages are sometimes delivered to the remote application out of order. It will be up to you (the developer) to deal with these issues.
相比之下，如果您使用 UDP 套接字，则write()调用不会阻塞很长时间。但不利的一面是，如果出现网络问题或远程应用程序没有跟上，消息将被丢弃在地板上，而不会通知任何一端。此外，您可能会发现消息有时会乱序传送到远程应用程序。由您（开发人员）来处理这些问题。
* It is theoretically possible to do this, but for most applications it makes no sense to implement an additional resyncing mechanism on top of an already reliable (to a point) TCP/IP stream. And if it did make sense, you would also need to deal with the possibility that the connection closed ... so it would be simpler to assumeit closed.
* 理论上可以这样做，但对于大多数应用程序来说，在已经可靠的（在一定程度上）TCP/IP 流之上实现额外的重新同步机制是没有意义的。如果确实有意义，您还需要处理连接关闭的可能性……因此假设它关闭会更简单。
回答by Noel Grandin
The only way to do this is to use NIO and selectors.
唯一的方法是使用 NIO 和选择器。
See the writeup from the Sun/Oracle engineer in this bug report: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4031100
请参阅此错误报告中 Sun/Oracle 工程师的文章：http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4031100
