FixedThreadPool vs CachedThreadPool: the lesser of two evils

by

A CachedThreadPool seems appropriate for your situation as there are no negative consequence to using one for long running threads directly. The comment in the java doc about CachedThreadPools being suitable for short tasks merely suggest that they are particularly appropriate for such cases, not that they cannot be used for long running tasks.

The main concern with a CachedThreadPool is that it will create up to Integer.MAX_VALUE number of threads as it will always spawn a new thread if an unused one does not exist in the cache. So if you have long running tasks it is then more likely that you could grow the number of concurrent threads more than you desire since this type of thread pool will not limit how many execute concurrently itself. This does not seem to be a problem for your use case as described, but it is something to be aware of.

To elaborate further on the difference between a CachedThreadPool and a FixedThreadPool, Executors.newCachedThreadPool and Executors.newFixedThreadPool are both backed by the same thread pool implementation (at least in the open JDK) via an instance of ThreadPoolExecutor, just with different parameters. The differences just being their thread minimum, maximum, thread kill time, and queue type.

public static ExecutorService newFixedThreadPool(int nThreads) {
     return new ThreadPoolExecutor(nThreads, nThreads,
                                   0L, TimeUnit.MILLISECONDS,
                                   new LinkedBlockingQueue<Runnable>());
 }

public static ExecutorService newCachedThreadPool() {
    return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                 60L, TimeUnit.SECONDS,
                                 new SynchronousQueue<Runnable>());
}

A FixedThreadPool does have its advantages when you do in fact want to work with a fixed number of threads, since then you can submit any number of tasks to the executor service while knowing that the number of threads will be maintained at the level you specified. If you explicitly want to grow the number of threads, then this is not the appropriate choice.

This does however mean that the one issue that you may have with the CachedThreadPool is in regards to limiting the number of threads that are running concurrently. The CachedThreadPool will not limit them for you, so you may need to write your own code to ensure that you do not run too many threads, which you can do relatively easily by instantiating your own ThreadPoolExecutor with your desired behaviour characteristics. This really depends on the design of your application and how tasks are submitted to the executor service.

More Related Contents:

  1. ExecutorService, how to wait for all tasks to finish
  2. How to properly use Java Executor?
  3. Turning an ExecutorService to daemon in Java
  4. Removing all queued tasks of an ThreadPoolExecutor
  5. Dynamic Thread Pool
  6. ExecutorCompletionService? Why do need one if we have invokeAll?
  7. ExecutorService that interrupts tasks after a timeout
  8. Handling exceptions from Java ExecutorService tasks
  9. Synchronization vs Lock
  10. How to properly shutdown java ExecutorService
  11. Executors.newCachedThreadPool() versus Executors.newFixedThreadPool()
  12. Naming threads and thread-pools of ExecutorService
  13. CompletableFuture is not getting executed. If I use the ExecutorService pool it works as expected but not with the common ForkJoinPool
  14. What are the advantages of using an ExecutorService?
  15. Is ConcurrentHashMap totally safe?
  16. Java’s Fork/Join vs ExecutorService – when to use which?
  17. Is ExecutorService (specifically ThreadPoolExecutor) thread safe?
  18. Impossible to make a cached thread pool with a size limit?
  19. How are Threads allocated to handle Servlet request?
  20. ThreadPoolExecutor Block When Queue Is Full?
  21. Java ExecutorService: awaitTermination of all recursively created tasks
  22. How to use invokeAll() to let all thread pool do their task?
  23. What is adaptive spinning w.r.t lock acquisition?
  24. Run Java Threads sequentially
  25. WAITING at sun.misc.Unsafe.park(Native Method)
  26. How Threadpool re-use Threads and how it works
  27. Thread safe Hash Map?
  28. Propagating ThreadLocal to a new Thread fetched from a ExecutorService
  29. ExecutorService vs Casual Thread Spawner
  30. JAVAFX : why wait cursor needs a new thread?

Leave a Comment