7

Java 1.4+ では、ソケット I/O でブロックされているストリームを中断する方法が 3 つあります。

  1. ソケットが通常のjava.net.Socket(InetAddress, int)コンストラクターを使用して作成された場合、別のスレッドから閉じることができます。その結果、SocketExceptionブロックされたスレッドで a がスローされます。
  2. を使用してソケットが作成された場合SocketChannel.open(...)socket()(ノンブロッキング I/O) — 繰り返しますが、別のスレッドから閉じることは可能ですがAsynchronousCloseException、ブロックされたスレッドで別の例外 ( ) がスローされます。
  3. さらに、ノンブロッキング I/O が使用されている場合は、ブロックされたスレッドをClosedByInterruptExceptionスローして中断することができます。古いスタイルの Java I/O を使用しているときにブロックされたスレッドを中断しても、スレッドには影響しません。

質問:

  1. 古いスタイルの I/O を使用している場合、スレッドセーフな別のスレッドからソケットを閉じていますか? そうでない場合、代替手段は何ですか?
  2. 代わりに NIO を使用する場合、スレッドセーフな別のスレッドからソケット/チャネルを閉じていますか?
  3. Socket.close()通常の IO とは対照的に NIO を使用する場合、動作に違いはありますか?
  4. スレッドを中断するだけでブロックされた I/O 操作を終了する可能性以外に、ネットワークに NIO を使用する利点はありますか(ソケットへの参照を保持する必要がなくなります)。
4

3 に答える 3

3

古いスタイルの I/O を使用している場合、スレッドセーフな別のスレッドからソケットを閉じていますか? そうでない場合、代替手段は何ですか?

はい。

別の方法として、ブロッキング NIO (これは SocketChannel BTW のデフォルトの動作です) を使用することです。これは、NIO の効率性とプレーン IO の単純さの一部を備えているため、接続数が少ない場合に適しています。

代わりに NIO を使用する場合、スレッドセーフな別のスレッドからソケット/チャネルを閉じていますか?

NIO をブロックする場合も、NIO をブロックしない場合も、スレッド セーフです。

通常の IO とは対照的に NIO を使用する場合、Socket.close() の動作に違いはありますか?

詳細を知る必要がある場合は、コードを読むことをお勧めしますが、基本的には同じです。

スレッドを中断するだけでブロックされた I/O 操作を終了する可能性以外に、ネットワークに NIO を使用する利点はありますか (ソケットへの参照を保持する必要がなくなります)。

接続を閉じる方法は、ほとんど問題ありません。そうです、プレーン IO よりも NIO を検討する理由はたくさんあります。

NIOの長所

  • ダイレクトメモリ使用時の高速化・軽量化
  • 何万人ものユーザーに拡張可能。
  • 効率的なビジー待ちをサポートします。

短所

  • プレーン IO はコーディングが簡単です。
  • このため、多くの API はプレーン IO のみをサポートしています。
于 2013-10-15T12:04:12.370 に答える
0

1) 例外を発生させる基になる OS 呼び出しエラーは、マルチスレッド対応の TCP スタックから発生するため、問題はないはずです。

2) わからない - 試したことはないが、何か問題があれば驚くだろう.

3) 多少の性能差がある場合があります。OS の close() 呼び出しには、TCP ピアとの 4 ウェイ ハンドシェイクが必要です。どの OS が非ブロッキング方式でそれをサポートしているかは不明です (接続と同じ)。

4) スレッド..またはソケット。何かへの参照を保持する必要があります。ソケットを閉じているので、それへの参照を保持するのが合理的です:)

于 2013-10-15T12:09:50.883 に答える