Executor Service & Thread Pools

Creating a new thread for every task is expensive. Each thread consumes ~1MB of stack memory and requires OS context switching. Instead of managing threads manually, Java provides the Executor Framework to reuse threads efficiently.

1. Why Use Thread Pools?

A Thread Pool is a collection of pre-started threads that are ready to execute tasks.

  • Reuse: Threads are returned to the pool after finishing a task, saving creation costs.
  • Throttling: Limits the number of active threads to prevent crashing the CPU.
  • Management: Provides lifecycle methods (shutdown, awaitTermination).

2. Types of Thread Pools

The Executors factory class provides several pre-configured pools:

Pool Type Description Use Case
FixedThreadPool(n) Reuse a fixed number of threads. If all are busy, tasks wait in a queue. Predictable load, stable servers.
CachedThreadPool Creates new threads as needed, but reuses idle ones. Threads die after 60s of inactivity. Short-lived async tasks.
SingleThreadExecutor Uses a single worker thread to execute tasks sequentially. Ensuring order (like an event loop).
ScheduledThreadPool Executes tasks after a delay or periodically. Background maintenance, cron jobs. 
// Create a pool with 4 threads
ExecutorService executor = Executors.newFixedThreadPool(4);

for (int i = 0; i < 10; i++) {
  int taskId = i;
  executor.submit(() -> {
    System.out.println("Executing Task " + taskId + " on " + Thread.currentThread().getName());
  });
}

// Always shutdown your pool!
executor.shutdown();

Interactive: Thread Pool Visualizer

Watch how tasks queue up when the worker threads are busy.

Task Queue
→
Worker Threads (Pool Size: 3)
Thread-1 Idle
Thread-2 Idle
Thread-3 Idle

3. Handling Results with Callable and Future

Standard Runnable tasks cannot return a result or throw checked exceptions. Use Callable<T> instead.

Callable<Integer> task = () -> {
  Thread.sleep(1000);
  return 42;
};

ExecutorService executor = Executors.newFixedThreadPool(2);
Future<Integer> future = executor.submit(task);

// Do other work here...

try {
  // Blocks until the result is ready
  Integer result = future.get();
  System.out.println("Result: " + result);
} catch (InterruptedException | ExecutionException e) {
  e.printStackTrace();
}

4. Go Implementation: Worker Pools

Go does not have a built-in “Thread Pool” class because goroutines are cheap. However, to throttle concurrency (e.g., limit DB connections), we use the Worker Pool Pattern with channels.

package main

import (
  "fmt"
  "sync"
  "time"
)

func worker(id int, jobs <-chan int, results chan<- int, wg *sync.WaitGroup) {
  defer wg.Done()
  for j := range jobs {
    fmt.Printf("Worker %d started job %d\n", id, j)
    time.Sleep(time.Second) // Simulate work
    fmt.Printf("Worker %d finished job %d\n", id, j)
    results <- j * 2
  }
}

func main() {
  const numJobs = 5
  jobs := make(chan int, numJobs)
  results := make(chan int, numJobs)
  var wg sync.WaitGroup

  // Start 3 workers (Fixed Pool equivalent)
  for w := 1; w <= 3; w++ {
    wg.Add(1)
    go worker(w, jobs, results, &wg)
  }

  // Send jobs
  for j := 1; j <= numJobs; j++ {
    jobs <- j
  }
  close(jobs)

  // Wait for workers in background
  go func() {
    wg.Wait()
    close(results)
  }()

  // Collect results
  for r := range results {
    fmt.Println("Result:", r)
  }
}

5. Best Practices

  1. Always Shutdown: Executor services keep the JVM running. Use executor.shutdown() or try-with-resources (Java 19+).
  2. Avoid Unbounded Queues: newFixedThreadPool uses an unbounded queue. If tasks come in faster than they are processed, you will get an OutOfMemoryError.
  3. Use virtualThreadPerTaskExecutor: In Java 21+, if your tasks are blocking (I/O), use virtual threads instead of pooling platform threads.

[!TIP] Virtual Threads vs Pools:

  • Platform Threads (Old): Must be pooled because they are expensive (1MB RAM).
  • Virtual Threads (New): Should NOT be pooled. Create a new virtual thread for every task.