スレッドプールの仕組み - なぜスレッドを使い回すのか？

ダメではないけど、めちゃくちゃ非効率なんだよ。スレッドを1つ作るたびに、OSはスタック領域のメモリ確保（だいたい512KB〜1MB）、カーネルへの登録、コンテキストスイッチの準備をしないといけない。処理が終わったら今度はその逆の破棄処理が走る。リクエストのたびにこれをやってたら、本来の処理より準備と片付けのほうがコストが高くなるんだ。

まさにそのイメージだね！スレッドプールは、あらかじめ何個かのスレッド（ワーカースレッド）を作っておいて、タスクキューに入ってきた仕事を空いてるスレッドが順番に取り出して処理する仕組みだよ。処理が終わったらスレッドは破棄されずにプールに戻って、次の仕事を待つ。弁当箱を洗って再利用するようなものだね。

スレッドプールには主に4つのパラメータがあるよ。まず「コアプールサイズ」は常に維持する最低スレッド数。次に「最大プールサイズ」は負荷が高いときに増やせる上限。「キュー容量」はスレッドが全部使用中のときにタスクを待機させる行列の長さ。そして「キープアライブ時間」はコアサイズを超えたスレッドが暇になってから消えるまでの時間だよ。

よく使うのは3つだね。newFixedThreadPool は固定数のスレッドで動くから、負荷が予測しやすいバッチ処理向き。newCachedThreadPool は必要に応じてスレッドを増減するから、短時間で終わるタスクが大量にくる場面に向いてる。ScheduledThreadPool は「5秒後に実行」「10秒ごとに繰り返し」みたいな定期実行ができるよ。用途に合わせて選ぶのが大事だね。

仕事を盗むんだよ（笑）。通常のスレッドプールは1つの共有キューからタスクを取り出すけど、ForkJoinPool ではスレッドごとに専用のデック（両端キュー）を持ってるんだ。自分のキューが空になった暇なスレッドが、忙しいスレッドのキューの反対側からタスクを『盗んで』処理する。これでスレッド間の負荷が自動的に平準化されるんだよ。再帰的に分割できるタスク、たとえばソートや探索で特に効果を発揮するね。

もちろん！たとえばTomcatにはリクエストを処理するワーカースレッドのプールがあって、デフォルトで最大200スレッドが設定されてる。HTTPリクエストが来ると空いてるスレッドに割り当てられて、レスポンスを返し終わったらプールに戻る。Nginxはちょっと違って、少数のワーカープロセスがイベント駆動で数千接続を同時に捌く設計だよ。アーキテクチャは違うけど、『リソースを事前確保して使い回す』という発想は同じだね。

あるある！一番怖いのが『スレッドプール枯渇』だね。たとえば全スレッドがデータベースのレスポンス待ちでブロックされると、新しいリクエストはキューに溜まり続けて、最終的にタイムアウトの嵐になる。もう一つは『プール内デッドロック』。タスクAがタスクBの結果を待っていて、タスクBもプール内のスレッドで動いているのにタスクAがスレッドを占有して離さない…みたいな状況だよ。対策としては、I/O待ちが多い処理と計算処理でプールを分離するのが基本だね。

鋭い質問だね！Project Loom で導入された仮想スレッドは、OSスレッドではなくJVM内部の軽量スレッドで、1つあたりのコストが数百バイト程度。100万個作っても問題ないから、『リクエストごとに1仮想スレッドを割り当てる』スタイルが現実的になったんだ。I/Oでブロックしても、裏でOSスレッドが別の仮想スレッドに切り替わるから枯渇しない。ただし、CPU集約型の処理ではOSスレッドベースのプールが依然として有効だから、完全に不要になるわけではないよ。

実はそれぞれ面白いアプローチを取ってるんだ。Goのgoroutineは M:N スレッディングモデルといって、M個のgoroutine（軽量スレッド）をN個のOSスレッドにマッピングする。ランタイムがスケジューリングするから、開発者はスレッドプールを意識しなくていい。Node.jsはシングルスレッドのイベントループでI/Oを非同期処理しつつ、ファイル操作やDNS解決など一部のブロッキング処理はlibuvの内部スレッドプール（デフォルト4スレッド）に委譲してるんだよ。『スレッドを使い回してコストを下げる』という本質は、言語やランタイムが変わっても共通の設計思想だね。

そうだよ。スレッドプールは『高コストなリソースを事前確保して使い回す』というプーリングパターンの代表例で、コネクションプールやメモリプールにも同じ発想が使われてる。仮想スレッドやgoroutineが普及しても、裏側ではOSスレッドのプールが動いてるし、この仕組みを理解しておくとパフォーマンス問題のトラブルシューティングで必ず役に立つよ。