Thread Pool Pattern

Intent

It is often the case that tasks to be executed are short-lived and the number of tasks is large. Creating a new thread for each task would make the system spend more time creating and destroying the threads than executing the actual tasks. Thread Pool solves this problem by reusing existing threads and eliminating the latency of creating new threads.

Also Known As

replicated workers or worker-crew model.

Explanation

 Thread Pool pattern is where a number of threads are created to perform a number of tasks, which are usually organized in a queue. The results from the tasks being executed might also be placed in a queue, or the tasks might return no result. Typically, there are many more tasks than threads. As soon as a thread completes its task, it will request the next task from the queue until all tasks have been completed. The thread can then terminate, or sleep until there are new tasks available.

Performance

The size of a thread pool is the number of threads kept in reserve for executing tasks. It is usually a tunable parameter of the application, adjusted to optimize program performance.

The primary benefit of a thread pool over creating a new thread for each task is that thread creation and destruction overhead is restricted to the initial creation of the pool, which may result in better performance and better system stability. Creating and destroying a thread and its associated resources is an expensive process in terms of time. An excessive number of threads in reserve, however, wastes memory, and context-switching between the runnable threads invoke performance penalties. 

The algorithm used to determine when to create or destroy threads affects the overall performance:
  • Creating too many threads wastes resources and costs time creating the unused threads.
  • Destroying too many threads requires more time later when creating them again.
  • Creating threads too slowly might result in poor client performance (long wait times).
  • Destroying threads too slowly may starve other processes of resources.

Source code

In this example, we create a list of tasks presenting work to be done. Each task is then wrapped into a Worker object that implements Runnable interface. We create an ExecutorService with a fixed number of threads (Thread Pool) and use them to execute the Workers.

Class Diagram

Class diagram of Thread Pool Pattern

Let's implement the source code for above class diagram.
Step 1: Create an Abstract base class for tasks.
public abstract class Task {

private static final AtomicInteger ID_GENERATOR = new AtomicInteger();

private final int id;
private final int timeMs;

public Task(final int timeMs) {
this.id = ID_GENERATOR.incrementAndGet();
this.timeMs = timeMs;
}

public int getId() {
return id;
}

public int getTimeMs() {
return timeMs;
}

@Override
public String toString() {
return String.format("id=%d timeMs=%d", id, timeMs);
}
}
Step 2: CoffeeMakingTask is a concrete task.
public class CoffeeMakingTask extends Task {

private static final int TIME_PER_CUP = 100;

public CoffeeMakingTask(int numCups) {
super(numCups * TIME_PER_CUP);
}

@Override
public String toString() {
return String.format("%s %s", this.getClass().getSimpleName(), super.toString());
}
}
Step 3: PotatoPeelingTask is a concrete task.
public class PotatoPeelingTask extends Task {

private static final int TIME_PER_POTATO = 200;

public PotatoPeelingTask(int numPotatoes) {
super(numPotatoes * TIME_PER_POTATO);
}

@Override
public String toString() {
return String.format("%s %s", this.getClass().getSimpleName(), super.toString());
}
}
Step 4: Worker implements Runnable and thus can be executed by ExecutorService.
public class Worker implements Runnable {

private final Task task;

public Worker(final Task task) {
this.task = task;
}

@Override
public void run() {
System.out.println(String.format("%s processing %s", Thread.currentThread().getName(),
task.toString()));
try {
Thread.sleep(task.getTimeMs());
} catch (InterruptedException e) {
e.printStackTrace();
}
Step 5: Let's test this pattern via the main method: program entry point.
public class App {

/**
* Program entry point
*
* @param args command line args
*/

public static void main(String[] args) {

System.out.println("Program started");

// Create a list of tasks to be executed
List<Task> tasks = new ArrayList<>();
tasks.add(new PotatoPeelingTask(3));
tasks.add(new PotatoPeelingTask(6));
tasks.add(new CoffeeMakingTask(2));
tasks.add(new CoffeeMakingTask(6));
tasks.add(new PotatoPeelingTask(4));
tasks.add(new CoffeeMakingTask(2));
tasks.add(new PotatoPeelingTask(4));
tasks.add(new CoffeeMakingTask(9));
tasks.add(new PotatoPeelingTask(3));
tasks.add(new CoffeeMakingTask(2));
tasks.add(new PotatoPeelingTask(4));
tasks.add(new CoffeeMakingTask(2));
tasks.add(new CoffeeMakingTask(7));
tasks.add(new PotatoPeelingTask(4));
tasks.add(new PotatoPeelingTask(5));

// Creates a thread pool that reuses a fixed number of threads operating off a shared
// unbounded queue. At any point, at most nThreads threads will be active processing
// tasks. If additional tasks are submitted when all threads are active, they will wait
// in the queue until a thread is available.
ExecutorService executor = Executors.newFixedThreadPool(3);

// Allocate new worker for each task
// The worker is executed when a thread becomes
// available in the thread pool
for (int i = 0; i < tasks.size(); i++) {
Runnable worker = new Worker(tasks.get(i));
executor.execute(worker);
}
// All tasks were executed, now shutdown
executor.shutdown();
while (!executor.isTerminated()) {
Thread.yield();
}
System.out.println("Program finished");
}
}

Applicability

Use the Thread Pool pattern when
  • you have a large number of short-lived tasks to be executed in parallel.

Comments

Popular posts from this blog

Design Patterns used in Hibernate Framework

Value List Handler