fork-join

As far as I had understood ForkJoinPool , that pool creates a fixed number of threads (default: number of cores) and will never create more threads (unless the application indicates a need for those by using managedBlock ). However, using ForkJoinPool.getPoolSize() I discovered that in a program that creates 30,000 tasks ( RecursiveAction ), the ForkJoinPool executing those tasks uses 700 threads on average (threads counted each time a task is created). The tasks don't do I/O, but pure computation; the only inter-task synchronization is calling ForkJoinTask.join() and accessing AtomicBoolean s

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 ... Jakub Kubrynski Fork-join allows you to easily execute divide and conquer jobs,

What are the benefits of using the new fork/join framework over just simply splitting the big task into N subtasks in the beginning, sending them to a cached thread pool (from Executors ) and waiting for each task to complete? I fail to see how using the fork/join abstraction simplifies the problem or makes the solution more efficient from what we've had for years now. For example, the parallelized blurring algorithm in the tutorial example could be implemented like this: public class Blur implements Runnable { private int[] mSource; private int mStart; private int mLength; private int[]