When Your Java Framework's Thread Pool Hides a Memory Leak: 3 Silent Killers to Fix

A Java application that runs fine for days suddenly starts throwing OutOfMemoryErrors at 3 AM. The heap dump shows a billion char[] instances. Your first guess? A static collection gone rogue. But sometimes the real culprit is the thread pool—the one your framework handed you on a silver platter.

Thread pools are a cornerstone of modern Java frameworks. Spring Boot's @Async, Tomcat's request processing, Netty's event loops—they all rely on pools of reusable threads. The problem is, these pools can hide memory leaks in plain sight. A thread that never dies accumulates thread-local data. Uncaught exceptions leave tasks stranded in queues. Framework lifecycle hooks leak classloaders. And since thread pools are 'optimized' by default, you might not notice the slow bleed until production crashes.

Where Thread Pool Leaks Hit in Real Work

Production incident at 3 AM

The alert came in at 2:47 AM: a payment-processing service was returning 503s from every node. I'd been on-call for a framework migration three weeks earlier—moved the team from a hand-rolled executor to a shiny `ForkJoinPool` variant. Seemed like a clear win. The first heap dump told a different story: thousands of `LinkedBlockingQueue` entries filled with partially processed `Runnable` objects, each holding a reference chain back to an HTTP client session. The thread pool wasn't the leak—it was the staging ground. Every task queued but never executed consumed heap because the pool's max size had been hit, and the saturation policy simply… blocked the caller. Blocked callers don't release their references. One thread blocked for five seconds pinned a 200KB session object. Multiply by 800 blocked threads across the cluster. You do the math—that's a 160MB silo of unreleasable memory that GC can't touch. We were shedding load by crashing.

The char[] heap dump mystery

Open the dominator tree in Eclipse Memory Analyzer and you'll see it: `char[]` arrays consuming 40% of retained heap, all reachable from a single `ForkJoinWorkerThread`. The thread itself looked innocent—idle, waiting on a `CountDownLatch`. But the latch was held by a future that would never complete because the upstream database pool was exhausted. That future's result—a massive JSON payload—was still referenced in the thread's stack. The payload wasn't leaked intentionally; it was abandoned. Thread pools don't clean up abandoned futures. They just hold the reference until the thread dies. And threads in a managed pool rarely die. This is the silent killer most devs miss: a thread pool doesn't create memory leaks—it preserves them long past their useful life. Every uncompleted `CompletableFuture` becomes a fossil in your heap, immortalized by the pool's thread lifecycle.

One engineer on our team insisted we just increase heap size. He was wrong—doubling heap just postponed the crash by six hours. The pattern repeats: object A holds reference B, B chains to C, and somewhere in that chain a thread-pool thread holds the root. The pool acts like a garbage collector's worst enemy—it hands out immortal roots to every halfway-scheduled task. You can't outrun this with more memory.

How a single thread can leak megabytes

Single thread. One `ThreadLocal` entry. Five-line oversight. Leaked 2.3 GB over eight hours. Here's the anatomy: a worker thread from the pool processes a request, calls a third-party SDK that stashes an authentication token in a `ThreadLocal`. Request finishes—SDK never calls `remove()`. Thread returns to pool, idle but still clutching that token. Next request on the same thread pulls the stale token, triggers a retry, which allocates a buffer, which the SDK attaches to the same `ThreadLocal`—now a chain grows. Every cycle doubles the retained size. A single thread in a 50-thread pool can accumulate tens of megabytes before anyone notices. The catch is that monitoring tools report heap usage as 'normal' because the leak is spread across threads—no single object is huge, but the aggregate bleeds out over hours.

'We restarted every twelve hours for six months before someone opened a thread dump at the right moment.'

— Lead SRE, mid-size fintech, recounting a ThreadLocal leak that survived three sprint cycles

Production incident review revealed the fix: override the pool's `afterExecute()` to clear `ThreadLocal` values. Took forty-five minutes to implement. The root irony? The team had intentionally chosen a cached thread pool over a fixed pool to 'handle load spikes better.' That choice gave threads longer lifetimes—which turned a five-minute leak into a twelve-hour catastrophe. Sometimes the optimization you choose is exactly what sharpens the knife against you. Keep a copy of your thread dump from the incident—it becomes the single best training artifact for every junior dev who asks 'Why can't we just reuse threads indefinitely?'

