Java's Fork/Join vs ExecutorService

2018-07-03 00:45:48

I just finished reading this post: What's the advantage of a Java-5 ThreadPoolExecutor over a Java-7 ForkJoinPool? and felt that the answer is not straight enough.

Can you explain in simple language and examples, what are the trade-offs between Java 7's Fork-Join framework and the older solutions?

I also read the Google's #1 hit on the topic Java Tip: When to use ForkJoinPool vs ExecutorService from javaworld.com but the article doesn't answer the title question when , it talks about api differences mostly ...

Fork-join allows you to easily execute divide and conquer jobs, which have to be implemented manualy if you want to execute it in ExecutorService. In practice ExecutorService is usualy used to process many independent requests (aka transaction) concurrently, and fork-join when you want to accelerate one coherent job.

Fork-join is particularly good for recursive problems, where a task involves running subtasks and then processing their results. (This is typically called "divide and conquer" ... but that doesn't reveal the essential characteristics.)

If you try to solve a recursive problem like this using conventional threading (eg via an ExecutorService) you end up with threads tied up waiting for other threads to deliver results to them.

On the other hand, if the problem doesn't have those characteristics, there is no real benefit from using fork-join.

Here's a "Java Tips" article that goes into more detail:

Java 8 provides one more API in Executors

static ExecutorService  newWorkStealingPool()

Creates a work-stealing thread pool using all available processors as its target parallelism level.

With addition of this API,Executors provides different types of ExecutorService options.

Depending on your requirement, you can chose one of them Or you can look out for ThreadPoolExecutor which provides better control on Bounded Task Queue Size, RejectedExecutionHandler mechanisms.

static ExecutorService newFixedThreadPool(int nThreads)

Creates a thread pool that reuses a fixed number of threads operating off a shared unbounded queue.

static ScheduledExecutorService newScheduledThreadPool(int corePoolSize)

Creates a thread pool that can schedule commands to run after a given delay, or to execute periodically.

static ExecutorService newCachedThreadPool(ThreadFactory threadFactory)

Creates a thread pool that creates new threads as needed, but will reuse previously constructed threads when they are available, and uses the provided ThreadFactory to create new threads when needed.

static ExecutorService newWorkStealingPool(int parallelism)

Creates a thread pool that maintains enough threads to support the given parallelism level, and may use multiple queues to reduce contention.

Each of these APIs are targeted to fulfil respective business needs of your application. Which one to use will depend on your use case requirement.

If you want to process all submitted tasks in order of arrival, just use newFixedThreadPool(1)

If you want to optimize performance of big computation of recursive tasks, use ForkJoinPool or newWorkStealingPool

If you want to execute some tasks periodically or at certain time in future, use newScheduledThreadPool

Have a look at one more nice article by PeterLawrey on ExecutorService use cases.