Qual é a vantagem de um ThreadPoolExecutor Java-5 sobre um ForkJoinPool Java-7?

@Java 5 introduziu o suporte à execução de tarefas assíncronas por um pool de threads na forma da estrutura Executor, cujo coração é o pool de threads implementado por java.util.concurrent.ThreadPoolExecutor. O Java 7 adicionou um conjunto de encadeamentos alternativo na forma de java.util.concurrent.ForkJoinPool.

Observando a respectiva API, o ForkJoinPool fornece um superconjunto da funcionalidade do ThreadPoolExecutor em cenários padrão (embora, estritamente falando, o ThreadPoolExecutor ofereça mais oportunidades de ajuste do que o ForkJoinPool). Adicionando a isso a observação de que as tarefas de junção / junção parecem ser mais rápidas (possivelmente devido ao agendador de roubo de trabalho), precisam definitivamente de menos encadeamentos (devido à operação de junção sem bloqueio), pode-se ter a impressão de que o ThreadPoolExecutor foi substituído por ForkJoinPool.

Mas isso é realmente correto? Todo o material que li parece resumir uma distinção bastante vaga entre os dois tipos de pools de threads:

@ForkJoinPool é para muitas tarefas dependentes, geradas por tarefas, curtas, quase nunca bloqueando (ou seja, intensivas em computação) @ThreadPoolExecutor é para poucas tarefas independentes, independentes e geradas externamente, longas e que às vezes bloqueiam

Essa distinção é correta? Podemos dizer algo mais específico sobre isso?

questionAnswers(8)

yourAnswerToTheQuestion