What Most Devs Get Wrong About Thread Pools and Memory

Thread reuse vs. thread-local accumulation

The core misunderstanding runs deeper than most devs realize. A thread pool doesn't destroy threads after each task—that's the whole point of reuse. But reuse means every ThreadLocal value you set in one request sticks around for the next task on that same thread. I've debugged a service where a logging filter stuffed a massive MDC context map into a thread-local, then never cleared it. After 10,000 requests, that single thread held onto megabytes of stale user IDs, request traces, and session data. The pool had 50 threads. You do the math. Most teams assume thread-locals are cleaned up automatically—they're not. Ever. The JVM can't reach into an active thread's stack and say "that reference is garbage now." Not while the thread's still alive in the pool.

The myth of 'bounded pool = safe'

Bounded thread pools cap concurrency, not memory. That's the trick. You can set maxPoolSize=10 and still leak 2 GB through thread-locals—the bound only limits how many threads run simultaneously, not how much heap each one drags along. The real danger? A bounded pool actually accelerates the leak. Fewer threads means each one processes more tasks, accumulating more thread-local cruft per thread over its lifetime. We saw this firsthand: a team capped their pool at 8 threads to prevent overload, and the leak sped up. The heap grew 30% faster than before. A bounded pool just concentrates the poison.

'Thread pools don't leak memory. Applications leak memory onto threads that happen to be pooled.' — senior engineer after a 3-day outage postmortem

— That quote isn't from a conference talk. It's from a Slack thread at 2 AM after rolling back a release.

Reality check: name the frameworks owner or stop.

Why GC can't clean thread-stack-referenced objects

The garbage collector follows roots. Thread stacks are GC roots. Every object referenced from a thread's local variables, operand stack, or thread-local map is considered alive—full stop. The GC doesn't care that your Runnable finished executing. The thread-local still holds a reference from the thread object itself, and that thread is part of the pool's core set, never destroyed. So those objects sit in old-gen, surviving minor GC after minor GC, until you hit a full GC pause or—more likely—an OutOfMemoryError that takes down the pod. The catch is that monitoring usually shows "normal" heap usage until it's not. The JVM's tenuring threshold works against you here: objects that should die young get promoted because the thread-local keeps them reachable. One concreted example: a team at my last company stored an entire XML document in a thread-local for request validation. Each one was 200 KB. After 500 requests per thread, that's 100 MB per thread in old-gen. The GC ran full collections every 12 minutes. The pod died every 90. And the thread pool was "bounded" at 20 threads. Sounds safe, right? Wrong order.

Patterns That Usually Work—Until They Don't

Fixed Thread Pool with Bounded Queue

You set newFixedThreadPool(10) with a bounded queue of 100. Smart—theoretically. This pattern works beautifully under normal load: tasks pile up, workers drain them, memory stays flat. The catch? One rogue task that throws an exception and never returns. I've debugged a production incident where a third-party SDK call went into an infinite retry loop inside a task—the pool's queue grew past its bound, rejected execution, and the rejection handler silently discarded every subsequent task. Memory didn't spike; it slowly bloated because each retry allocated new HTTP client buffers, and the rejected tasks' parent callers kept retrying upstream. That's a 14-hour drift before anyone noticed.

What usually breaks first is the assumption that a bounded queue protects you. It does—from unbounded queue growth. But it doesn't protect against tasks that leak per-execution state. A bounded queue with long-lived threads: the threads themselves hold references to thread-locals, and if those locals reference the task's context (a user session, a database connection wrapper), the entire chain stays alive until the thread pool shuts down. Not a crash—a slow, quiet creep. The fix we shipped: wrap every task in a try-finally that clears thread-locals and enforces a per-task timeout, even if the executor's own termination policy seems sufficient. That sounds fine until you hit a framework that spawns its own internal threads and doesn't expose them to your timeout logic.

Thread-Local Cleanup in Finally Blocks

Every blog says "clean up thread-locals in finally blocks." They're right—mostly. Yet I've watched teams implement this perfectly for their own code, then integrate a popular web framework that reuses threads across requests. The framework's filter chain sets a request-scoped thread-local—your finally block clears it. Great. But what about the framework's internal ThreadLocal for security context? You don't own that code. If that context holds a reference to a user object that keeps a cached classloader (think Jasper reports, dynamic Groovy compilation), the thread pool's reused threads pin that classloader forever. That's a classloader leak masquerading as a thread-local problem.

