送信者のリストを持っているので、個別に並行してメールを送信する必要があります。現在、リストを繰り返して本文を作成し（人によって異なるため）、送信しています。これにフォークジョインを使用するにはどうすればよいですか。recusiveActionを使用してみましたが、再帰的なタスクにのみ使用できると思います。

インターネットで利用可能なすべての例は、RecursiveActionを使用して実装されています。これを実装できるクラスは他にありますか？

最初に大きなタスクを単純に N 個のサブタスクに分割し、それらを ( Executorsから) キャッシュされたスレッド プールに送信し、各タスクが完了するのを待つだけでなく、新しいfork/join フレームワークを使用する利点は何ですか? fork/join 抽象化を使用することで、問題が単純化されたり、何年も前から解決策がより効率的になったりすることがわかりません。

たとえば、チュートリアルの例の並列化されたぼかしアルゴリズムは、次のように実装できます。

最初に分割し、タスクをスレッド プールに送信します。

タスクはスレッド プールのキューに移動し、ワーカー スレッドが使用可能になるとそこから実行されます。分割が十分に細分化されており (特に最後のタスクを待機する必要がないように)、スレッド プールに十分な (少なくとも N 個のプロセッサ) スレッドがある限り、計算全体が完了するまで、すべてのプロセッサがフル スピードで動作します。

何か不足していますか？fork/join フレームワークを使用することの付加価値は何ですか?

jdk7 が fork-and-join をサポートしていることは理解していますが、JDK7.0 にアップグレードせずに JDK6 で fork-and-join を使用できますか?

私のアプリケーションでは、多くのネットワーク io バインド タスクを実行し、場合によっては 1 つの io バインド タスクを実行して、より小さな io バインド タスクに分割して問題を解決する必要があります。これらのタスクは現在、Java の標準スレッドプール メカニズムを使用して実行されています。フォーク アンド ジョイン フレームワークに移行できるかどうか疑問に思っています。しかし問題は、forkanandjoin フレームワークは通常、io バウンド操作または CPU バウンドの解決に使用されているのでしょうか? それらは主にCPUバウンド操作用であると思います.fork-and-joinフレームワークはワークスティーリング技術を利用してマルチコアプロセッサを利用しますが、IOバウンドタスクに使用すると悪影響はありますか?

スレッドに関しては常に少し苦手で、Steven Toub の Parallel Computing の本を読んでいるだけです。

39 ページには、以下のフォーク/ジョイン パターンの例があります。

上記の例のアプローチ 3 の場合、すべての結果が公式に値を持っているかどうかを明確にするために、

「結果を返す」？

または、スレッドが完了したかどうかに応じて、それらの一部のみが値を持ちますか?

あなたが呼び出すときのアプローチ4についても同様ToArray()

もっと簡単な問題を解決する必要があります。1000 個のランダムな X 値と 1000 個のランダムな Y 値の並列合計を解く必要があります。JavaのParallel ForkJoinフレームワークを使用しています。単一の計算方法を使用すると、まったく異なるルートで X 値と Y 値の合計を計算することはできません。

さらに、X * Y の合計を計算する必要があります。つまり、Σxiyi ですが、1 つのスレッドがトラバースする X 値は別のタスクを割り当て、Y は別のタスクとしてスレッドプールに挿入されます。では、X と Y の両方の値を同時に乗算するにはどうすればよいでしょうか。つまり、X * Y ==> (X = 100, Y = 150) のようになります。最初のスレッドは X で動作し、2 番目のスレッドは Y で動作します。

コード：

public class RegressionLineForkJoin {

}

java 7util.concurrentのForkJoinAPIを活用する計画はありますか、またはAkkaで同様のAPIを公開する計画はありますか？

ForkJoinPoolタスク (RecursiveActionまたは) を送信するために使用しているときに、例外 (キャッチされない) を処理するより良い方法は何RecursiveTaskですか?

ForkJoinPool は、Thread.UncaughtExceptionHandlerWorkerThread が突然終了した場合 (これはとにかく私たちの制御下にはありません)、例外を処理するために を受け入れますが、このハンドラーは がForkJoinTask例外をスローする場合には使用されません。私は実装で標準submit/invokeAll方法を使用しています。

これが私のシナリオです：

サードパーティのシステムからデータを読み取る無限ループでスレッドを実行しています。このスレッドでは、タスクをForkJoinPool

私は RecursiveAction を使用しており、いくつかのシナリオでは RecursiveTask を使用しています。これらのタスクはメソッドを使用して FJPool に送信されsubmit()ます。UncaughtExceptionHandlerタスクがチェックされていない/キャッチされていない例外をスローした場合に、例外を処理し、必要に応じてタスクを再送信できるような一般的な例外ハンドラーが必要です。例外を処理することで、タスクの 1 つまたは一部が例外をスローした場合に、キューに入れられたタスクが取り消されないようにすることもできます。

invokeAll()メソッドは一連の ForkJoinTasks を返しますが、これらのタスクは再帰ブロックにあります (各タスクはcompute()メソッドを呼び出し、さらに分割される可能性があります [仮想シナリオ] )

3 ～ 4 個のタスクが失敗すると、キュー送信ユニット全体が破棄されることに気付きました。現在、私はtry/catch個人的に好きではないプロセスタスクを回避しています。より一般的なものを探しています。

1. また、失敗したタスクのすべてのリストを知りたいので、それらを再送信できます
2. タスクが例外をスローすると、スレッドはプールから追い出されますか?
3. FutureTask でメソッドを呼び出すget()と、タスクが完了するまで待機するため、フローがシーケンシャルになる可能性が高くなります。
4. Task が失敗した場合のみ、Task のステータスを知りたい。いつ完了するかは気にしません (明らかに 1 時間後に待ちたくありません)。

上記のシナリオで例外を処理する方法はありますか?

分割統治戦略を介して階乗関数を実装しようとしています。ForkJoin フレームワークを使用して各再帰タスクをフォークし、計算を高速化しました。しかし、思ったほどスピードアップしていないことがわかりました。ForkJoin を使用しないと 50000 の階乗を計算すると 28 秒かかりましたが、ForkJoin を使用した場合は 25 秒かかりました。これは forkjoin のないコードです:

これは forkJoin を使用したコードです。

どこが間違っていますか？これは、Fork/Join の結果ではないと思います。助けてください！

Java7のForkJoinPoolクラスには、次のような実装に関するコメントがあります。

メソッド signalWork() と scan() は主なボトルネックであるため、特に大幅にマイクロ最適化/マングルされています。多くのインライン割り当て("while ((local = field) != 0)" の形式) があり、これらは通常、必要な読み取り順序を確保する最も簡単な方法です (これは重要な場合もあります)。

私の質問は次のとおりです:インライン割り当ては読み取り順序にどのように役立ちますか(私はJavaメモリモデルに精通しており、インライン割り当てがここでどのように役立つかわかりません)?