が、それはいつものExecutorServiceのようForkJoinPoolを使用することが有益である

Question

のは、私はそのようなコードがあるとしましょう：代わりに、コンストラクタでThreadPoolExecutorを渡すので、私はForkJoinPoolを使用する場合

class Foo { 
    private final ExecutorService executor; 

    public Foo(ExecutorService executor) { 
     this.executor = executor; 
    } 

    public void doSomething() { 
     executor.execute(() -> {/* Do important task */}); 
    } 
} 

は、私はより良いパフォーマンスを得ることができます。はいの場合は、ThreadPoolExecutorの代わりにどのような状況でも使用することをお勧めします。

アップデート1

私の質問はExecutorService APIを通じてForkJoinPoolの使用についてですとForkJoinPool特定のAPIを使用して再帰的なタスク分割を想定しません。

Answer 1

あなたがnewWorkStealingPool

public static ExecutorService newWorkStealingPool() 

を使用している場合、そのターゲット並列度として利用可能なすべてのプロセッサを使用してワークスチールスレッドプールを作成し、有効になります。

あなたは、このドキュメントpageから利点を見つけることができます。

ForkJoinPool非ForkJoinTaskクライアントだけでなく、管理および監視業務からの提出のためのエントリポイントを提供します。すべてのスレッドをプール試みで見つけると他によってプールに提出及び/又は作成されたタスクを実行する：ForkJoinPool

は主ワークスチールを用いによってExecutorServiceのの他の種類とは異なりますアクティブなタスク（存在しない場合、最終的には作業待ちをブロックする）。

多くの小さなタスクは、外部クライアントからプールに提出されたとき、ほとんどのタスクは、他のサブタスクを（ほとんどのForkJoinTasksがそうであるように）産卵、だけでなく、ときに効率的な処理を可能にします。特に、asyncModeをコンストラクタでtrueに設定すると、ForkJoinPoolsは、結合されていないイベントスタイルのタスクでの使用に適している可能性があります。

Answer 2

はい、再帰的なノンブロッキングタスクがある場合は可能です。

Hereは最近のジョーカーカンファレンスのCay S. Horstmannの素晴らしい説明です。