回答:
スレッドプールは、事前にインスタンス化されたアイドルスレッドのグループであり、作業を行う準備ができています。これらは、少数の長いタスクではなく、多数の短いタスクを実行する必要がある場合に、各タスクの新しいスレッドをインスタンス化するよりも優先されます。これにより、スレッドを何度も作成するオーバーヘッドが発生しなくなります。
実装は環境によって異なりますが、簡単に言えば、次のものが必要です。
Taskとexecute()仕事をした後、返すメソッド。スレッドプールが作成されると、特定の数のスレッドをインスタンス化して使用可能にするか、実装のニーズに応じて必要に応じて新しいスレッドを作成します。
プールにaが渡されるTaskと、コンテナからスレッドを取得し（または、コンテナが空の場合はスレッドが利用可能になるのを待ちます）、aを渡してTask、バリアを満たします。これにより、アイドルスレッドは実行を再開し、指定されたexecute()メソッドを呼び出しTaskます。実行が完了すると、スレッドはプールに戻り、コンテナに入れて再利用し、そのバリアを満たし、サイクルが繰り返されるまでスリープ状態になります。
スレッドプールは、通常はキューに編成された管理スレッドのコレクションであり、タスクキュー内のタスクを実行します。
何かを非同期に実行する必要があるたびに新しいスレッドオブジェクトを作成すると、コストがかかります。スレッドプールでは、非同期で実行するタスクをタスクキューに追加するだけで、スレッドプールは、対応するタスクに利用可能なスレッドがあれば割り当てます。タスクが完了するとすぐに、現在使用可能なスレッドが別のタスクを要求します（残っていると仮定）。
スレッドプールを使用すると、実際に必要な数よりも多くのスレッドを作成または破壊することを回避できます。
まず、スレッドのキューとタスクのキューを持つクラスを作成します。次に、タスクをタスクキューに追加してそこから先に進むメソッドを実装します。もちろん、スレッドプールで許可される最大スレッド数を設定できるようにする必要もあります。
実生活の例;
施設があり、12人が働いています。この機能には3つのセクションがあります。キッチン、トイレ、セキュリティ。スレッドプールの手法を使用しない場合の仕組みです：12人全員が会議室に立っており、新しい顧客が施設から来てタスクを要求した場合、グループ内の人々を分けて仕事をするように送信します、会議室に戻ります。しかし、彼らが義務を果たす前に、準備段階があります。彼らは正しいユニフォームを着用し、特定のデバイスを装備し、そのセクションに歩いて行き、仕事を終えて戻ってくる必要があります。そのため、仕事を終えるたびに（スレッド終了）、会議室に戻ってユニフォームを脱ぎ、機器を取り出して次の仕事を待つ必要があります。これらは、スレッドコンテキストの作成、メモリ割り当て、およびOSによる追跡情報を参照します。
スレッドプーリングを使用している場合、早朝に、キッチンに6人、トイレに2人、セキュリティに4人を割り当てます。したがって、彼らは1日に1回だけ準備を行います。キッチンに顧客がいなくても、これらの4人は、今後のタスクのためにアイドリングします。キッチンが閉じる（アプリが終了する）まで会議室に戻る必要はありません。これら4人はキッチンアプリプールにあり、すぐにサービスを提供できます。しかし、キッチンが時々アイドルになることがあるので、彼らが一日中働いていると約束することはできません。トイレとセキュリティにも同じロジックが適用されます。
最初のシナリオでは、タスクのスレッドを無駄にしませんが、各タスクのすべてのスレッドを準備するにはかなりの時間がかかります。2番目の方法では、スレッドを事前に準備するため、すべてのタスクですべてのスレッドを使用することを保証できませんが、OSはほとんどの場合最適化を行うため、安全に信頼できます。