Thread Pool Exceptions: Destroy or Reuse? and Pre‑starting Core Threads

Two common Java thread‑pool interview questions are presented: (1) after a thread throws an exception, should the thread be destroyed or reused, and (2) can threads be created before submitting tasks.

Exception handling: When a task is submitted with execute() and an uncaught exception occurs, the thread terminates; the pool detects the termination and creates a new thread to keep the configured pool size unchanged. In contrast, when a task is submitted with submit() , any exception is wrapped inside the returned Future . Calling Future.get() throws an ExecutionException , but the worker thread itself remains alive and can process subsequent tasks.

In short, execute() leads to thread termination and replacement on uncaught exceptions, while submit() encapsulates the exception, allowing the thread to be reused.

This design lets submit() provide flexible error‑handling for callers who need to process results, whereas execute() suits fire‑and‑forget scenarios where the result is irrelevant.

Pre‑starting core threads: Yes, ThreadPoolExecutor offers two methods to create core threads before any tasks are submitted, achieving pool warm‑up. prestartCoreThread() starts a single core thread if the current number of core threads is below the configured core size, returning true on success. prestartAllCoreThreads() starts all core threads and returns the number of threads that were successfully started.