私は、トピックの検索リクエストを受け取り、New York Times API への API 呼び出しを行ってトピックに関連する記事を取得し、次に Twitter API への API 呼び出しを行って記事に言及しているツイートを取得し、最終的に結果を処理して返すプログラムに取り組んでいます。それを戻します。
これをマルチスレッド化する必要があります。固定サイズのスレッド プールで ExecutorService を使用することを考えました。そのため、すべての受信検索リクエストは個別のスレッドによって処理されます。また、Callable インターフェイスを使用してタスクを送信します。Callable を実装するクラスは、API 処理 (API 要求/応答の作成と受信) を行います。最後に、結果が Future によってフェッチされ、出力として表示されます。これは、着信リクエストごとに発生します。
これは理にかなっていますか？または、これを行うより良い方法はありますか？
編集:コマンドラインインターフェイスからデータを受け入れるローカルマシンでこれを実行しています。
これが Web アプリケーションの場合、デフォルトでマルチスレッド化されています。そうでない場合でも、サーブレットコンテナーにデプロイできれば、有益です。スレッド プールは、基盤となるコンテナー (Tomcat など) によって提供されます。各リクエストは、個別のスレッドによって処理されます。
気にする唯一のこと：
synchronizedThreadLocalしますワークフローを正しくすることに焦点を当て、ボトルネックがどこにあるかをプロファイリングしてから、並行性（スレッド化！=並行性または非同期実行）が役立つ可能性がある場所を確認しようとします。CPU、ネットワーク、またはディスクI / Oを複数の実行スレッドで飽和させても、処理が速くなることはなく、特にハイパースレッドのIntel CPUでは、通常、パフォーマンスが低下します。
次に、マルチスレッドにする前に、非ブロッキングで非同期にすることについてもっと心配します。タスクのブロック（シリアル化）は、スレッドを使用して物事を並行させる試みの利点を完全に無効にします。
マルチスレッドは、タスクがワークフローで引き続きシリアル化されている場合に、魔法のように高速または効率的に実行されることを意味するものではありません。逆に、メッセージパッシングや非同期のものが手元にない場合は、処理速度が低下し、効率が低下する可能性があります。
また、これを最上位のCore i7ラップトップで実行している場合は、4つの実際のスレッド（4つのハイパースレッドは通常CPUバウンドアプリで事態を悪化させます）と、物事を起こそうとするオーバーヘッドを取得するだけです。シリアルオーダーしてから元に戻すと、実際の利益や多くの複雑さが得られない場合があります。より多くのコアサーバーでは、これは当てはまらない可能性があります。ラップトップでは、スレッド化はあまり効果がありません。
「並行性を実行するのは簡単ですが、並行性を正しく実行するのは非常に困難です！」-合気道先生の言い換え