ExecutorService vs Casual Thread Spawner

by

While the question and the sample code do not correlate, I’ll try clarifying both.

The advantage of ExecutorService over haphazardly spawning threads is that it behaves predictably and avoids the overhead of thread creation, which is relatively big on the JVM (it needs to reserve memory for each thread, for example).

By predictability, I mean you can control the number of concurrent threads, and you know when and how they might get created and destroyed (so your JVM won’t blow up in case of sudden peaks, and threads won’t be left abandoned leaking memory). You can pass an ExecutorService instance around so that various parts of your program can submit tasks to it, while you still manage it in a single location, fully transparently. An ExecutorService can also be precisely scoped, and shut down when the scope is exited (via shutdown()).

A fixedThreadPool uses a pool of threads that won’t grow beyond what it is allocated.

A cachedThreadPool doesn’t have a max, but will reuse cached threads for a period of time. It’s mostly used in cases where many small tasks need to be executed on a separate thread.

A singleThreadExecutor is for async tasks executed serially.

There are others, like newScheduledThreadPool for periodically repeating tasks, newWorkStealingPool for tasks that can be forked into subtasks and a few others. Explore the Executors class for the details.

As of JVM 18, virtual threads are a thing, and these can be created cheaply, so they change the picture significantly. An ExecutorService that creates a new virtual thread each time can be obtained via newVirtualThreadPerTaskExecutor. The advantage of using this versus spawning threads manually is not performance-centric as much as structural in that it allows for scoping and other benefits explained above, and interoperability with existing APIs that expect an ExecutorService.

Now, on the topic of Runnable vs Callable, it is easy to see from your examples. Callables can return a value place-holder (Future) that will eventually be populated by an actual value in the future. Runnables can not return anything. Additionally, a Runnable also can’t throw exceptions, while a Callable can.

More Related Contents:

  1. How to wait for all threads to finish, using ExecutorService?
  2. ExecutorService, how to wait for all tasks to finish
  3. ExecutorService that interrupts tasks after a timeout
  4. Handling exceptions from Java ExecutorService tasks
  5. How to properly shutdown java ExecutorService
  6. Executors.newCachedThreadPool() versus Executors.newFixedThreadPool()
  7. Choose between ExecutorService’s submit and ExecutorService’s execute
  8. How to properly use Java Executor?
  9. What are the advantages of using an ExecutorService?
  10. Java’s Fork/Join vs ExecutorService – when to use which?
  11. Turning an ExecutorService to daemon in Java
  12. Is ExecutorService (specifically ThreadPoolExecutor) thread safe?
  13. Impossible to make a cached thread pool with a size limit?
  14. ThreadPoolExecutor Block When Queue Is Full?
  15. Java ExecutorService: awaitTermination of all recursively created tasks
  16. How to use invokeAll() to let all thread pool do their task?
  17. How to shutdown an ExecutorService?
  18. FixedThreadPool vs CachedThreadPool: the lesser of two evils
  19. ThreadPoolExecutor Block When its Queue Is Full?
  20. How to stop all runnable thread in java executor class?
  21. How to pause/resume all threads in an ExecutorService in Java?
  22. Java Executors: how can I stop submitted tasks?
  23. Removing all queued tasks of an ThreadPoolExecutor
  24. Shutdown ExecutorService gracefully in webapp?
  25. Dynamic Thread Pool
  26. ExecutorCompletionService? Why do need one if we have invokeAll?
  27. Why use a ReentrantLock if one can use synchronized(this)?
  28. ThreadLocal & Memory Leak
  29. Is having a single threadpool better design than multiple threadpools
  30. Is LinkedList thread-safe when I’m accessing it with offer and poll exclusively?

Leave a Comment