"How does ThreadLocal work, and why can it cause memory leaks?"
ThreadLocal is a staple concurrency question and the memory-leak angle specifically separates candidates who have debugged real heap dumps from those who have only read the javadoc. Thread-pool-based frameworks (Tomcat, Dubbo, Spring Web) turn ThreadLocal misuse into production memory leaks, so this matters in practice.
Explain the storage model: every Thread has a private ThreadLocalMap (thread.threadLocals). The map's key is the ThreadLocal instance itself, and the value is whatever you .set(). So data lives on the Thread object, not on ThreadLocal.
Explain weak reference on the key: ThreadLocalMap's Entry extends WeakReference<ThreadLocal>. If your code drops its last strong reference to the ThreadLocal instance, the GC reclaims it and the map's key becomes null, but the value is still strongly referenced.
Walk through the leak: in a thread-pool (like Tomcat request threads or Dubbo worker threads), threads live forever. If ThreadLocalMap keys go null but values remain, each request adds garbage until the heap fills up.
Note the partial cleanup: ThreadLocal.get() / set() opportunistically clean entries with null keys when they happen to probe those slots. But this is not guaranteed — an unlucky access pattern leaves the value uncollected.
State the fix: always call ThreadLocal.remove() after you're done with a request, ideally in a finally block. Spring's TransactionSynchronizationManager, SecurityContextHolder, and RequestContextHolder all follow this pattern internally.
ThreadLocal stores data per-thread without synchronization. The surprising part is where the data actually lives — not inside the ThreadLocal instance, but inside each Thread object. Every Thread has a private field threadLocals of type ThreadLocalMap. When you call threadLocal.set(value), Spring — sorry, ThreadLocal — looks up the current thread's map and stores an Entry where the key is the ThreadLocal instance itself and the value is whatever you passed. This design means two threads calling .get() on the same ThreadLocal each hit their own map, so no contention. The memory leak comes from the Entry's design. Entry extends WeakReference<ThreadLocal>, meaning the key is held weakly. If your code drops its last strong reference to the ThreadLocal (say it was a local variable or the class owning it got unloaded), GC will collect the ThreadLocal and the map's key becomes null. But the value is a strong field of the Entry, so it stays alive — and because the Thread is alive (especially in a thread pool where threads are reused for the lifetime of the JVM), the map and its zombie entries stay alive too. In a Tomcat or Dubbo server with hundreds of long-lived worker threads, every request that sets a ThreadLocal and forgets to remove it leaves a value in the map, and over time this produces a classic slow memory leak that manifests as gradual heap growth and eventual OOM. ThreadLocal.set() and .get() do opportunistic cleanup — when they hash-probe and happen to land on a slot with a null key, they discard it. But this cleanup is probabilistic and relies on probing, so you can't rely on it. The correct pattern is: try { threadLocal.set(x); ... use it ... } finally { threadLocal.remove(); } — always remove in a finally block. Frameworks you use every day follow this — Spring's TransactionSynchronizationManager, Spring Security's SecurityContextHolder, and Spring MVC's RequestContextHolder all remove in the filter/interceptor teardown phase.
Always draw the picture: Thread → ThreadLocalMap → Entry[key=WeakRef<ThreadLocal>, value=strong].
Call out thread pool reuse specifically — that's what turns a theoretical leak into a production outage.
The finally { remove(); } pattern is the memorable takeaway — make sure you say it.
If you get tripped up in the interview explaining weak vs strong references, HireMe AI can surface the exact Entry layout.
The value is what you actually want to retrieve; if it were weak, the first GC would clear it and .get() would return null, making ThreadLocal useless.
Yes, and additionally it copies values to child threads, so a leak can propagate. Use TransmittableThreadLocal from Alibaba for thread-pool scenarios needing inheritance.
Yes by design — each thread sees its own value, no synchronization needed. But the value object itself must be used safely if accessed across threads in any other way.
HireMe AI listens to your interview in real-time, detects questions, and generates instant answer suggestions — so you never freeze up again.
Try HireMe AI Free