Handing Work to a Pool Instead of Making a Thread for It

Ten thousand short tasks, one new Thread each. The program spends more time creating and destroying threads than doing the work, and somewhere around the eight thousandth one the machine stops cooperating.

A thread runs once and cannot be restarted, so a thread per task means a thread per task. A pool inverts that: a fixed set of threads that stay alive, and a queue of tasks they take from.

java

ExecutorService pool = Executors.newFixedThreadPool(4);

for (Path file : files) {
    pool.submit(() -> process(file));
}

What the pool separates
You decide	The pool decides
What work there is	Which thread runs it
When to submit it	When it starts
How many threads exist	Which thread is free

Four threads handle ten thousand tasks, taking the next one whenever they finish the last. Nothing is created per task except the lambda, and the number of threads stops being a function of the amount of work.

So a pool is a decision about capacity rather than about scheduling. You choose how much of the machine this work may use, and the pool takes care of the rest.