'We added thread-local cleanup in all our service methods. The heap still grew. Turned out it was the framework's own ThreadLocal we couldn't touch.'

— lead engineer, after a three-week chase

The hard truth: thread-local cleanup in finally blocks is necessary but not sufficient. The patterns fail when you don't control the entire thread lifecycle. Consider ForkJoinPool.commonPool—shared across your entire JVM. One misbehaving library that spawns a fiber or forks a task that captures a thread-local? That reference leaks into the common pool, and no finally block in your code helps. The workaround—never assume a framework's executors are safe; wrap them in a custom pool with explicit purge logic—adds overhead but prevents the silent drift.

Framework-Provided Executors (e.g., ForkJoinPool.commonPool)

Framework executors like ForkJoinPool.commonPool() feel like a gift: pre-tuned, shared, efficient. Until they aren't. The common pool is a static singleton—every module, every library, every plugin uses it. Drop a long-running task in there (a blocking queue poll with a 30-second timeout), and you starve the pool of threads. Starvation doesn't leak memory directly. But when those threads block, the pool creates new compensation threads via ForkJoinPool.ManagedBlocker, and those new threads inherit whatever thread-local state the blocking task had. Suddenly, a pattern that should work (let the framework manage parallelism) leaks references across unrelated components. One team I worked with saw heap growth whenever their reporting module ran—because the reporting thread blocked on a database call, the pool spawned a new thread that picked up a stale HTTP session from the thread-local of the blocking thread. That session held a 5MB parse tree. Repeat that 50 times and you've got 250MB of leaked memory before the reporting job finishes.

The pattern usually works—until your workload mixes short-lived CPU tasks with occasional blocking operations. Then it fails catastrophically, and the monitoring shows "normal" thread counts because the pool hides the compensation threads. You're left wondering why the heap keeps growing under steady load. We fixed this by isolating long-running work into a dedicated executor, never the common pool. That's not elegant—it's defensive. But the alternative is a memory leak that only appears under production concurrency, and those are the worst to chase.

Anti-Patterns That Make Teams Revert to Simpler Code

Cached thread pools for all async tasks

Looks harmless on paper. Executors.newCachedThreadPool() — one line, infinite scaling, perfect for bursty workloads. Except it never stops scaling. A cached pool with no upper bound creates threads as fast as tasks arrive, and it keeps every idle thread alive for 60 seconds by default. That sounds fine until a spike hits your service; suddenly you've got 800 threads holding stack frames, each carrying its own ThreadLocal baggage, and the JVM heap looks like a balloon two minutes before popping. I have seen a team push this pattern into production thinking 'it's just async logging.' The OOM killer disagreed. The fix wasn't complex — a bounded LinkedBlockingQueue with a sane max pool size — but the revert cost them a full sprint. Nobody wants to go back to synchronous request-handling when they've tasted async speed, yet that's exactly what they did: ripped out the pool, fell back to inline execution, and shipped hotfixes at 3 AM.

Inheriting thread locals across executors

Here's the trap most devs miss: InheritableThreadLocal. You write a parent thread that sets a user context, spawns a child task, and the child inherits that context automatically. Beautiful — until the child thread lives longer than the parent. Then you've got stale authentication tokens, outdated tenant IDs, and object references the GC can't touch because the thread still holds them. The pattern feels like magic for transaction propagation, but it's a leak disguised as convenience. Most teams skip this: thread locals in a pool outlive the original request by minutes or hours. One e-commerce team I worked with traced a 12% heap growth to a single InheritableThreadLocal holding a Map of session data. Their rollback was brutal — they replaced the entire async pipeline with a synchronous queue. The catch? Throughput dropped 40%. That said, the memory graph flattened overnight.

What usually breaks first is the developer's intuition: 'But the thread finishes its task, right?' Wrong. In a pool, the thread returns to the pool — it never dies. The ThreadLocal stays attached like a barnacle. You need remove() in a finally block, or better yet, use TransmittableThreadLocal from the Alibaba toolkit. But teams rarely refactor until the pager goes off. One rhetorical question: how many hours would you trade to avoid a 3 AM rollback?

Odd bit about frameworks: the dull step fails first.

Using ThreadLocal without remove() in long-running threads

