The Mutex Club: Thread Pools: Fixed, Cached, and Beyond
The Mutex Club: Thread Pools: Fixed, Cached, and Beyond
dgtalbug
- 2 min read

The Mutex Club: Thread Pools: Fixed, Cached, and Beyond

On this page
Introduction

Ready to stop treating rejected tasks like the awkward leftovers under the fridge? Your ThreadPoolExecutor isn’t broken—it’s telling you it needs a strategy.

Key Insights

ThreadPoolExecutor Essentials

  • Core vs. Maximum Threads: Picture a kitchen brigade—line cooks (core threads) handle routine orders, sous-chefs (max threads) jump in when the dinner rush hits.
  • Task Queue: That’s your ticket line. When cooks are busy, orders wait in line—until the queue is full and the bouncer shows them the door.
  • RejectedExecutionHandler: The bouncer. Decides what to do when there’s no more room. Abandon orders, re-route them, or make VIP patrons (caller threads) handle their own dishes.

Fixed vs. Cached Pools

  • Fixed Pools: A reliable sedan with a capped passenger count. Perfect when your load is predictable.
  • Cached Pools: A convertible that auto-expands seating. Great for quick joyrides, but risky on marathon trips—you might run out of life vests.

Common Misunderstandings

  • Myth: Pools accept everything. False. Once threads and queue hit the limit, tasks get rejected—no magic fallback.
  • Myth: Cached is always faster. Not under sustained pressure. Unbounded threads can doom your heap.
  • Myth: RejectedExecutionHandler is just for logs. Nope. It’s your backstop for real-world retries, alerts, or offloading to a message broker.
  • Custom Pools in Microservices: Tailor thread counts, queue sizes, and rejection policies per service to avoid global meltdowns.
  • Dynamic Instrumentation: Metrics on active threads, queue depth, and rejected counts drive auto-tuning—so you’re not flying blind.
  • Resilient Rejection Handling: Route overflow to secondary queues, durable stores, or real-time dashboards to keep SLAs intact.

Real-World Examples

Rate-Limited Web Crawler

  • Use a fixed-size pool (e.g., 100 threads) and a bounded queue.
  • On rejection, push URLs into Kafka for a later round—no lost links, no downtime.

Black Friday Order Processor

  • Custom pool with CallerRunsPolicy to throttle callers—urgent orders swap to the caller thread, automatically slowing intake.
  • For VIP orders, implement a priority rejection handler that moves high-value tasks to a failover queue.

Could your thread pool BE any more rejected? Only if you ignore rejection handling! What’s your most creative RejectedExecutionHandler hack?

References:

The Mutex Club RejectedExecutionHandler in Thread Pools