Thread Pool — Practice Tasks¶

Hands-on exercises for the Thread Pool pattern, easy → hard. Each task has a goal, requirements, hints, and a solution sketch. Work in junior.md/middle.md first; tasks 7–10 lean on senior.md/professional.md.

Table of Contents¶

1. Task 1 — Build a fixed pool and prove reuse
2. Task 2 — Submit and collect results with Future
3. Task 3 — Refactor thread-per-request to a bounded pool
4. Task 4 — Demonstrate the unbounded-queue trap
5. Task 5 — Implement all four rejection policies
6. Task 6 — Build a Go worker pool with results
7. Task 7 — Size an IO-bound pool with the Goetz formula
8. Task 8 — Reproduce and fix pool-induced deadlock
9. Task 9 — Bulkhead two dependencies
10. Task 10 — Migrate an IO pool to virtual threads
11. How to Practice

Task 1 — Build a fixed pool and prove reuse¶

Goal: Show that a thread pool reuses threads rather than creating one per task.

Requirements: - Submit 1,000 tasks to a 4-thread pool. - Each task records Thread.currentThread().getName(). - Assert that only 4 distinct thread names appear.

Hints: Collect names in a ConcurrentHashMap.newKeySet(). Shut down and awaitTermination before asserting.

ExecutorService pool = Executors.newFixedThreadPool(4);
Set<String> names = ConcurrentHashMap.newKeySet();
for (int i = 0; i < 1000; i++) pool.submit(() -> names.add(Thread.currentThread().getName()));
pool.shutdown(); pool.awaitTermination(10, TimeUnit.SECONDS);
assert names.size() == 4;   // exactly the 4 reused workers

Task 2 — Submit and collect results with Future¶

Goal: Fan out N computations, fan in the results.

Requirements: - Submit 50 Callable<Integer> tasks (return i * i). - Collect results in submission order; handle ExecutionException.

Hints: Keep Futures in a List; loop and get(). Unwrap e.getCause() on failure.

List<Future<Integer>> fs = new ArrayList<>();
for (int i = 0; i < 50; i++) { final int n = i; fs.add(pool.submit(() -> n * n)); }
List<Integer> out = new ArrayList<>();
for (Future<Integer> f : fs)
    try { out.add(f.get()); }
    catch (ExecutionException e) { log.error("task failed", e.getCause()); }

Task 3 — Refactor thread-per-request to a bounded pool¶

Goal: Cap concurrency on a server that currently spawns a thread per connection.

Starting code:

while (true) {
    Socket conn = server.accept();
    new Thread(() -> handle(conn)).start();   // unbounded
}

Requirements: - Replace with a bounded ThreadPoolExecutor (bounded queue, named threads, a rejection policy). - Under a flood of 10,000 connections, prove the live thread count never exceeds maximumPoolSize.

Hints: Track pool.getPoolSize() / getLargestPoolSize(). Use CallerRunsPolicy to avoid dropping connections while throttling.

ThreadPoolExecutor pool = new ThreadPoolExecutor(
    16, 64, 60, TimeUnit.SECONDS, new ArrayBlockingQueue<>(256),
    named("conn"), new ThreadPoolExecutor.CallerRunsPolicy());
while (true) {
    Socket conn = server.accept();
    pool.execute(() -> { try (conn) { handle(conn); } catch (IOException e) { log.warn("", e); } });
}
// After the flood: assert pool.getLargestPoolSize() <= 64

Task 4 — Demonstrate the unbounded-queue trap¶

Goal: Prove that an unbounded queue makes maximumPoolSize meaningless.

Requirements: - Create a ThreadPoolExecutor with core=2, max=10, LinkedBlockingQueue (unbounded). - Submit slow tasks faster than they complete; record getLargestPoolSize(). - Show it stays at 2 even though max is 10, and the queue grows unboundedly.

Hints: Each task sleeps; submit thousands quickly. Watch getQueue().size() climb.

Task 5 — Implement all four rejection policies¶

Goal: Feel each saturation policy's behavior.

Requirements: - Tiny pool (core=max=1, ArrayBlockingQueue(1)). - Submit 5 tasks rapidly under each of AbortPolicy, CallerRunsPolicy, DiscardPolicy, DiscardOldestPolicy. - Record which tasks run, which are dropped, and which throw.

Hints: Wrap submission in try/catch to observe RejectedExecutionException under AbortPolicy.

Task 6 — Build a Go worker pool with results¶

Goal: Implement the pattern from primitives in Go.

Requirements: - N worker goroutines drain a jobs channel. - Results flow back on a results channel; collect all of them. - Graceful shutdown: close jobs, wait for workers via sync.WaitGroup, then close results.

Hints: Use a buffered jobs channel as the bounded queue. Close results only after wg.Wait().

Task 7 — Size an IO-bound pool with the Goetz formula¶

Goal: Compute a defensible pool size, then validate it.

Requirements: - Given: 16 cores, target CPU utilization 0.9, tasks that wait 180 ms (network) and compute 20 ms. - Compute N = N_cores × U × (1 + W/C). - Load-test at that size; watch queue depth and p99 latency; adjust.

Hints: W/C = 180/20 = 9.

Task 8 — Reproduce and fix pool-induced deadlock¶

Goal: Make a pool deadlock itself, then fix it three ways.

Requirements: - Pool of size 2. Submit 2 tasks; each submits an inner task to the same pool and calls get(). - Observe the deadlock (no progress, both workers blocked). - Fix with: (a) a separate inner pool, (b) CompletableFuture.thenApplyAsync, (c) restructuring to not block a worker.

Hints: A thread dump shows both workers parked in FutureTask.get.

Task 9 — Bulkhead two dependencies¶

Goal: Prove that isolated pools contain a dependency failure.

Requirements: - One service calls a fast cache and a slow payment dependency. - Version A: shared pool of 8. Version B: separate cachePool(8) and paymentPool(4). - Inject a 5-second latency into payment; measure cache request latency under both versions.

Hints: Drive concurrent load at both dependencies; record cache p99.

Task 10 — Migrate an IO pool to virtual threads¶

Goal: Replace a large platform-thread IO pool with virtual threads, keeping the downstream cap.

Requirements: - Start from a ThreadPoolExecutor(144, 144, ...) serving blocking HTTP calls (from Task 7). - Replace with Executors.newVirtualThreadPerTaskExecutor(). - Re-introduce the downstream concurrency cap with a Semaphore (the DB allows 20 connections). - Verify at most 20 concurrent DB calls despite thousands of virtual threads.

Hints: Semaphore(20); acquire/release around the DB call. Check for synchronized pinning with -Djdk.tracePinnedThreads=full.

ExecutorService pool = Executors.newVirtualThreadPerTaskExecutor();
Semaphore dbLimit = new Semaphore(20);
pool.submit(() -> {
    dbLimit.acquire();
    try { return queryDb(); } finally { dbLimit.release(); }
});

How to Practice¶

• Always measure, don't assume. Print getPoolSize, getLargestPoolSize, getQueue().size(), getCompletedTaskCount, and rejection counts. The numbers teach the growth rule and the trap faster than reading does.
• Reproduce failures on purpose. Deliberately cause OOM (unbounded queue), deadlock (same-pool get()), and starvation (shared pool + slow dependency) in small programs. Engineers who've seen these recognize them instantly in production.
• Tune against a load generator, not a single run. The queue-lock cliff and tail-latency blowups only appear under concurrency.
• Diff platform vs virtual threads on the same IO workload at 10k concurrency to feel why Loom changes the calculus.
• Write the assertions first (max thread count, max concurrent downstream calls) so each task proves a property, not just "it ran."