Short-lived pools mask this crime. A request thread that dies after 200 milliseconds drops its locals on GC. But put that same code in a ScheduledThreadPoolExecutor with threads that live for days? The leak compounds like interest on bad debt. I've debugged a Spring Boot application where a RestTemplate interceptor stored a ThreadLocal MDC context — and the scheduler pool held 16 threads. Each thread accumulated a chain of LinkedHashMap entries from failed API calls. After 72 hours, each thread carried 40 MB of orphaned diagnostic data. The team reverted to a simpler @Async with SimpleAsyncTaskExecutor — a pattern they had abandoned three months earlier because it was 'too primitive.' Primitive won. They lost the performance gain but regained stability. The trade-off stung: 15% more latency in exchange for zero unexplained OOMs.

'The thread pool isn't leaking memory — the thread itself is a memory hoarder, and nobody cleaned its closets.'

— senior engineer, after 18 hours of heap dump analysis

The Long-Term Cost: Drift, Monitoring, and Classloader Leaks

Classloader leaks in application servers

You restart Tomcat, the heap drops fifty percent, and everyone calls it a win. I've seen teams do this for months—like resetting a leaking bucket and pretending the hole isn't there. Classloader leaks are the most insidious form of thread pool memory waste because the garbage collector can't touch them. The framework's classloader holds references to every thread-local object that your thread pool ever touched, and those objects persist until the entire web app is redeployed. Tomcat's loader hierarchy means a single ThreadLocal map in a pooled worker can pin megabytes of per-request state. Honest question: how often does your team actually profile classloader retention? Most skip it until the OOM kills production at 3 AM on a Sunday.

Thread pool metrics that drift over time

The catch is that these leaks don't spike—they drift. Your jstack looks clean Monday. By Thursday the old gen occupancy climbs twelve percent. By the following Tuesday you see that telltale sawtooth in GC logs: collections every two minutes instead of twelve. But here's where most monitoring falls short—you track pool size and queue depth, not what those threads are holding. That gap is where the leak hides. A thread finishes its task but keeps a reference to a HttpSession or a cached query plan. One thread holds 200 KB. Fifty idle threads hold ten megabytes. Over three weeks that's a slow bleed that metrics like "memory used" will show—but why won't be obvious unless you map thread-to-classloader relationships. Most teams miss this because they're watching the wrong dashboard.

Why restarting clears the leak but not the root cause

Restarting hides the evidence. The classloader gets thrown away, all those dangling references vanish, and the heap profile looks textbook again. That feels like a fix. It isn't. You haven't stopped the code that creates ThreadLocal values tied to a shared thread pool—you just pressed the reset button on its accumulating damage. The pattern usually looks like this: a utility class grabs a thread-local DataSource or SecurityContext, the thread returns to the pool but keeps the map entry, and the entry's key is a class from the deployed app. Once that web app is undeployed—or when the classloader references become orphaned—those threads carry dead class references forever. We fixed this once by adding a dedicated finally block that nulled out every ThreadLocal after request completion. It felt like overkill. It wasn't.

'Three weeks of heap drift, an emergency restart, and zero root cause analysis—that's not maintenance, that's a gambling habit.'

— Senior engineer after tracing a classloader leak to a forgotten executor wrapper

The real cost isn't the memory—it's the drift in your monitoring baselines. Once you accept weekly restarts as normal, you stop looking for the leak. You tune GC flags instead of fixing the reference chain. You set lower heap thresholds instead of auditing thread pool lifecycle. And the next time someone deploys a new microservice with a shared executor, the pattern repeats. What to fix first: audit every ThreadLocal usage in classes that run inside pooled threads. If you can't guarantee cleanup in a finally clause, don't use thread locals at all. Use context passing instead. That hurts less than a five-hour war room session to diagnose why your Tomcat farm drifts ten percent heap every week.

When the Thread Pool Isn't the Problem—and What Else to Check

Large Message Queues vs. Thread Pool Leaks

You're staring at a heap dump. Threads are stuck, memory is rising, and every instinct screams thread pool bug. Sometimes it's not. I once spent three days chasing a phantom thread leak only to find a LinkedBlockingQueue that had swallowed 800,000 unprocessed messages. The pool itself was healthy—workers grabbed tasks, completed them, went idle. But the producer was shoving data in faster than the consumer could drain. That backlog lives off-heap in the queue's internal node objects, and if your monitoring only watches thread count, you'll miss it. The giveaway? Threads stay in WAITING or TIMED_WAITING, not BLOCKED. They're idle because the queue is fat, not because the pool is broken.

