私は読書用と送信用の2つのスレッドがあるとしましょう。書き込みが失敗した場合、他のスレッドの読み取り操作も常に失敗しますか？Javaソケットの書き込みが同時に読み込みをスローせずにスローされる可能性はありますか？
少なくとも1つのケースがあると思います（送信スレッドが中断された場合はInterruptedIOException）がありますが、それ以外のケースはありますか？もしそうなら、そのようなケースのいくつかはネットワークの問題に関連していますか？
もう1つの方法は、書き込み用にソケットをシャットダウンした場合です。あなたは書くことはできませんが、あなたはまだ読むことができます。
ソケットがもう一方の端で閉じられていると、書き込みに失敗する可能性があります（データは移動先がないため）が、読み取ることができる未読データがある可能性があります。
読み取りにタイムアウトが発生した場合は、ソケットを閉じてすべての書き込みを終了したい場合があります。例えばもう一方の端がロックされている場合これをしないと、書き込みスレッドは永久にタイムアウトしたソケットを書き込むのをブロックする可能性があります（そして永遠になる可能性があります）
本当に状況に左右されます。おそらく最も一般的な状況は接続の終了であり、これは読み書きの両方が失敗することを意味します。しかし、それは必ずしも真実ではありません。ファイアウォールの設定が奇妙になることがあります。
あなたのアドバイスは、すべての可能なシナリオを考えるのではなく、各スレッドを別々にプログラムすることです。あなたが読もうとするとできない場合、何が起こるのですか？あなたが他のスレッドに書き込もうとするとできない場合はどうなりますか？両方のスレッドが読み書きできることが非常に重要な場合は、現在のスレッドが何らかの問題を抱えている場合（および他のスレッドが当然アクティブな場合）、他のスレッドを停止させるフォールバックメカニズムを設計します。
実際に、私は、書き込みが失敗するのを待つのではなく、読み込み側を閉じることができない場合があるかどうかを知りたいと思っています。 – penpen
@penpen。エラー書き込みが未読データを破棄する必要がある場合のみ。私はこれを行う良い理由を考えることができません。 –
私は本当にはっきりしていませんでした。私が書き込みに失敗してしまった場合（もしあれば）に興味があり、読み込み側はまだブロックされています。この場合、閉じて再起動して一貫性のある状態にしたいと考えています。書き込みに関する例外が常に読み取り時にイベントにつながる場合は、実際には個別に処理する必要があります。 – penpen
私の場合、これはアプリケーションのバグであるため、これが唯一のケースであれば、それは無視できます。 – penpen
私はこれが唯一の他のケースだとは言わなかった;-) – EJP
これを答えとして選ぶと、読み込みが失敗した場合の書き込みスローが発生する場合があります。 – penpen