Learn the vocabulary of a fixed set of reusable worker threads pulling tasks off a shared queue.
0 / 5 completed
1 / 5
At standup, a dev mentions a fixed set of worker threads created once at startup, pulling tasks off a shared queue, rather than the server spawning a brand-new thread for every single incoming request. What is this pattern called?
A thread pool is a fixed set of worker threads created once at startup that pull tasks off a shared queue, reusing the same threads across many requests instead of paying the cost of creating and tearing down a brand-new thread for every single one. A deadlock is an unrelated failure mode about threads blocking each other, not about how threads are provisioned. This reuse is what makes a thread pool dramatically cheaper under high request volume than spawning a thread per request.
2 / 5
During a design review, the team wants the pool's size capped at a fixed maximum, with excess tasks queued rather than spawning unbounded additional threads under a traffic spike. Which capability supports this?
A bounded thread pool with a fixed maximum size, backed by a task queue that absorbs any burst beyond that capacity, keeps memory and CPU usage predictable even under a sudden traffic spike, since excess tasks simply wait in the queue instead of triggering more threads than the system can handle. An unbounded pool that spawns a new thread per task risks exhausting memory or CPU entirely once traffic spikes hard enough. This bounded-size-plus-queue design is the standard way to keep a thread pool's resource usage under control.
3 / 5
In a code review, a dev notices every single task submitted to the pool blocks on a slow downstream call, and once enough tasks pile up, the pool's threads are all occupied waiting on that same slow dependency. What does this represent?
This is thread pool starvation, where every worker ends up blocked on the same slow dependency, leaving no thread free to pick up any other queued task, even ones that have nothing to do with the slow call. A cache eviction policy is an unrelated concept about discarded cache entries. This starvation scenario is exactly why a slow downstream dependency needs its own timeout, or its own isolated pool, so it can't monopolize every worker thread in the whole system.
4 / 5
An incident report shows the entire API became unresponsive because a single slow downstream dependency caused enough tasks to block that every thread in the shared pool was eventually occupied waiting on it, starving unrelated requests. What practice would prevent this?
Isolating the slow dependency's calls behind their own dedicated thread pool, a pattern often called a bulkhead, ensures that dependency's blocking can only exhaust its own smaller pool rather than starving every worker the rest of the API relies on. Continuing to route everything through one shared pool with no isolation is exactly what let one slow dependency take down the entire API in this incident. This isolation is a standard resilience pattern for any system where different downstream calls have very different latency and failure characteristics.
5 / 5
During a PR review, a teammate asks why the team sizes the thread pool carefully and monitors its queue depth instead of just setting the maximum size as high as possible to avoid ever queuing a task. What is the reasoning?
An oversized pool can spin up more threads than the CPU can actually schedule efficiently, or more concurrent calls than a downstream dependency can absorb, so simply maximizing the pool's size just shifts the bottleneck elsewhere instead of eliminating it. A carefully sized pool paired with monitored queue depth lets the team see contention building up and react, whether by scaling out, adding a bulkhead, or tuning the size, before it turns into an outage. The tradeoff is the ongoing tuning effort of finding and re-validating the right pool size as traffic patterns and downstream dependencies change over time.
What does the "Thread Pool Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to thread pool vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.