スレッドを正常に閉じるための、受け入れられた正しい解決策を知っています。
しかし、私のゲームがフォールト トレラントであると仮定すると、新しい gamegplay が開始されると、古いゲームプレイの (一時停止された) スレッドを適切に閉じようとします。結合/クローズに失敗した場合 (たとえば、古いスレッドにバグがあり、無限ループになっているため)、新しいスレッドをインスタンス化して開始します。しかし、古いスレッドがまだそこにあり、リソースを消費しているという事実は好きではありません。
プロセスを強制終了せずに応答しないスレッドを強制終了する方法はありますか? 実際、Thread が Thread.stop() に反応しない可能性があることをどこかで読んだことはないようです。
無限ループのスレッドを処理する方法はありません (たとえば、バグのため)。Thread.stop() に反応しても、ドキュメントによると、Thread.stop() は Dalvik VM を一貫性のない状態のままにする可能性があります...
この機能が必要な場合は、設計して実装する必要があります。明らかに、スレッドを適切にシャットダウンする方法を設計および実装しないと、スレッドを適切にシャットダウンする方法はありません。ソリューションはアプリケーション固有であるため、一般的なソリューションはありません。たとえば、スレッドが保持する可能性のあるリソースや、スレッドがロックを保持する可能性がある、または破損している可能性がある共有状態によって異なります。
正規の答えは次のとおりです。この機能が必要な場合は、スレッドを使用しないでください。プロセスを使用します。
主な理由は、スレッドの動作方法です。ロックを取得してから、共有データを操作します。その共有データを操作している間、データは一貫性のない状態になる可能性があります。ロックを解除する前にデータを一貫した状態に復元することは、スレッドの絶対的な責任です。（たとえば、二重リンクリストからオブジェクトを削除することを検討してください。最初に順方向リンクまたは逆方向リンクを調整する必要があります。これら2つの操作の間で、リンクリストは不整合な状態になります。）
あなたがこのコードを持っているとしましょう：
ロックを取得するか、同期ブロックに入ります。
ロックが保護する共有状態の変更を開始します。
バグ
ロックが保護するデータを一貫した状態に戻します。
ロックを解除します。
それで、今、私たちは何をしますか？ステップ3で、スレッドはロックを保持し、バグが発生して例外がトリガーされました。手順1で取得したロックを解放しないと、同じロックを取得しようとするすべてのスレッドが永久に待機し、運命にあります。手順1で取得したロックを解放すると、ロックを取得するすべてのスレッドは、手順4に到達しなかったため、スレッドがクリーンアップに失敗した一貫性のない共有状態を確認します。いずれにしても、運命にあります。
スレッドが例外的な状態に遭遇した場合、アプリケーションプログラマーは適切な処理方法を作成しなかったため、プロセスは運命づけられます。