HttpUrlConnectionスレッドは安全ですか？つまり、サーバーにHttpConnectionインスタンスが接続されていて、このインスタンスが異なるスレッドで使用されている場合（たとえば、POSTを同時に送信しようとする場合）、この状況はHttpUrlConnectionによってどのように処理されますか？a）POSTをシリアルに送信しますか、またはb）最初のスレッドがPOSTを送信し、応答を取得してから、2番目のスレッドがPOSTを送信しますか？POSTをシリアルに送信する場合、これは、同じtcp接続への複数のアクティブなPOSTを意味します。これは許可されていますか？サーバーで処理できますか？
ありがとう
スレッドセーフではありません。
接続をキャッシュ/共有しないでください。リクエストごとに新しい接続を作成するだけです。新しい接続の作成には確かに少しオーバーヘッドがありますが、それは非常に小さいので、心配する必要はありません。
HTTPの精神は、実際にはコネクションレス型です。意味的に言えば、クライアントとサーバーの間に接続はありません。クライアントはリクエストを送信し、サーバーはレスポンスを送り返します。それだけです。
今日、HTTPは実際に接続フルプロトコルであるTCPの上に定義されており、HTTPは複数の要求/応答に長寿命のTCP接続を使用する場合がありますが、これはHTTPの性質ではありません。
交換される要求/応答はほとんどのネットワークプロトコルの上に実装できるため、元々HTTPでは基盤となるプロトコルを指定する可能性がありました。電子メールを介したhttp要求/応答交換を想像できます- http:/smtp/www.example.com; 多分RMI- http:/rmi/www.example.com; デフォルトはTCPなので、http://実際にはhttp:/tcp/
現在、TCPのみが使用されており、この奇妙なダブルスラッシュ区切り文字が残っています。ただし、HTTPのTCPへの依存はかなり偶発的なものであることを思い出してください。
ドキュメントにあるかどうかはわかりません。コードを見た後（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はインスタンス変数であり、おそらくスレッド間で共有すべきではありません。
私があなたなら、メッセージをキューに投稿できるようにするキューを実装してから、一度に1つずつサーバーに投稿します。リクエストが戻ったら、コールバックを呼び出すだけです。これにより、応答が返される前に要求が送信されないようになります。