スレッドプール

なぜスレッドプールが要るのか

スレッドは便利ですが、1つ作るたびにコストがかかります。OS にスタック領域を確保させ、カーネル内に管理情報を登録し、終わったら片付ける——この生成・破棄は無視できない重さです。

リクエストが来るたびに新しいスレッドを作って捨てる素朴な方式には、2つの問題があります。

• 生成・破棄のコスト が、1件ごとに毎回積み上がる
• 同時に大量の要求が来ると スレッドが無制限に増え、メモリや CPU を食い尽くす

スレッドプールは、あらかじめ決まった数のスレッドを作っておき、それらを使い回す ことでこの両方を解決します。タスクが来たら空いているスレッドに渡し、終わったらスレッドは破棄せず次のタスクを待ちます。

仕組み：ワーカーとタスクキュー

スレッドプールは、ワーカースレッド の集まりと タスクキュー で構成されます。

[タスク投入] → ┌─────────────┐
               │  タスクキュー  │ ← 順番待ちの仕事を貯める
               └─────┬───────┘
                     │ 取り出す
        ┌────────────┼────────────┐
     ワーカー1      ワーカー2      ワーカー3   ← 使い回されるスレッド

動きはシンプルです。

• 仕事（タスク）は キューに積まれる
• 各ワーカーは、空いたら キューから1つ取り出して実行 する
• 実行が終わったら破棄されず、また次をキューから取りに行く
• キューが空なら、ワーカーは 待機（ブロック） して CPU を消費しない

ワーカー数を超える数のタスクが同時に来ても、あふれた分はキューで待つだけです。つまりスレッドプールは、同時実行数の上限 を自然に与えてくれます。

サイズの決め方

プールのサイズ（ワーカー数）は性能を大きく左右します。少なすぎれば仕事が詰まり、多すぎれば切り替え（コンテキストスイッチ）の負荷や資源の浪費を招きます。目安は処理の性質で変わります。

処理の性質	例	サイズの目安
CPU バウンド	画像変換・暗号計算・圧縮	コア数と同程度（N または N+1）
I/O バウンド	DB 問い合わせ・外部 API・ファイル	コア数より多め（待ち時間を埋める）

理由は単純です。CPU バウンド な処理はスレッドが常に計算で CPU を使うため、コア数を超えてスレッドを増やしても並列には走れず、切り替え損だけが増えます。一方 I/O バウンド な処理は応答待ちで CPU を遊ばせるので、その間に別スレッドを走らせられるよう多めに用意すると効率が上がります。

デッドロックに注意

プール内のタスクが、同じプール上の別タスクの完了を待つ と危険です。全ワーカーが「待ち」で埋まり、待たれている側はキューで順番が回ってこない——という膠着（デッドロック）に陥ることがあります。

避けるには、依存関係のあるタスクは 別のプールに分ける、あるいは互いに待たない設計にします。

まとめ

• スレッドプールは、事前に用意したスレッドを 使い回して タスクを処理する仕組み。
• 生成・破棄のコスト を避け、タスクキュー で順番待ちさせ、同時実行数の上限 を与える。
• サイズは CPU バウンドならコア数前後、I/O バウンドなら多め が目安。
• キューの上限とプール内の待ち合わせには注意する。

スレッドそのものは プロセスとスレッド、切り替えの中身は コンテキストスイッチ も合わせてどうぞ。