java httpurlconnection 线程安全
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3272681/
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
httpurlconnection thread safety
提问by Cratylus
Is HttpUrlConnection thread safe? I.e. if I have an HttpConnection instance connected to a server and this instance is used by different threads (e.g.try to send a POST concurrently) how will this situation be handled by HttpUrlConnection? a) Will they send the POSTs serially, or b) the first thread sends the POST, gets the response and then the second thread will send the POST? If they send the POSTs serially, this means multiple active POSTs to the same tcp connection. Is this allowed? Can it be handled by a server?
HttpUrlConnection 线程安全吗？即，如果我有一个连接到服务器的 HttpConnection 实例，并且该实例被不同的线程使用（例如尝试同时发送 POST），HttpUrlConnection 将如何处理这种情况？a) 他们会串行发送 POST，还是 b) 第一个线程发送 POST，获得响应，然后第二个线程将发送 POST？如果它们串行发送 POST，这意味着多个活动 POST 到同一个 tcp 连接。这是允许的吗？可以由服务器处理吗？
Thanks
谢谢
回答by irreputable
it's not thread safe.
它不是线程安全的。
you shouldn't cache/share a connection. just create a new connection for each request. there is certainly a little overhead in creating new connections, but it is very small, you shouldn't worry about it.
您不应该缓存/共享连接。只需为每个请求创建一个新连接。创建新连接肯定会有一些开销，但它非常小，您不必担心。
the spiritof HTTP is actually connection-less. there is no, semantically speaking, connection between client and server. client sends a request, server sends back a response, that is all.
HTTP的精神实际上是无连接。从语义上讲，客户端和服务器之间没有连接。客户端发送请求，服务器返回响应，仅此而已。
although today HTTP is indeed defined on top of TCP, which is a connection-ful protocol, and HTTP may use long lived TCP connection for multiple requests/responses, that's not the nature of HTTP.
尽管今天 HTTP 确实是在 TCP 之上定义的，TCP 是一个连接协议，并且 HTTP 可能使用长寿命 TCP 连接来处理多个请求/响应，但这不是 HTTP 的本质。
since a request-response exchanged can be implemented on top of most network protocols, originally HTTP allowed possibility of specifying underlying protocols. We can imagine http request/response exchange over email - http:/smtp/www.example.com; maybe RMI - http:/rmi/www.example.com; the default is TCP, so http://really means http:/tcp/
由于交换的请求-响应可以在大多数网络协议之上实现，最初 HTTP 允许指定底层协议的可能性。我们可以想象通过电子邮件的 http 请求/响应交换 - http:/smtp/www.example.com; 也许RMI - http:/rmi/www.example.com; 默认是 TCP，所以http://真的意味着http:/tcp/
today, only TCP is used, and we are left with this curious double slash separator. but it's a reminder that HTTP's dependency on TCP is rather incidental.
今天，只使用 TCP，我们留下了这个奇怪的双斜线分隔符。但它提醒我们 HTTP 对 TCP 的依赖是相当偶然的。
回答by Romain Hippeau
It does not say if it is or not in the docs. After looking at the code ( http://www.java2s.com/Open-Source/Java-Document/6.0-JDK-Modules-sun/net/sun/net/www/protocol/http/HttpURLConnection.java.htm) it looks like getInputStream and getOutputStream are synchronized. The concern I do have is that if you have a Thread that gets an input Stream and at the same time you have another Thread that gets an Output Stream you might get your signals crossed. inputStream and outputStream are instance variables that probably should not be shared across Threads.
它没有说明它是否在文档中。查看代码后（http://www.java2s.com/Open-Source/Java-Document/6.0-JDK-Modules-sun/net/sun/net/www/protocol/http/HttpURLConnection.java.htm）看起来 getInputStream 和 getOutputStream 是同步的。我确实担心的是，如果您有一个获取输入流的线程，同时您有另一个获取输出流的线程，您可能会交叉信号。inputStream 和 outputStream 是可能不应跨线程共享的实例变量。
If I were you I would implement a queue that would allow you to post the messages to the queue and would then post them to the server one at a time. When the request returns then you simply invoke a callback. This would make sure that a request was not sent before a response came back.
如果我是你，我会实现一个队列，允许你将消息发布到队列，然后一次一个地将它们发布到服务器。当请求返回时，您只需调用一个回调。这将确保在响应返回之前不会发送请求。
