Card 08/ 09
Practice: Choosing an Executor for Four Workloads
Computing, waiting, scheduling and combining: which pool fits each, and what the wrong one costs.
Work that computes wants about as many threads as there are processor cores; work that waits wants as many threads as there is work, which virtual threads make affordable. For each workload below, choose what to run it on and say what the wrong choice would cost, all four before you open the answer.
| The workload | |
|---|---|
| 1 | Resizing ten thousand images; each takes a second of pure computation |
| 2 | Twenty thousand open connections, each mostly waiting on the network |
| 3 | One task every minute, forever, checking a directory |
| 4 | Three independent service calls whose results are combined into one response |
The four choices, and what the wrong one costs
| Use | The wrong choice costs | |
|---|---|---|
| 1 | A fixed pool, sized to the processor count | More threads than cores add switching and no throughput |
| 2 | A virtual thread (a lightweight thread the JVM schedules itself) per task | Twenty thousand platform threads reserve around twenty gigabytes of stack |
| 3 | A single-threaded scheduled executor | A new thread per minute, and no way to stop the schedule |
| 4 | CompletableFuture (a future you can chain and combine), combined | Three blocking get() calls in turn take the sum of the times, not the maximum |
The first two are most of pool sizing. Work that computes wants about as many threads as there are cores; work that waits wants as many as there is work.
The fourth is the one that looks fine in review. Submitting all three and then collecting takes as long as the slowest; submitting and waiting one at a time takes as long as all three together.
← → move through sections and cards