Problems With Nested CompletableFuture in Java

CompletableFuture was introduced in Java 8 for executing things in an asynchronous way. This can help to prevent the main thread from waiting to complete the execution of a particular block of code that is not needed for the main thread execution. CompletableFuture uses threads from ForkJoinPool.commonPool() for its execution, if there is no custom executor passed as an argument.

If the parallelism is less than two, then CompletableFuture creates a new thread for each asynchronous task submitted. ForkJoinPool.commonPool() will have the number of threads based on the java.util.concurrent.ForkJoinPool.common.parallelism property set.

java.util.concurrent.ForkJoinPool.common.parallelism is set to default with a value equal to the number of cores available in the system where the JVM is running. For example, if we are running the JVM on a 4 CPU machine, then the value of java.util.concurrent.ForkJoinPool.common.parallelism will be 4, and ForkJoinPool.commonPool() will also have the 4 threads created. We can increase the value of this java.util.concurrent.ForkJoinPool.common.parallelism by passing this parameter at startup via —Djava.util.concurrent.ForkJoinPool.common.parallelism=<count>. This property can’t be modified at runtime and must be set during the JVM startup as a command line argument.

Nested CompletableFuture in the code will create problems when the application gets a high volume of requests to execute it. For example, in the code, there is one CompletableFuture1, which in turn contains another CompletableFuture2. Both the CompletableFuture 1 and 2 require separate threads to be allocated to execute the task assigned. In this case, it requires two threads from them ForkJoinPool.commonPool() to execute the tasks. It will run successfully if there are no other requests in the application while this code is executed, and the parallelism is 4. It will get the threads available in ForkJoinPool.commonPool() as they are available, and the tasks will be executed successfully. If there are more requests coming to the application, then more threads are needed to execute these nested CompletableFuture tasks. The ForkJoinPool.commonPool() may run out of threads, and the application may get into a hung kind of situation without being able to process the requests.

For example, if we are running the application on a machine with a CPU count of 4, then there will be 4 threads in the ForkJoinPool.commonPool() by default. If the application receives 4 requests simultaneously, then it will enter CompletableFuture1, and it will try to execute CompletableFuture2, where it will wait for the threads as all the ForkJoinPool.commonPool() threads were already busy executing CompletableFuture1. This will make the application go into a kind of hung state, and it won’t proceed with processing the current 4 requests as well as the requests that are going to reach this nested CompletableFuture code. It might also halt the other requests that use CompletableFuture inside it from processing. 

To resolve this situation, the java.util.concurrent.ForkJoinPool.common.parallelism parameter can be increased to a higher value as a short-term workaround. That may resolve the situation mentioned above in the blog, but it will occur if there is a number of simultaneous requests that are equal to or more than the java.util.concurrent.ForkJoinPool.common.parallelism parameter value set. Also, sometimes, the issue may not occur even if there is a variation of milliseconds while receiving the simultaneous requests or if the CompletableFuture code block is getting executed in a faster manner. As a permanent fix to this situation, it is always better to avoid having nested asynchronous tasks like this as it has the overhead of using more threads as well as a possibility of getting into a hung situation.