Most teams skip this: check your queue depth before blaming thread configuration. A pattern I've fixed repeatedly is pairing a bounded queue with a dynamic pool—the pool expands, the queue never fills, but the backlog moves to database tables or message broker disks. That's just shifting the leak. The real fix is backpressure: throttle producers when queue size crosses a threshold. It's ugly code but it stops the silent growth. Without it, you'll keep resizing pools and wondering why your JVM has a 4 GB heap for 12 threads.

Direct Buffer Memory Allocated Off-Heap

Here's a favorite trap. Your heap looks fine—GC logs show normal collections, young gen is stable. Yet the JVM process memory climbs relentlessly toward the OS limit. You restart the thread pool, memory stays high. That's the signature of ByteBuffer.allocateDirect() leaking in pooled threads. Direct buffers live outside the heap, invisible to standard profilers. A common pattern in Netty or gRPC-based services: each request allocates a direct buffer in a worker thread, the thread is reused, but the buffer reference escapes into a callback that never releases it. The pool doesn't leak—the native memory does.

What usually breaks first is the OS OOM killer, not your JVM. I've seen a twelve-hour investigation collapse into a single -XX:MaxDirectMemorySize flag that exposed the real leak. The fix is boring but effective: wrap all direct buffer allocations in try-with-resources, or use reference queues to track uncleaned buffers. One rhetorical question for your next post-mortem: "Could our thread pool be healthy while our native memory bleeds?" Yes, and it's worse than a heap leak because it takes down the whole box—not just the JVM.

Reality check: name the frameworks owner or stop.

'We assumed the thread pool was the culprit. Three weeks of profiling later, we found 2 GB of unreleased direct buffers in a Netty pipeline that never closed its ByteBufs.'

— Senior engineer, fintech company, after a production outage

Native Memory Leaks from JNI Calls

Thread pools wrap JNI calls—oh, the trouble that follows. A pooled thread calls a native library via JNI; that library mallocs memory internally, forgets to free it, and the thread returns to the pool. The native memory grows with each call, but the JVM heap stays flat. Standard tools like VisualVM show nothing. The thread pool looks innocent—threads cycle in and out of RUNNABLE, no blocked workers, queue depth is zero. Yet pmap reveals anonymous memory regions expanding by megabytes per minute. This isn't a Java leak. It's a C leak hiding behind your framework.

The catch is that JNI leaks are hard to reproduce outside production. Load tests with smaller data sets won't trigger them. I've debugged this exact scenario: a Spring Boot service using a JNI-based image processing library inside a fixed thread pool. The library leaked 12 bytes per invocation—trivial per call, catastrophic at 10,000 requests per minute. The fix required wrapping each native call in a separate, short-lived thread that could be killed after execution, releasing leaked memory via process-level cleanup. Ugly? Yes. But it stopped the drift. If your thread pool memory leak vanishes in staging but kills production, suspect JNI first—then suspect the thread pool second. Honestly, suspect JNI first.

Frequently Asked Questions About Thread Pool Memory Leaks

Can virtual threads solve thread pool leaks?

Short answer: not by themselves. Virtual threads (Project Loom) eliminate the *stack* cost per thread, which is huge — you can have millions without OOM from thread count. But the memory leaks we're talking about here? They live in objects pinned to tasks: thread-locals, cached data structures, open resources attached to a carrier thread. Virtual threads reuse carrier threads under the hood, so a careless ThreadLocal map still grows unbounded. I fixed a case where a legacy library wrote request-scoped metrics into a static InheritableThreadLocal — virtual threads ran fine for hours, then hit metaspace exhaustion. You'll still need cleanup logic. The catch is: virtual threads make the pool *invisible*, so devs stop thinking about it entirely. That's dangerous.

How to detect a thread-local leak with a heap dump?

Most teams skip this: you open the dump in Eclipse MAT or VisualVM, run the OQL query SELECT * FROM java.lang.ThreadLocal, then expand the table field. What you're hunting — thread-local maps whose keys are WeakReference objects that never got cleared. A healthy thread-local map has one to five entries. I've seen dumps with 4,000 entries per worker thread — all stale SimpleDateFormat wrappers from a logging adapter. The pitfall: you look at the Thread objects first. Wrong order. Look at java.lang.ThreadLocal$ThreadLocalMap instances sorted by size. Then walk up to the thread that owns it. That's where the leak's parent lives — often a long-lived pool thread that processed a thousand requests and never retired its locals. One team we consulted had a thread-local holding a reference to a 40MB XML schema object. Per thread. In a 200-thread pool. You do the math.

