私はサーブレットを作成しています。サーブレットはJavaサーブレットコンテナ（JBoss、Jetty、Tomcat、GlassFishなど）で実行されます。サーブレットコンテナはいつスレッドを中断しますか？
サーブレットコンテナがHTTPリクエストハンドラを実行しているスレッドを中断する理由は何ですか？それはシャットダウン時にのみ行うのだろうか？それはクライアントが応答していないときに行うのでしょうか？
標準化されているか、自由に自由に使える容器ですか？
明確にするために、私が作成した新しいスレッドの中断について、私の要求が実行されているサーブレットコンテナのスレッドについてのみではありません。 （答えに新しいスレッドに何が起こるかを言えば面白いだろうが）。
サーブレットコンテナがHTTPリクエストハンドラを実行しているスレッドを中断する理由は何ですか？
これはコンテナ自体によって異なります。サーブレット仕様では実際には標準化されていません。
シャットダウン時のみ有効ですか？
最も明白な理由の1つと思われます。ローカルのテストでは、少なくともTomcat 7.0.22とGlassfish 3.1.1はサーブレットの処理をただちに中断せずにすべてのサーブレットの処理を中止することを教えてくれました。その時点で例外はスローされません。
クライアントが応答していないときはどうなりますか？
リクエストヘッダーが完全に到着していない場合のみ。ソケット接続にはコンテナ固有のタイムアウトがあり、通常は60秒です。しかし、リクエストヘッダーが完全に到着していない場合、サーブレットメソッドはとにかく入力されません。要求ヘッダーが完全に到着した場合のみ、サーブレットメソッドが入力されます。
次に、サーブレットのメソッドの内部。クライアントがリクエスト本体（POSTなど）を提供していて、サーブレットのコードがリクエスト本体の読み込みを開始する場合（request.getParameter()またはrequest.getInputStream()）、クライアントがリクエスト本体の送信を中止したときにはIOExceptionが返されます。一方、レスポンスに書いて（そしてflush/commitする）、クライアントがその時点で接続を打ち切ると、IOExceptionもスローされます。必要に応じてtry-catchに入れることができますが、ロギングだけではそれ以上のことはできません。これらのロギングの有用性は非常に疑問であり、サーバーログを混乱させる可能性があります。
基本的に、サーブレットコードで 'InterruptedException'を無視することはできません。 –
はい。さらに、スレッド*を自分で作成して管理している場合にのみ、そのスレッドを捕まえることができます。 – BalusC
私はそれをスローする 'process.waitFor（）'で捕まえることができます。 –
「スレッド」と言ったときのあいまいさを避けるため、実際には「HTTPリクエスト」ですか？ – BalusC
これは技術的にはスレッドを中断させ、スレッドが自分のHTTP要求を実行したときに発生します。だから私はそれを書く方法がわからない。言い換えれば、より良いことを願っています。 –
独自のスレッドを生成する場合、シナリオは非常に異なります。したがって、どのスレッドが正確にどのスレッドを意味し、どのように作成されたのか、そしてそれがデーモンスレッドであるかどうかなどを明確にする必要があります。 – BalusC