スレッドの破棄はJavaでは非推奨であり（javadocに従って実装されていません）、それを中断することは、スレッドが終了すると予想される提案にすぎませんが、終了しない可能性があります。（J VM内のスレッドを強制終了する方法を提供しないことは、邪魔な設計ですが、私の質問は設計に関連していません。）
Javaアプリケーションサーバーはどのようにアプリケーションをアンロードしますか？彼らはどういうわけかアンロードされているアプリケーションのスレッドを破壊することができますか？はいの場合、どのように？いいえの場合、無限ループを持つデプロイされたアプリの単一スレッドは、介入する可能性なしにアプリサーバー全体をダウンさせる可能性がありますか？
このためのテストケースを作成していないことを残念に思いますが、実際にそこで何が起こっているのか知りたいです。
J VM内のスレッドを強制終了する方法を提供しないのは気がかりな設計ですが、私の質問は設計とは関係ありません。
あなたの本当の質問に答えたので、上記の引用文に対処します。
歴史は、Java 設計者が最初にスレッドの強制終了と一時停止の問題に対処しようとしたことですが、Java 言語のコンテキストでは解決できない根本的な問題に遭遇しました。
問題は、非アトミックな方法で共有データを変更できるスレッドや、待機/通知メカニズムを使用して他のスレッドと同期できるスレッドを安全に強制終了できないことです。このコンテキストでスレッドの強制終了を実装すると、データ構造が部分的に更新され、他のスレッドが到着しない通知を待機することになります。つまり、1 つのスレッドを強制終了すると、アプリケーションの残りの部分が不安定で壊れた状態になる可能性があります。
スレッドを強制終了できる他の言語/ライブラリ (C、C++、C# など) は、関連する仕様/教科書で明確にされていなくても、上記と同じ問題に悩まされます。スレッドを強制終了することは可能ですが、これを安全に行うには、アプリケーション全体の設計と実装に細心の注意を払う必要があります。一般的に言えば、正しくするのは難しすぎます。
では、(仮説として) Java でスレッドの強制終了を安全に行うには何が必要でしょうか? ここにいくつかのアイデアがあります：
JVM が Isolate を実装している場合は、子 Isolate で強制終了したい計算を起動できます。問題は、適切に実装されたisolateがメッセージパッシングによってのみ他のisolateと通信できることであり、一般にそれらを使用するとはるかにコストがかかります。
ミュータブルな共有状態の問題は、ミューテーションを完全に禁止するか、Java 実行モデルにトランザクションを追加することで対処できます。これらは両方とも Java を根本的に変えるでしょう。
待機/通知の問題は、対話していたスレッドがなくなったことを「他の」スレッドに通知できるランデブーまたはメッセージパッシングメカニズムに置き換えることで対処できます。これから回復するには、「他の」スレッドをコーディングする必要があります。
編集- コメントへの応答。
thread.destroy()破棄されたスレッドが所有するすべてのミューテックスを解放 (中断) するように設計されているため、ミューテックスのデッドロックは問題ではありませんでした。問題は、ミューテックスによって保護されたデータ構造が、ロックが解除された後に正常な状態になるという保証がないことでした。
このトピックの歴史を正しく理解していればThread.suspend()、Thread.delete()など は実際の Java 1.0 アプリケーションで実際に問題を引き起こしました。そして、これらの問題は非常に深刻で、アプリケーション作成者が対処するのが非常に困難だったため、JVM 設計者はメソッドを非推奨にすることが最善の方法であると判断しました。これは簡単な決断ではなかったでしょう。
さて、勇気があれば、実際にこれらの方法を使用できます。また、場合によっては実際に安全な場合もあります。しかし、非推奨のメソッドを中心にアプリケーションを構築することは、健全なソフトウェア エンジニアリングの実践ではありません。
ejbサーバー内に独自のスレッドを作成することは許可されていません。
Webコンテナ（Tomcatなど）でスレッドを生成することは珍しくありませんが、それを行うことについては慎重に検討する必要があります。また、これらのスレッドのライフサイクルを管理するようにしてください。