Should I use ThreadPoolExecutor with a rejection policy?

Yes — but pick the policy based on the memory profile, not just throughput. CallerRunsPolicy feels safe; it throttles the producer. However, if the producer thread is an HTTP worker that holds a large request body in memory, you've just moved the leak to the calling thread. DiscardOldestPolicy drops the head of the queue — sounds fine until that head holds a database connection reference that never closes. I once saw a system where DiscardOldestPolicy silently swallowed a task that held a transactional context, leaving the underlying connection in a half-committed state. Memory didn't spike; connection pool exhaustion did. The pragmatic move: AbortPolicy with a circuit breaker upstream. You take the exception, drop the request fast, and log — the memory stays clean. That hurts throughput, but a crash hurts worse.

“We replaced a cached thread pool with a fixed pool and rejection handler — memory dropped 30%, but latency spiked. We'd traded one leak for a deadline miss.”

— Senior engineer, high-frequency trading firm, after a postmortem I attended

The trade-off is real: a rejection policy protects heap but shifts pressure to queue sizing and response times. What to fix first: measure your queue depth under peak load. If tasks pile up faster than they drain, no policy saves you — the queue itself becomes a memory sink. Set maximumPoolSize high enough that rejection rarely fires, then instrument the beforeExecute and afterExecute hooks to clear thread-locals. That single change fixed 80% of the thread-pool leaks I've seen in production. Start there.

What to Fix First: A Summary and Next Steps

Audit your thread locals with remove()

Start here—thread locals are the single most common source of thread pool memory leaks I've debugged. Every ThreadLocal you set inside a pooled thread lives as long as that thread lives. And in an application server? That thread may never die. The fix is mechanical but brutally easy to skip: call remove() in a finally block. Not in a try-with-resources. Not at the end of a happy path. In the finally. I watched a team lose two sprints because a security context ThreadLocal held a reference to a 2MB user object—times 200 idle threads. That's 400MB of reachable garbage the GC can't touch. Audit every single ThreadLocal.set() call in your codebase. If the lifecycle doesn't perfectly match a request boundary, it's a ticking bomb.

Monitor active thread count vs. queue depth

Most teams watch heap usage—which often looks fine until Tuesday at 3 PM when everything seizes. Try a different signal: active thread count against queue depth. A growing queue with constant active threads? Likely a leak in task objects pinned by thread locals. A shrinking queue with rising active threads? You've got threads that never complete—blocked I/O, forgotten locks, or tasks that swallow interrupts. I set a simple rule at my last gig: alert when active threads stay at max for more than 30 seconds and queue depth exceeds 1,000. The false-positive rate was low; the real catches were haunting. The catch is—most monitoring tools track threads and queues separately. You need a paired metric or a custom gauge. Worth the ten lines of Micrometer config.

“We had a quarterly outage tied to a thread pool leak. The heap looked stable. The thread count looked stable. But the combination told the real story.”

— senior engineer at a mid-size payments platform, after moving to paired monitoring

Test with prolonged load and heap diff analysis

Unit tests won't catch this. Even integration tests with 100 requests rarely expose a thread-local leak. You need a soak test—sustained load for hours, coupled with a heap dump before and after. Diff those dumps. Look for objects of your own classes that grew in count but shouldn't have. A pattern I've seen three times: a request-scoped cache held by InheritableThreadLocal that accumulates entries over time. The heap diff shows 50,000 UserCacheEntry instances after 10,000 requests. Not obviously a leak—until you realize they never get released. Run the test, take two dumps, diff them, and look for your own packages. That's the shortest path to proof. Most teams skip this because heap dump analysis feels heavy. A one-time 20-minute investment beats a production war room at 2 AM.

What else to fix next? After these three changes, lock down your ThreadPoolExecutor rejection policy. Default AbortPolicy throws RejectedExecutionException silently—your leak just shifts from memory to lost tasks. Switch to CallerRunsPolicy during soak tests, or log every rejection with a stack trace. And for the love of production—add a beforeExecute and afterExecute hook to your executor that clears any thread-local state you control. Two method overrides. No dependencies. Instant safety net. Do that this week.