問題タブ [executors]

Executors.newFixedThreadPool（100）メソッドを使用しています。1回のコマンド実行には約20スレッドが必要です。コマンドを5〜6回実行すると、アプリケーションは応答を停止します。私のスレッドはCallableを実装しています。

そのスレッドは完了後に終了しないのではないかと思います。また、shutdown（）を呼び出してスレッドを終了しました。

get（）メソッドを使用してスレッドの結果を取得すると、終了する（つまり、キューから削除される）のか、それともプールがスレッドを格納するために使用するキューにまだ存在するのか、誰か教えてください。

送信したタスクをシリアル順に実行するために、singleThreadExecutor があります。つまり、タスクを 1 つずつ実行し、並列実行しません。

私はこのようなものになるrunnableを持っています

}

たとえば、MyRunnable の 3 つのインスタンスを前述のシングル スレッド エグゼキュータに送信すると、最初のタスクが実行されると予想されます。Thread.sleep には実行中のスレッドが TIMED_WAITING にあるためです (具体的には間違っている可能性があります)。州）。他の 2 つのタスクには、少なくとも最初のタスクが終了するまで、それらを実行するためのスレッドを割り当てないでください。

したがって、私の質問は、FutureTask API を介してこの状態を取得する方法、または何らかの方法でタスクを実行しているスレッドに到達する方法です (そのようなスレッドがない場合、タスクは実行または保留中を待機しています)。他の意味？

FutureTask は isCanceled() および isDone() メソッドのみを定義していますが、それらは Task の考えられるすべての実行ステータスを説明するには十分ではありません。

生産者/消費者パターンについての私の理解は、生産者と消費者の間で共有されるキューを使用して実装できるということです。プロデューサーは作業を共有キューに送信し、コンシューマーはそれを取得して処理します。また、プロデューサーがコンシューマーに直接送信することによって実装することもできます（プロデューサースレッドがコンシューマーのエグゼキューターサービスに直接送信します）。 

今、私はスレッドプールのいくつかの一般的な実装を提供するExecutorsクラスを見てきました。仕様によると、メソッドnewFixedThreadPoolは、「共有された無制限のキューで動作する固定数のスレッドを再利用します」。彼らはここでどのキューについて話しているのですか？ 

プロデューサーがタスクをコンシューマーに直接送信する場合、ランナブルのリストを含むのはExecutorServiceの内部キューですか？

それとも、プロデューサーが共有キューに送信する場合の中間キューですか？ 

私は全体のポイントを逃しているかもしれませんが、誰かが明確にしてください？

アプリケーションでスレッドプールを使用しています。TreadPoolExecutor をサブクラス化し、メソッド beforeExecute、afterExecute をオーバーライドし、統計目的で終了しました。
また、独自の ThreadFactory を実装し、newThread メソッドをオーバーライドしました。

スレッドプール ラッパー クラスは多数の「呼び出し可能な」タスクを作成し、invokeAll メソッドを呼び出して結果を取得することを理解しています。各タスクには、インターフェイス オブジェクトがあります。ベース X オブジェクトはインターフェースを実装し、何度もサブクラス化されています。そのため、スレッドプールが実行されると、オブジェクト X の子が起動されます。

コードの観点からは、次のようになります。

私の質問は、前と後の実行フックを呼び出すときに、呼び出し可能なタスクに保持されている情報を取得する方法です。または、スレッドプールの各スレッドに特定の名前を付けることは可能ですか?

Runnable オブジェクト/FutureTask/callable に隠されているデバッグ モードの Eclipse 変数ビューに情報があることがはっきりとわかります。

メソッド (beforeExecute、afterExecute) を Runnable オブジェクトでオーバーライドし、Callable オブジェクトをオーバーライドする必要がない理由がわかりません (結果を取得する必要があるため)。私が見逃している、または理解していないものはありますか？FutureTask をサブクラス化する必要があるかもしれません。

ご協力いただきありがとうございます、

新しいタスクをキューの一番上に追加するか一番下に追加するかを選択できる Executor が必要です。それを達成する最も簡単な方法は何ですか？

割り当ては、非常に単純化されたコンピューティング「クラウド」を実装することです。クラウド インスタンス (「エンジン」) は、定期的にキープアライブ メッセージ (「コマンド」) をスーパーバイザーに送信することになっています。次のタスクを使用してこれを実装しました。

これは、 scheduleAtFixedRate()を使用して実行がスケジュールされています。長時間実行されるタスクへの明示的な参照を保持する必要がないように、shutdownNow()を使用して適切な (ish) シャットダウンを行っています。

タスクに固有のクリーンアップを実行する「クリーンな」方法はありますか (を閉じるDatagramSocket)? あるいは、スケジュールされた実行間で DatagramSocket インスタンスを保持することは理にかなっていますか、それとも毎回新しいものを作成できますか?

私が開発するソフトウェアが大きく複雑になり、そのさまざまな部分で独自の方法でエグゼキュータが使用されることは、私の実践では珍しいことではありません。パフォーマンスの観点からは、各部分で異なるスレッドプール構成を使用することをお勧めします。ただし、保守性とコードの使いやすさの点から、スレッド、同時実行性、およびCPU使用率に関連するすべてのものが、一元化された場所に保持および構成されていると、より望ましいでしょう。

同時実行またはスケジューリングが必要な各クラスに独自のスレッドプールを作成させることは、ライフサイクルとスレッドの総数を制御することが難しいため、OKではありません。

ある種のExecutorManagerを作成し、アプリケーションの周りに1つのスレッドプールを渡すこともOKではありません。タスクのタイプと送信率によっては、作業キューとスレッドプールサイズの不適切に構成された組み合わせがパフォーマンスに悪影響を与える可能性があるためです。

したがって、問題は、この問題に対処するいくつかの一般的なアプローチがありますか？

ネットワーク経由でデータをフェッチするための単一スレッドのエグゼキュータ サービスがあります。

ユーザーが検索ボックスに入力しているときに、考えられるネットワーク タスクをキューに入れています。私が望むのは、以前のすべてのリクエストをキャンセルし、エンキューして最新のリクエストのみをすぐに実行することです。

私の現在のアプローチは、execute() および submit() メソッドをオーバーライドし、super を呼び出す前にキューをクリアすることです。

これについて何か考えはありますか？

MyFutureTask extends FutureTask<Void>メソッドでコードを実行するカスタムクラスがありdone()ます。

私はそれに呼び出す ExecutorService を使用submit(new MyFutureTask())します。

Future<?>これで、submit を呼び出した後に返される への参照を保持できますが、cancel を呼び出すと、isCancelled()メソッドは決して true を返しません。

Future<?>返されるオブジェクトを無視して、代わりにそれを操作しMyFutureTaskて呼び出す必要がありcancel(true)ますか?

Future<?>では、オブジェクトの使用は何ですか？

編集: Java の Future と FutureTask の違いは何ですか? このスレッドから私は違いを理解しています。

デフォルトのキャンセル動作に加えて、進行中のネットワーク呼び出しを停止したいので、FutureTask を使用するルートは正しいと思います。誰かが確認できますか？

スレッドプールを使用する理由について、例を挙げて説明できる人はいますか。

理論的には、エグゼキューターでのスレッドプールの使用について知っています。

私は多くのチュートリアルを経験しましたが、スレッドプールを使用する必要がある理由についての実際的な例は得られませんでした。

スケーラビリティとパフォーマンスの面で。

誰かがパフォーマンスとスケーラビリティについて例を挙げて説明してくれませんか?