3

現在、ビジネス上の問題を解決するために、さまざまな同時実行ソリューションを評価しています。ユースケースは、「恥ずかしい並列」アルゴリズムに似ています。

基本的に、1 つのユーザー リクエストに対して、レスポンスを計算する前に、複数の異なるデータ ソースからデータを取得する必要があります。現在、3 つの DAO 呼び出しはすべてシリアルに行われますが、相互依存関係がないため、並行して行うことができます。

これまでに実装されたソリューション:

  • Callable と Future を使用した java.util.concurrent.ExecutorService
  • org.springframework.scheduling.annotation.Async を使用して、Spring がスレッド プールを管理できるようにしますが、aysnchronous 呼び出しを行うこともできます。
  • 比較的単純なユースケースの Akka (オーバーキルと見なされる)

私が評価したかった最後のフレームワークは Java ForkJoin フレームワークでした。RecursiveTasks の使用例を複数見ることができますが、私のユース ケースは本質的に再帰的ではないため、モデルに適合しません。タスクが十分に小さい場合は、タスクを分割して同じものを再帰的に呼び出します。メソッド (つまり、分割統治)

私のユースケースは、タスクを 3 つのタスクに分割することです。3 つすべてをフォークして、再度参加します。これは ForkJoin 実装の有効な使用例ですか? または、一般的な ExecutorService 実装に固執する必要があります。

4

4 に答える 4

0

Definitelly not ForkJoinPool.

It's stated in javadoc that you have to avoid pushing any tasks that could cause any IO, except in some cases output to async streams.

Tasks should also not perform blocking IO... 100 to 10000 basic computational steps.

So it should probably better to use either container concurrency management or ExecutorServices with Futures.

于 2012-07-05T18:40:49.390 に答える
0

すでに述べたように、ユースケースには再帰は含まれていません。3 つのタスクを並行して実行し、それらが完了するのを待つだけであればExecutorService.invokeAll、最も簡単な解決策のように思えます。

于 2012-07-04T09:54:16.087 に答える
0

3 つの並列タスクのみの場合、最も簡単な方法は 3 つのスレッドを実行し、thread.join() で終了するまで待機することです。

于 2012-07-04T10:03:13.970 に答える
0

ExecutorService の利点は、スレッド プールを保持できることです。したがって、あなたの場合、複数の連続した呼び出しの場合、スレッドが再利用されます。これにより、OS が停止して新しいスレッドを作成するサイクルが節約されます。

ForkJoinPool のさらなる利点は、作業を「盗む」ことができることです。私の知る限り、それが意味することは、タスクを終了した1つのスレッドが、ExecutorServiceよりもはるかに少ないオーバーヘッドですぐに別のタスクを実行できるということです。

あなたの場合、 ForkJoinPool の利点は最小限に見えます。

于 2012-07-04T10:22:11.933 に答える