What is a thread pool and why reuse threads instead of spawning?

beginner

← All Concurrency & Multithreading questions

Re-explain

A thread pool is a fixed set of worker threads that pull tasks from a shared queue. You submit work, and an idle worker picks it up, runs it, then loops back for more. The workers live for the life of the program.

Reusing threads skips the cost of creating and destroying one per task. That setup, tens of microseconds each, adds up fast under load.

A pool also caps concurrency. You never launch ten thousand threads and exhaust memory or thrash the scheduler, because the queue absorbs bursts instead.

The tradeoff is sizing. Too few workers leave tasks waiting, and too many fight over cores. Use roughly the core count for compute, and more for I/O-bound work.

Rewriting in plainer words…

This answer doesn't lend itself to a diagram - it reads best . No credits were charged.

Why there's no diagram: “”

The interactive diagram is below the answer - jump to diagram ↓ · Below it, the related concept . Jump to it ↓

The diagram below the answer is the concept . Jump to it ↓

Tailored explanation · switch back to · ·

What should the new diagram focus on?

Guided practice for Concurrency & Multithreading One question at a time. Answer out loud, get graded, see what you missed.

How well did you know this?

AI:

Saved in this browser - sign in to keep your review list.

How should your speech become text?

Listening… your words appear above as you speak - tap Stop when you're done.

Recording · cr - tap Stop & transcribe when you're done.

Transcribing with AI…

Voice:

Keep going - a few more words and AI can grade it.

Interview lens How interviewers actually use this question

Likely follow-ups

How would you size a pool for CPU-bound work versus I/O-bound work, and how would you check the choice? Core count for compute, since extra threads only add switching. More for I/O, since workers sit blocked. Then measure queue wait and CPU use.
What goes wrong if the pool's work queue has no limit and tasks arrive faster than workers finish them? Memory grows until the process fails, and latency climbs for every queued task. Bound the queue and choose a rejection or backpressure policy.
If a task blocks waiting on a subtask it submitted to the same pool, what can go wrong? Every worker can end up blocked on subtasks stuck in the queue behind them. Avoid blocking waits inside tasks, or give subtasks their own pool.
When would you use async I/O instead of a thread pool? Many mostly idle connections, where async I/O holds thousands of waits without a thread each. Keep pools for CPU work and blocking calls with no async form.
How do idle workers wait for the next task without spinning on the CPU? They block on the queue, typically a lock plus a condition variable, and each submit wakes a worker. A spin loop would burn a core doing nothing.

What you can say

A thread pool is a fixed set of worker threads that take tasks from a shared queue, so you submit work instead of starting a new thread for it.
An idle worker picks up a task, runs it, then goes back to the queue for the next one, and the workers live as long as the program does.
Reusing them skips creating and destroying a thread per task, which costs tens of microseconds each time and adds up fast under load.
The pool also caps concurrency, so a burst of ten thousand requests waits in the queue instead of launching ten thousand threads that eat memory and thrash the scheduler.
The tradeoff is sizing, because too few workers leave tasks waiting and too many just fight over cores.
For compute I'd start near the core count, and for I/O-bound work I'd go higher, since those workers spend much of their time blocked.

Weak answers to avoid

Says a pool just makes code faster A pool saves creation cost and caps concurrency. It does not make one task run faster, and more threads than cores can slow CPU work down.
Covers creation cost, skips the concurrency cap That is half the answer. Say the pool limits how many threads are alive, so bursts wait in the queue instead of exhausting memory.
Picks a pool size with no reasoning Sizing depends on the work. Tie it to core count for compute and explain why I/O-bound work can use more threads than cores.
Treats the queue as free The queue absorbs bursts, but an unbounded one moves the overload into memory. Mention bounding it or rejecting work when it fills.

Interview lens

Likely follow-ups, what you can say, and the weak answers to avoid.

Want a quick review of the fundamentals? See the Concurrency & Multithreading cheatsheet.

← Back to all Concurrency & Multithreading questions

Pro · $10/mo

47 of 54 Concurrency & Multithreading answers are in Pro.

Full answers, code samples, and AI explanations that go simpler or deeper. Cancel anytime.

Full answers + code
AI explanations, simpler or deeper
1,000 AI credits / month
Cancel anytime

Get Pro → See plans & pricing →