スレッドプールのアナロジー
リクエストごとに新しいスレッドを生成するアプリケーションに取り組んでいます。マシン上で一度にアクティブになるスレッドの数が数百に達することもあります。これがあらゆる種類の問題を引き起こしていると思われます。代わりにスレッドプールを使用して実験し、これによって作業スループットが向上するかどうかを確認したいと思います。しかし、最初に、私は私に時間を与えることになる力を納得させなければなりません。
私の議論の一部として、力ずくの「launchxthreads」メソッドをスレッドプールのテクニックと比較する良い例えが役立つと思います。これに対する教科書のアナロジーはありますか？
教科書の例えではありません。
アプリケーションのスレッドプールはコミュニティのリサイクルのようなものです。
喉が渇いたときはいつでも、すべての新しい材料で作られた新しいボトル入り飲料水を購入することができます。それは簡単で、私たちにとっては比較的安価であり、メーカーにとっては非常に有益です。残念ながら、拡張性はありません。
同様に、ゼロから毎回新しいスレッドを作成することは無駄であり（遅い可能性があります）、セーフガードがありません。スレッドが多すぎると、ペットボトルが多すぎて自然の生息地を圧倒して毒殺するのと同じように、実行環境のリソースを使い果たす可能性があります。
スレッドプール内のスレッドは、正当な理由から「ワーカースレッド」と呼ばれることがよくあります。彼らは会社の何人かの労働者のようで、いくつかの「タスク」に取り組む準備ができており、それぞれが仕事にいくらかの作業スペースを取り、それぞれが処理するタスクのキューを持っています。
タスクを実行するためだけにスレッドを起動することは、このタスクのために特別に誰かを雇うためのリソースを見つけ、彼女にそれを実行させ、そして彼女を解雇するようなものです。
明らかに、タスクが非常に長く、まれで、具体的である場合、これに問題はないかもしれませんが、これが頻繁に発生するほど、コストが高くなります。
この場合、ワーカーのタスクキューの一番上にタスクを配置するだけで十分です。作業を開始するのに時間がかかりすぎると、タスクがなくなる別のワーカーがキューからタスクを盗む可能性があります。しばらくの間利用可能なワーカーがない場合は、十分なワーカーがないか、利用可能なリソースで迅速に実行できないことを意味します。特に、スレッドプールのように、誰もが他の人の足元を歩くことなく使用できるワーカーの最大数がすでにある場合は、場所を大きくする（ハードウェアを改善する）か、作業負荷を減らす以外に何もできません。 。
このアナロジーは、中断と通信のコストを簡単に説明することもできます。
オレオクッキーのパッケージ全体を食べることを想像してみてください。おいしいクリーミーなセンターが欲しいたびにドライチョコレートウエハースを食べる必要がなければ、この体験はもっと楽しいでしょう。スレッドプールを使用することは、それらすべてのCookieの中心を1組のウェーハの間に積み重ねるようなものです。
コードのプロファイルを作成し、マシンがスレッドの開始と停止に費やす時間（ウェーハを食べる）とクリーミーなセンターに費やす時間（実際にはリクエストを処理する）を示すと、そのアナロジーははるかに説得力があります。
実装が必要な場合は、 libdispatch を参照してください。