How do CF and parallelStream use ForkJoinPool?

• CF default – supplyAsync(), runAsync(), and all *Async() methods use commonPool() when no executor is specified.
• parallelStream default – stream parallel operations use commonPool() for splitting and processing.
• CF usage – does not use fork/join splitting; submits tasks as regular Runnables; work-stealing helps idle workers pick up queued tasks.
• parallelStream usage – uses true fork/join splitting via Spliterator.trySplit(); recursive task forking and result merging.
• Shared pool risk – blocking IO in CF tasks starves parallelStream; heavy parallelStream work delays CF callbacks.
• Isolation – pass dedicated executors to CF; submit parallelStream inside a custom ForkJoinPool.

How does CompletableFuture use ForkJoinPool?

CompletableFuture uses commonPool as a regular executor. It does not split tasks recursively. It just submits Runnable or Callable tasks. Work-stealing helps because idle workers pick up queued CF tasks from other workers' deques.

// All use commonPool by default:
CompletableFuture.supplyAsync(() -> compute());        // commonPool
CompletableFuture.runAsync(() -> process());            // commonPool
cf.thenApplyAsync(fn);                                  // commonPool

// Override with custom pool:
CompletableFuture.supplyAsync(() -> compute(), myPool); // custom
cf.thenApplyAsync(fn, myPool);                           // custom

How does parallelStream use ForkJoinPool?

parallelStream uses true fork/join splitting. The Spliterator splits the data source into chunks, each chunk becomes a ForkJoinTask, workers process chunks in parallel, and results are merged.

// Uses commonPool by default:
list.parallelStream().map(this::process).toList();  // commonPool

// Override with custom ForkJoinPool:
ForkJoinPool custom = new ForkJoinPool(8);
List<Result> results = custom.submit(() ->
    list.parallelStream().map(this::process).toList()
).join();
// Runs on custom pool, not commonPool

How do CF and parallelStream differ in their use of the pool?

| Feature | CompletableFuture | parallelStream |
|---|---|---|
| Task type | Regular Runnable/Callable | ForkJoinTask (recursive) |
| Splitting | No splitting | Spliterator.trySplit() |
| Work-stealing benefit | Idle workers pick up CFs | Idle workers steal data chunks |
| Data processing | Independent tasks | Splits and merges data |

Why is sharing commonPool a problem?

// Component A: blocking HTTP calls on commonPool via CF
for (int i = 0; i < 3; i++) {
    CompletableFuture.supplyAsync(() -> httpCall()); // blocks commonPool!
}

// Component B: report generation via parallelStream
report = accounts.parallelStream()  // STALLED! same pool!
    .map(this::generateStatement)
    .toList();

How do you isolate the pools?

// CF: use dedicated IO pool
ExecutorService ioPool = Executors.newFixedThreadPool(20);
CompletableFuture.supplyAsync(() -> httpCall(), ioPool);

// parallelStream: use custom ForkJoinPool
ForkJoinPool reportPool = new ForkJoinPool(8);
reportPool.submit(() -> accounts.parallelStream().map(...).toList()).join();

// commonPool: free for lightweight CPU work

How do you configure commonPool?

# System properties (set at JVM start)
-Djava.util.concurrent.ForkJoinPool.common.parallelism=16
-Djava.util.concurrent.ForkJoinPool.common.threadFactory=com.bank.CustomThreadFactory
-Djava.util.concurrent.ForkJoinPool.common.exceptionHandler=com.bank.CustomHandler

Prefer dedicated pools over changing global settings.

What are common mistakes?

// WRONG: blocking IO on commonPool via CF
CompletableFuture.supplyAsync(() -> jdbcQuery()); // blocks shared pool!

// WRONG: assuming parallelStream uses a separate pool
list.parallelStream().map(this::heavyIO); // ALSO on commonPool!

// CORRECT: isolate both
CompletableFuture.supplyAsync(() -> jdbcQuery(), ioPool);
customFJP.submit(() -> list.parallelStream().map(...)).join();

What are common interview follow-up questions?

• Does CompletableFuture use fork/join splitting? No, it uses the pool as a regular executor.
• Can you change commonPool after JVM start? No, only via system properties at startup.
• What happens if you call parallelStream inside a CF callback? It runs on the same commonPool thread, potentially causing contention.