{"title":"ExecutorService","description":null,"content":"# Executor Service\n\nCreating a new thread for every task sounds simple. But it's a terrible idea at scale.\n\nThreads are expensive. Each one consumes memory for its stack (typically 1MB), and the OS spends CPU cycles managing them. Create thousands of threads, and your application grinds to a halt.\n\n**Executor Service** solves this by decoupling task submission from task execution. You submit tasks; a pool of reusable threads executes them. No more manual thread management.\n\nIn this article, we'll explore:\n\n- Why manual thread creation doesn't scale\n- How executor services work\n- Types of thread pools\n- Submitting tasks and getting results\n- Proper shutdown and lifecycle management\n- Thread pool sizing strategies\n- Common patterns and pitfalls\n\n---\n\nIf you're enjoying this newsletter and want to get even more value, consider becoming a **[paid subscriber](https://blog.algomaster.io/subscribe)**.\n\nAs a paid subscriber, you'll unlock all **premium articles** and gain full access to all **[premium courses](https://algomaster.io/newsletter/paid/resources)** on **[algomaster.io](https://algomaster.io)**.\n\n[Unlock Full Access](undefined)\n\n---\n\n## 1. The Problem with Manual Thread Creation\n\nConsider a web server handling requests:\n\n\n```java\n// Bad: Creating a new thread for each request\npublic void handleRequest(Request request) {\n new Thread(() -> process(request)).start();\n}\n```\n\n\nThis approach has serious problems:\n\n\n```mermaid\nflowchart TD\n subgraph Problems[\"Problems with Thread-per-Task\"]\n P1[\"High memory usage
(~1MB per thread stack)\"]\n P2[\"Thread creation overhead
(expensive OS operation)\"]\n P3[\"Context switching overhead
(too many threads)\"]\n P4[\"No limit on threads
(resource exhaustion)\"]\n P5[\"No task queuing
(work lost under load)\"]\n end\n\n Load[\"High Load
(1000s of requests)\"]\n Crash[\"System Crash
OutOfMemoryError\"]\n\n Load --> Problems\n Problems --> Crash\n\n style Problems fill:#ff8787,stroke:#000,color:#000\n style Load fill:#ffa94d,stroke:#000,color:#000\n style Crash fill:#9775fa,stroke:#000,color:#000\n```\n\n\nWith 10,000 concurrent requests, you'd create 10,000 threads consuming ~10GB just for thread stacks. The system would thrash from context switching and likely crash.\n\n---\n\n## 2. What is an Executor Service?\n\nAn **Executor Service** manages a pool of worker threads that execute submitted tasks. Instead of creating threads directly, you submit tasks to the executor, which handles all thread management.\n\n\n```mermaid\nflowchart LR\n subgraph Client[\"Client Code\"]\n T1[\"Task 1\"]\n T2[\"Task 2\"]\n T3[\"Task 3\"]\n T4[\"Task 4\"]\n end\n\n subgraph Executor[\"Executor Service\"]\n Queue[\"Task Queue\"]\n subgraph Pool[\"Thread Pool\"]\n W1[\"Worker 1\"]\n W2[\"Worker 2\"]\n W3[\"Worker 3\"]\n end\n end\n\n T1 --> Queue\n T2 --> Queue\n T3 --> Queue\n T4 --> Queue\n\n Queue --> W1\n Queue --> W2\n Queue --> W3\n\n style Executor fill:#00ceff,stroke:#000,color:#000\n style Queue fill:#ffa94d,stroke:#000,color:#000\n style Pool fill:#69db7c,stroke:#000,color:#000\n style Client fill:#9775fa,stroke:#000,color:#000\n```\n\n\n### Key Benefits\n\n\n| ##### Benefit | ##### Description |\n| --- | --- |\n| **Thread reuse** | Workers execute multiple tasks, avoiding creation overhead |\n| **Bounded resources** | Fixed number of threads prevents resource exhaustion |\n| **Task queuing** | Excess tasks wait in queue instead of being rejected |\n| **Decoupling** | Separate task submission from execution policy |\n| **Lifecycle management** | Proper startup and shutdown handling |\n\n\n### Basic Usage\n\n\n```java\n// Create an executor with 4 worker threads\nExecutorService executor = Executors.newFixedThreadPool(4);\n\n// Submit tasks\nexecutor.submit(() -> processRequest(request1));\nexecutor.submit(() -> processRequest(request2));\n\n// Shutdown when done\nexecutor.shutdown();\n```\n\n\n---\n\n## 3. How Executor Service Works\n\nAn executor service consists of three main components:\n\n\n```mermaid\nflowchart TB\n subgraph ExecutorService[\"Executor Service\"]\n subgraph TaskQueue[\"Task Queue\"]\n Q[\"Waiting Tasks
[T5, T6, T7, ...]\"]\n end\n\n subgraph ThreadPool[\"Thread Pool\"]\n W1[\"Worker 1
executing T1\"]\n W2[\"Worker 2
executing T2\"]\n W3[\"Worker 3
idle\"]\n end\n\n subgraph ThreadFactory[\"Thread Factory\"]\n TF[\"Creates worker
threads\"]\n end\n end\n\n Submit[\"submit(task)\"]\n Submit --> Q\n Q -->|\"next task\"| W3\n TF -.->|\"creates\"| W1\n TF -.->|\"creates\"| W2\n TF -.->|\"creates\"| W3\n\n style ExecutorService fill:#00ceff,stroke:#000,color:#000\n style TaskQueue fill:#ffa94d,stroke:#000,color:#000\n style ThreadPool fill:#69db7c,stroke:#000,color:#000\n style ThreadFactory fill:#9775fa,stroke:#000,color:#000\n```\n\n\n### The Execution Flow\n\n1. Client submits a task to the executor\n2. Task is placed in the queue (if no idle worker)\n3. An idle worker picks up the task from the queue\n4. Worker executes the task\n5. Worker returns to idle state or picks up next task\n\n\n```mermaid\nsequenceDiagram\n participant C as Client\n participant E as Executor\n participant Q as Queue\n participant W as Worker Thread\n\n C->>E: submit(task)\n E->>Q: enqueue(task)\n E-->>C: Future\n\n W->>Q: poll()\n Q-->>W: task\n\n W->>W: execute task\n\n W->>Q: poll()\n Note over W: Wait for next task\n```\n\n\n---\n\n## 4. Types of Thread Pools\n\nDifferent workloads need different thread pool configurations. Most languages provide factory methods for common patterns.\n\n### Fixed Thread Pool\n\nA pool with a fixed number of threads. If all threads are busy, tasks wait in an unbounded queue.\n\n\n```java\nExecutorService executor = Executors.newFixedThreadPool(4);\n```\n\n\n\n```mermaid\nflowchart LR\n subgraph Fixed[\"Fixed Thread Pool (4 threads)\"]\n Q[\"Unbounded Queue
[waiting tasks...]\"]\n W1[\"Worker 1\"]\n W2[\"Worker 2\"]\n W3[\"Worker 3\"]\n W4[\"Worker 4\"]\n end\n\n Q --> W1\n Q --> W2\n Q --> W3\n Q --> W4\n\n style Fixed fill:#69db7c,stroke:#000,color:#000\n style Q fill:#ffa94d,stroke:#000,color:#000\n```\n\n\n**Use when:** You know the optimal thread count and want predictable resource usage.\n\n### Cached Thread Pool\n\nCreates threads as needed and reuses idle threads. Threads expire after 60 seconds of idleness.\n\n\n```java\nExecutorService executor = Executors.newCachedThreadPool();\n```\n\n\n\n```mermaid\nflowchart LR\n subgraph Cached[\"Cached Thread Pool\"]\n Q[\"SynchronousQueue
(direct handoff)\"]\n W1[\"Worker 1\"]\n W2[\"Worker 2\"]\n Wn[\"Worker N
(created on demand)\"]\n end\n\n New[\"New Task\"] --> Q\n Q -->|\"if idle worker\"| W1\n Q -->|\"if no idle worker\"| Wn\n\n style Cached fill:#00ceff,stroke:#000,color:#000\n style Wn fill:#ffa94d,stroke:#000,color:#000\n```\n\n\n**Use when:** Tasks are short-lived and you have variable load. **Caution:** Can create unlimited threads under high load.\n\n### Single Thread Executor\n\nA pool with exactly one thread. Tasks execute sequentially in submission order.\n\n\n```java\nExecutorService executor = Executors.newSingleThreadExecutor();\n```\n\n\n**Use when:** Tasks must execute sequentially, or you need a dedicated background thread.\n\n### Scheduled Thread Pool\n\nExecutes tasks after a delay or periodically.\n\n\n```java\nScheduledExecutorService executor = Executors.newScheduledThreadPool(2);\n\n// Run after 5 seconds delay\nexecutor.schedule(() -> doTask(), 5, TimeUnit.SECONDS);\n\n// Run every 10 seconds\nexecutor.scheduleAtFixedRate(() -> doTask(), 0, 10, TimeUnit.SECONDS);\n\n// Run with 10 second delay between completions\nexecutor.scheduleWithFixedDelay(() -> doTask(), 0, 10, TimeUnit.SECONDS);\n```\n\n\n\n```mermaid\nflowchart TD\n subgraph Scheduled[\"Scheduled Executor\"]\n DQ[\"Delay Queue
(sorted by execution time)\"]\n W1[\"Worker 1\"]\n W2[\"Worker 2\"]\n end\n\n T1[\"Task (run at 10:00:05)\"]\n T2[\"Task (run at 10:00:10)\"]\n T3[\"Task (run at 10:00:03)\"]\n\n T1 --> DQ\n T2 --> DQ\n T3 --> DQ\n\n DQ -->|\"when time arrives\"| W1\n DQ -->|\"when time arrives\"| W2\n\n style Scheduled fill:#9775fa,stroke:#000,color:#000\n style DQ fill:#ffa94d,stroke:#000,color:#000\n```\n\n\n**Use when:** You need delayed or periodic task execution (timeouts, polling, heartbeats).\n\n### Comparison\n\n\n| ##### Pool Type | ##### Threads | ##### Queue | ##### Use Case |\n| --- | --- | --- | --- |\n| Fixed | Fixed count | Unbounded | Predictable load |\n| Cached | 0 to unlimited | SynchronousQueue | Variable, bursty load |\n| Single | 1 | Unbounded | Sequential execution |\n| Scheduled | Fixed count | DelayQueue | Delayed/periodic tasks |\n\n\n---\n\n## 5. Submitting Tasks\n\nThere are two ways to submit tasks: `execute()` for fire-and-forget, and `submit()` when you need a result or exception handling.\n\n### Runnable vs Callable\n\n\n```mermaid\nflowchart LR\n subgraph Runnable[\"Runnable\"]\n R[\"void run()
No return value
No checked exceptions\"]\n end\n\n subgraph Callable[\"Callable\"]\n C[\"V call()
Returns a value
Can throw exceptions\"]\n end\n\n style Runnable fill:#ffa94d,stroke:#000,color:#000\n style Callable fill:#69db7c,stroke:#000,color:#000\n```\n\n\n### execute() vs submit()\n\n\n| ##### Method | ##### Returns | ##### Exception Handling |\n| --- | --- | --- |\n| `execute(Runnable)` | void | Uncaught exceptions terminate thread |\n| `submit(Runnable)` | Future | Exceptions captured in Future |\n| `submit(Callable)` | Future | Exceptions captured in Future |\n\n\n\n```java\nExecutorService executor = Executors.newFixedThreadPool(4);\n\n// Fire-and-forget\nexecutor.execute(() -> doWork());\n\n// Get a Future (result or exception)\nFuture future = executor.submit(() -> computeValue());\n```\n\n\n---\n\n## 6. Future: Getting Results\n\nWhen you submit a task, you get a `Future` object that represents the pending result.\n\n\n```mermaid\nflowchart LR\n Submit[\"submit(callable)\"]\n Future[\"Future\"]\n Task[\"Task executing...\"]\n Result[\"Result ready\"]\n\n Submit --> Future\n Future -.->|\"get() blocks\"| Task\n Task --> Result\n Result -->|\"returns\"| Future\n\n style Future fill:#00ceff,stroke:#000,color:#000\n style Task fill:#ffa94d,stroke:#000,color:#000\n style Result fill:#69db7c,stroke:#000,color:#000\n```\n\n\n### Future Methods\n\n\n| ##### Method | ##### Description |\n| --- | --- |\n| `get()` | Blocks until result is available |\n| `get(timeout, unit)` | Blocks up to timeout |\n| `isDone()` | Returns true if task completed |\n| `isCancelled()` | Returns true if task was cancelled |\n| `cancel(mayInterrupt)` | Attempts to cancel the task |\n\n\n### Basic Usage\n\n\n```java\nFuture future = executor.submit(() -> {\n Thread.sleep(1000);\n return 42;\n});\n\n// Do other work while task executes...\n\n// Block and get result\nInteger result = future.get(); // Blocks until complete\n\n// Or with timeout\nInteger result = future.get(5, TimeUnit.SECONDS); // Throws TimeoutException if not ready\n```\n\n\n### Handling Exceptions\n\nExceptions thrown by tasks are wrapped in `ExecutionException`:\n\n\n```java\nFuture future = executor.submit(() -> {\n throw new RuntimeException(\"Task failed\");\n});\n\ntry {\n Integer result = future.get();\n} catch (ExecutionException e) {\n Throwable cause = e.getCause(); // The actual exception\n System.err.println(\"Task failed: \" + cause.getMessage());\n}\n```\n\n\n### Waiting for Multiple Tasks\n\n\n```java\nList> futures = new ArrayList<>();\n\n// Submit multiple tasks\nfor (int i = 0; i < 10; i++) {\n futures.add(executor.submit(() -> computeValue()));\n}\n\n// Wait for all and collect results\nList results = new ArrayList<>();\nfor (Future future : futures) {\n results.add(future.get());\n}\n```\n\n\nOr use `invokeAll()`:\n\n\n```java\nList> tasks = List.of(\n () -> computeA(),\n () -> computeB(),\n () -> computeC()\n);\n\n// Submit all and wait for completion\nList> futures = executor.invokeAll(tasks);\n```\n\n\n---\n\n## 7. Shutdown and Lifecycle\n\nProper shutdown is critical. An executor that isn't shut down keeps its threads alive, preventing the JVM from exiting.\n\n\n```mermaid\nstateDiagram-v2\n [*] --> Running: Created\n Running --> ShuttingDown: shutdown()\n Running --> ShuttingDown: shutdownNow()\n ShuttingDown --> Terminated: All tasks complete\n Terminated --> [*]\n\n note right of Running\n Accepting new tasks\n Executing tasks\n end note\n\n note right of ShuttingDown\n Rejecting new tasks\n Completing existing tasks\n (or interrupting with shutdownNow)\n end note\n\n note right of Terminated\n All threads stopped\n All tasks done\n end note\n```\n\n\n### shutdown() vs shutdownNow()\n\n\n| ##### Method | ##### New Tasks | ##### Running Tasks | ##### Queued Tasks |\n| --- | --- | --- | --- |\n| `shutdown()` | Rejected | Complete | Complete |\n| `shutdownNow()` | Rejected | Interrupted | Returned (not executed) |\n\n\n### Proper Shutdown Pattern\n\n\n```java\nexecutor.shutdown(); // Stop accepting new tasks\n\ntry {\n // Wait for existing tasks to complete\n if (!executor.awaitTermination(60, TimeUnit.SECONDS)) {\n executor.shutdownNow(); // Force shutdown\n\n // Wait again for tasks to respond to interruption\n if (!executor.awaitTermination(60, TimeUnit.SECONDS)) {\n System.err.println(\"Executor did not terminate\");\n }\n }\n} catch (InterruptedException e) {\n executor.shutdownNow();\n Thread.currentThread().interrupt();\n}\n```\n\n\n\n```mermaid\nflowchart TD\n Start[\"shutdown()\"]\n Wait1[\"awaitTermination(60s)\"]\n Check1{\"Terminated?\"}\n Force[\"shutdownNow()\"]\n Wait2[\"awaitTermination(60s)\"]\n Check2{\"Terminated?\"}\n Done[\"Shutdown complete\"]\n Error[\"Log error\"]\n\n Start --> Wait1\n Wait1 --> Check1\n Check1 -->|\"Yes\"| Done\n Check1 -->|\"No\"| Force\n Force --> Wait2\n Wait2 --> Check2\n Check2 -->|\"Yes\"| Done\n Check2 -->|\"No\"| Error\n\n style Start fill:#00ceff,stroke:#000,color:#000\n style Done fill:#69db7c,stroke:#000,color:#000\n style Force fill:#ff8787,stroke:#000,color:#000\n style Error fill:#ff8787,stroke:#000,color:#000\n```\n\n\n---\n\n## 8. ThreadPoolExecutor: Custom Thread Pools\n\nThe factory methods use `ThreadPoolExecutor` internally. For fine-grained control, create it directly.\n\n\n```java\nThreadPoolExecutor executor = new ThreadPoolExecutor(\n corePoolSize, // Minimum threads to keep alive\n maximumPoolSize, // Maximum threads allowed\n keepAliveTime, // Idle time before excess threads terminate\n timeUnit, // Unit for keepAliveTime\n workQueue, // Queue for waiting tasks\n threadFactory, // Factory for creating threads\n rejectionHandler // Policy when queue is full\n);\n```\n\n\n### How Core and Max Pool Size Work\n\n\n```mermaid\nflowchart TD\n Task[\"New Task Submitted\"]\n CheckCore{\"Active threads
< corePoolSize?\"}\n CreateCore[\"Create new thread\"]\n CheckQueue{\"Queue has space?\"}\n Enqueue[\"Add to queue\"]\n CheckMax{\"Active threads
< maxPoolSize?\"}\n CreateMax[\"Create new thread\"]\n Reject[\"Reject task\"]\n\n Task --> CheckCore\n CheckCore -->|\"Yes\"| CreateCore\n CheckCore -->|\"No\"| CheckQueue\n CheckQueue -->|\"Yes\"| Enqueue\n CheckQueue -->|\"No\"| CheckMax\n CheckMax -->|\"Yes\"| CreateMax\n CheckMax -->|\"No\"| Reject\n\n style Task fill:#00ceff,stroke:#000,color:#000\n style CreateCore fill:#69db7c,stroke:#000,color:#000\n style Enqueue fill:#ffa94d,stroke:#000,color:#000\n style CreateMax fill:#69db7c,stroke:#000,color:#000\n style Reject fill:#ff8787,stroke:#000,color:#000\n```\n\n\n### Queue Types\n\n\n| ##### Queue Type | ##### Behavior |\n| --- | --- |\n| `LinkedBlockingQueue` | Unbounded queue (maxPoolSize ignored) |\n| `ArrayBlockingQueue` | Bounded queue (enables max threads) |\n| `SynchronousQueue` | No queue, direct handoff (requires max threads) |\n| `PriorityBlockingQueue` | Priority ordering |\n\n\n### Example: Bounded Thread Pool\n\n\n```java\nThreadPoolExecutor executor = new ThreadPoolExecutor(\n 4, // core threads\n 8, // max threads\n 60, TimeUnit.SECONDS, // idle timeout\n new ArrayBlockingQueue<>(100), // bounded queue\n new ThreadPoolExecutor.CallerRunsPolicy() // rejection policy\n);\n```\n\n\n---\n\n## 9. Rejection Policies\n\nWhen the queue is full and max threads are busy, the executor must reject new tasks. The rejection policy determines how.\n\n\n```mermaid\nflowchart TD\n subgraph Policies[\"Rejection Policies\"]\n Abort[\"AbortPolicy
(throw exception)\"]\n Discard[\"DiscardPolicy
(silently drop)\"]\n DiscardOld[\"DiscardOldestPolicy
(drop oldest, retry)\"]\n CallerRuns[\"CallerRunsPolicy
(run in caller thread)\"]\n end\n\n Task[\"Rejected Task\"]\n Task --> Policies\n\n style Policies fill:#00ceff,stroke:#000,color:#000\n style Abort fill:#ff8787,stroke:#000,color:#000\n style Discard fill:#ffa94d,stroke:#000,color:#000\n style DiscardOld fill:#ffa94d,stroke:#000,color:#000\n style CallerRuns fill:#69db7c,stroke:#000,color:#000\n```\n\n\n### Policy Comparison\n\n\n| ##### Policy | ##### Behavior | ##### Use When |\n| --- | --- | --- |\n| **AbortPolicy** | Throws RejectedExecutionException | You need to know about rejections |\n| **DiscardPolicy** | Silently discards task | Task loss is acceptable |\n| **DiscardOldestPolicy** | Discards oldest queued task | Newer tasks are more important |\n| **CallerRunsPolicy** | Runs task in submitting thread | Back-pressure is desired |\n\n\n### CallerRunsPolicy: Built-in Back-Pressure\n\nCallerRunsPolicy is particularly useful. When the pool is saturated, it makes the submitting thread execute the task itself, slowing down the producer.\n\n\n```mermaid\nsequenceDiagram\n participant C as Client Thread\n participant E as Executor\n participant Q as Queue (Full)\n\n C->>E: submit(task)\n E->>Q: enqueue?\n Q-->>E: Queue full, pool saturated\n\n Note over E: CallerRunsPolicy\n\n E->>C: You run the task\n C->>C: Executes task\n Note over C: Client slowed down
(back-pressure)\n```\n\n\n---\n\n## 10. Thread Pool Sizing\n\nChoosing the right pool size depends on your workload.\n\n### CPU-Bound Tasks\n\nTasks that compute without blocking (mathematical calculations, data processing).\n\n**Optimal threads = Number of CPU cores**\n\nMore threads would cause context switching overhead without benefit.\n\n\n```java\nint cpuCores = Runtime.getRuntime().availableProcessors();\nExecutorService executor = Executors.newFixedThreadPool(cpuCores);\n```\n\n\n### I/O-Bound Tasks\n\nTasks that wait for I/O (network calls, disk reads, database queries).\n\n**Optimal threads = CPU cores × (1 + Wait time / Compute time)**\n\nIf tasks spend 90% of time waiting, you can use 10x the cores.\n\n\n```java\n// If tasks are 80% waiting, 20% computing\nint cpuCores = Runtime.getRuntime().availableProcessors();\nint optimalThreads = cpuCores * (1 + 4); // Wait/Compute = 0.8/0.2 = 4\nExecutorService executor = Executors.newFixedThreadPool(optimalThreads);\n```\n\n\n### Sizing Guidelines\n\n\n```mermaid\nflowchart TD\n Start[\"What type of workload?\"]\n CPU[\"CPU-Bound\"]\n IO[\"I/O-Bound\"]\n Mixed[\"Mixed\"]\n\n CPUSize[\"Threads = CPU cores\"]\n IOSize[\"Threads = cores × (1 + wait/compute)\"]\n MixedSize[\"Separate pools for
CPU and I/O tasks\"]\n\n Start --> CPU\n Start --> IO\n Start --> Mixed\n\n CPU --> CPUSize\n IO --> IOSize\n Mixed --> MixedSize\n\n style Start fill:#00ceff,stroke:#000,color:#000\n style CPUSize fill:#69db7c,stroke:#000,color:#000\n style IOSize fill:#69db7c,stroke:#000,color:#000\n style MixedSize fill:#69db7c,stroke:#000,color:#000\n```\n\n\n\n| ##### Workload | ##### Formula | ##### Example (8 cores) |\n| --- | --- | --- |\n| CPU-bound | cores | 8 threads |\n| I/O-bound (50% wait) | cores × 2 | 16 threads |\n| I/O-bound (90% wait) | cores × 10 | 80 threads |\n\n\n---\n\n## 11. Common Patterns\n\n### Pattern 1: Web Server Request Handler\n\n\n```java\npublic class WebServer {\n private final ExecutorService executor = Executors.newFixedThreadPool(200);\n\n public void handleRequest(Request request) {\n executor.submit(() -> {\n Response response = processRequest(request);\n sendResponse(response);\n });\n }\n}\n```\n\n\n### Pattern 2: Parallel Processing with Results\n\n\n```java\npublic List processInParallel(List items) throws Exception {\n List> tasks = items.stream()\n .map(item -> (Callable) () -> process(item))\n .toList();\n\n List> futures = executor.invokeAll(tasks);\n\n List results = new ArrayList<>();\n for (Future future : futures) {\n results.add(future.get());\n }\n return results;\n}\n```\n\n\n### Pattern 3: Timeout for External Calls\n\n\n```java\npublic Result callExternalService(Request request) {\n Future future = executor.submit(() -> externalService.call(request));\n\n try {\n return future.get(5, TimeUnit.SECONDS);\n } catch (TimeoutException e) {\n future.cancel(true); // Cancel the task\n throw new ServiceTimeoutException(\"External service timed out\");\n }\n}\n```\n\n\n### Pattern 4: Periodic Health Check\n\n\n```java\nScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1);\n\nscheduler.scheduleAtFixedRate(\n () -> {\n if (!healthCheck()) {\n alertOps();\n }\n },\n 0, // initial delay\n 30, // period\n TimeUnit.SECONDS\n);\n```\n\n\n### Pattern 5: Graceful Shutdown with Hook\n\n\n```java\npublic class Application {\n private final ExecutorService executor = Executors.newFixedThreadPool(10);\n\n public void start() {\n Runtime.getRuntime().addShutdownHook(new Thread(() -> {\n executor.shutdown();\n try {\n executor.awaitTermination(30, TimeUnit.SECONDS);\n } catch (InterruptedException e) {\n executor.shutdownNow();\n }\n }));\n }\n}\n```\n\n\n---\n\n## 12. Common Pitfalls\n\n### Pitfall 1: Never Shutting Down\n\n\n```java\n// Bad: Executor never shut down, threads keep running\npublic void processTask(Task task) {\n ExecutorService executor = Executors.newFixedThreadPool(4);\n executor.submit(() -> process(task));\n // Executor never shut down!\n}\n\n// Good: Use try-with-resources or ensure shutdown\nExecutorService executor = Executors.newFixedThreadPool(4);\ntry {\n executor.submit(() -> process(task));\n} finally {\n executor.shutdown();\n}\n```\n\n\n### Pitfall 2: Unbounded Queue with Fixed Pool\n\n\n```java\n// Dangerous: Unbounded queue can cause OutOfMemoryError\nExecutorService executor = Executors.newFixedThreadPool(4);\n// Uses LinkedBlockingQueue with no limit\n\n// Better: Bounded queue with rejection policy\nThreadPoolExecutor executor = new ThreadPoolExecutor(\n 4, 4, 0L, TimeUnit.MILLISECONDS,\n new ArrayBlockingQueue<>(1000),\n new ThreadPoolExecutor.CallerRunsPolicy()\n);\n```\n\n\n### Pitfall 3: Ignoring Exceptions in Tasks\n\n\n```java\n// Bad: Exception silently swallowed\nexecutor.execute(() -> {\n throw new RuntimeException(\"Oops\"); // Lost forever\n});\n\n// Good: Use submit() and check Future\nFuture future = executor.submit(() -> {\n throw new RuntimeException(\"Oops\");\n});\n\ntry {\n future.get();\n} catch (ExecutionException e) {\n logger.error(\"Task failed\", e.getCause());\n}\n```\n\n\n### Pitfall 4: Blocking in Cached Thread Pool\n\n\n```java\n// Bad: Cached pool with long-running blocking tasks\nExecutorService executor = Executors.newCachedThreadPool();\n\nfor (int i = 0; i < 10000; i++) {\n executor.submit(() -> {\n blockingIOOperation(); // Creates 10000 threads!\n });\n}\n\n// Good: Use fixed pool for blocking operations\nExecutorService executor = Executors.newFixedThreadPool(100);\n```\n\n\n### Pitfall 5: Using Default Thread Factory in Production\n\n\n```java\n// Default threads have unhelpful names: pool-1-thread-1\nExecutorService executor = Executors.newFixedThreadPool(4);\n\n// Better: Custom thread factory with meaningful names\nExecutorService executor = Executors.newFixedThreadPool(4, r -> {\n Thread t = new Thread(r);\n t.setName(\"order-processor-\" + t.getId());\n t.setDaemon(false);\n return t;\n});\n```\n\n\n---\n\n## 13. Summary\n\n**Executor Service** provides a high-level abstraction for managing thread pools and executing tasks asynchronously.\n\n\n```mermaid\nflowchart TD\n subgraph Components[\"Executor Service Components\"]\n Pool[\"Thread Pool
(worker threads)\"]\n Queue[\"Task Queue
(waiting tasks)\"]\n Policy[\"Rejection Policy
(when saturated)\"]\n end\n\n subgraph Operations[\"Key Operations\"]\n Submit[\"submit() / execute()\"]\n Future[\"Future\"]\n Shutdown[\"shutdown()\"]\n end\n\n Components --> Operations\n\n style Components fill:#00ceff,stroke:#000,color:#000\n style Operations fill:#69db7c,stroke:#000,color:#000\n```\n\n\n### Thread Pool Selection\n\n\n| ##### Pool Type | ##### Queue | ##### Use Case |\n| --- | --- | --- |\n| Fixed | Unbounded | Known optimal thread count |\n| Cached | SynchronousQueue | Short tasks, variable load |\n| Single | Unbounded | Sequential execution |\n| Scheduled | DelayQueue | Delayed/periodic tasks |\n| Custom | Configurable | Specific requirements |\n\n\n### Sizing Guidelines\n\n\n| ##### Workload | ##### Thread Count |\n| --- | --- |\n| CPU-bound | CPU cores |\n| I/O-bound | CPU cores × (1 + wait/compute) |\n| Mixed | Separate pools |\n\n\n### Best Practices\n\n1. **Always shut down executors** to prevent resource leaks\n2. **Use bounded queues** to prevent memory issues\n3. **Choose appropriate rejection policy** for your use case\n4. **Size pools based on workload** (CPU vs I/O bound)\n5. **Use custom thread factories** with meaningful names\n6. **Handle exceptions** from tasks (use Future.get())\n7. **Prefer submit() over execute()** for better error handling\n8. **Use CallerRunsPolicy** for natural back-pressure\n9. **Add shutdown hooks** for graceful termination\n\nExecutor services are fundamental to building scalable concurrent applications. Understanding their internals helps you configure them correctly and avoid common pitfalls.\n\n---\n\nThank you for reading!\n\nIf you found it valuable, hit a like and consider subscribing for more such content every week.\n\nIf you have any questions or suggestions, leave a comment.\n\nThis post is public so feel free to share it.\n\n[Share](undefined)\n\n---\n\n**P.S.** If you're enjoying this newsletter and want to get even more value, consider becoming a **[paid subscriber](https://blog.algomaster.io/subscribe)**.\n\nAs a paid subscriber, you'll unlock all **premium articles** and gain full access to all **[premium courses](https://algomaster.io/newsletter/paid/resources)** on **[algomaster.io](https://algomaster.io)**.\n\n[Unlock Full Access](undefined)\n\n**There are [group discounts](https://blog.algomaster.io/subscribe?group=true), [gift options](https://blog.algomaster.io/subscribe?gift=true), and [referral bonuses](https://blog.algomaster.io/leaderboard) available.**\n\n---\n\nCheckout my **[Youtube channel](https://www.youtube.com/@ashishps_1/videos)** for more in-depth content.\n\nFollow me on **[LinkedIn](https://www.linkedin.com/in/ashishps1/)** and **[X](https://twitter.com/ashishps_1)** to stay updated.\n\nCheckout my **[GitHub repositories](https://github.com/ashishps1)** for free interview preparation resources.\n\nI hope you have a lovely day!\n\nSee you soon, Ashish\n\n---\n\n## References\n\n- [Java Concurrency in Practice (Brian Goetz)](undefined) - Chapter 6: Task Execution, Chapter 8: Applying Thread Pools\n- [Java ExecutorService Documentation](undefined)\n- [Java ThreadPoolExecutor Documentation](undefined)\n- [Effective Java (Joshua Bloch)](undefined) - Item 80: Prefer executors, tasks, and streams to threads\n\n---\n\n## Images Needed\n\n[IMAGE 1: Thread-per-Task Problems] \n\n[IMAGE 2: Executor Service Architecture] \n\n[IMAGE 3: Thread Pool Types Comparison] \n\n[IMAGE 4: Task Submission Flow] \n\n[IMAGE 5: Shutdown Lifecycle] \n\n[IMAGE 6: Thread Pool Sizing Decision] ","pageType":"lld-interviews"}

ExecutorService

Ashish Pratap Singh

Get Premium