Stop Making Threads

Separate the work from the thread that runs it.

ExecutorService pool = Executors.newFixedThreadPool(4);

pool.submit(() -> handle(socket));

pool.shutdown();

You hand over tasks. The pool decides which thread runs each one, and reuses them.

Verified, fifty tasks into a pool of two:

50 tasks ran on 2 threads: [pool-1-thread-3, pool-1-thread-2]

Two threads created, fifty jobs done.

Callable is Runnable that can answer.

public interface Runnable { void run(); }
public interface Callable<V> { V call() throws Exception; }

Two differences and both matter. Callable returns a value, and it can throw a checked exception. Both are only possible because somebody is waiting for the result, which is what Future is.

Future<Integer> f = pool.submit(() -> expensiveCalculation());
Integer answer = f.get();       // waits until it is ready

Future is a receipt. get() blocks until the answer exists, get(timeout) gives up, cancel() asks to stop, isDone() asks without waiting.

And this is where a worker’s exception finally reaches you.

Future<?> f = pool.submit(() -> { throw new RuntimeException("boom"); });
f.get();      // throws ExecutionException, with the original as its cause

That is the answer to Section 14.2, where a thread’s exception had nowhere to go. Somebody is holding a receipt, so there is now a place to put it.

The pools you get from Executors:

Shutting one down has two levels:

pool.shutdown();                                 // no new tasks. Finish what is queued
pool.awaitTermination(30, TimeUnit.SECONDS);     // wait for that
pool.shutdownNow();                              // interrupt the running ones, drop the queue

shutdownNow interrupts every worker, so it only works if your tasks respond to interruption, which is everything from Section 14.3. A task that swallows InterruptedException cannot be stopped by it.

Submitting after shutdown throws RejectedExecutionException, verified.

Answer from memory before opening the explanation. Then compare your rule with the answer and revisit the example if they differ.

1. What does a thread pool actually save you?

   Show the answer

   Creation, and the memory that goes with it. A thread reserves a stack of around a megabyte before it does any work, from Section 13.1, and it cannot be restarted once it finishes.

   A pool makes its threads once and feeds them tasks. Verified: fifty tasks submitted to a pool of two ran on exactly two threads.

   It also gives you a bound. Without one, a thread per request means a thousand requests is a thousand threads and most of a gigabyte of stacks, and the machine falls over rather than getting slower.

2. `execute` and `submit` both run a task. What happens when the task throws?

   Show the answer

   execute lets it reach the thread's uncaught exception handler, so the stack trace is printed. Loud, and easy to notice.

   submit catches it and stores it in the Future. Nothing is printed and nothing is logged. Verified: a failing task submitted with submit produced no output at all until get() was called, which then threw ExecutionException wrapping the original.

   So a submitted task that fails and whose Future nobody looks at fails completely silently. That is the most common way an executor loses work.

3. Why is `Executors.newFixedThreadPool(10)` the wrong way to build a pool?

   Show the answer

   Because of the queue it gives you. Verified: it is a LinkedBlockingQueue with a remaining capacity of 2,147,483,647.

   Effectively unbounded. If tasks arrive faster than ten threads can finish them, the queue grows until the heap runs out, and you get an OutOfMemoryError rather than any sign that the system is overloaded.

   Backpressure is the thing you actually want: when the queue is full, the caller should be told, so it can slow down, shed load or fail fast. An unbounded queue removes that signal and turns a capacity problem into a crash.

   Building a ThreadPoolExecutor directly lets you set a bounded queue and say what happens when it fills.

Write each solution in VS Code, predict its result, and then run the checks. Reading an example does not replace implementing it.

4 exercises105 pointsabout 100 minutes

import java.util.*;
import java.util.concurrent.*;

public class Reused {
    public static void main(String[] args) throws Exception {
        // TODO: a pool of two. Submit fifty tasks that each record the name of
        //       the thread they ran on. Print the set of distinct names.
        // TODO: do the same with new Thread() per task and count the names
        // TODO: time both at 50 tasks and at 5000 tasks
        // TODO: forget to shut the pool down. Does the program exit?
    }
}

import java.util.concurrent.*;

public class Envelope {
    public static void main(String[] args) throws Exception {
        // TODO: submit a failing task with execute(). What appears on screen?
        // TODO: submit the same failing task with submit(). Now what appears?
        // TODO: call get() on that Future. What comes out, and what is inside it?
        // TODO: submit twenty tasks where three fail, ignoring all the Futures.
        //       How would you ever find out?
        // TODO: fix it two ways: check every Future, and wrap the task body
    }
}

import java.util.concurrent.*;

public class Unbounded {
    public static void main(String[] args) throws Exception {
        // TODO: ask newFixedThreadPool(1) what queue it uses and what its
        //       remaining capacity is. Predict first.
        // TODO: with -Xmx128m, submit slow tasks in a tight loop and watch it die
        // TODO: build a ThreadPoolExecutor with an ArrayBlockingQueue(100)
        //       and AbortPolicy. Submit the same load. What happens instead?
        // TODO: try CallerRunsPolicy and describe how the producer behaves
        // TODO: say which failure you would rather have at 3am
    }
}

import java.util.concurrent.*;

public class PoolLock {
    public static void main(String[] args) throws Exception {
        // TODO: a pool of ONE. Submit a task that itself submits a second task
        //       to the same pool and calls get() on it. Predict what happens.
        // TODO: do the same with a pool of two and two levels of nesting
        // TODO: print the pool's active count and queue size while it is stuck
        // TODO: fix it three ways: a separate pool, more threads, or no nested get
        // TODO: say which fix actually removes the problem rather than moving it
    }
}