问题的答案。
ThreadLocal在Java 1.2中引入，用于提供线程局部变量而无需方法参数传递。实现使用存储在每个Thread对象中的ThreadLocalMap，其中映射的键是对ThreadLocal实例的WeakReference包装。关键的设计缺陷在于映射的Entry类通过强引用字段持有值，这意味着即使WeakReference键被垃圾回收清除，值对象仍然被存活的Thread强引用。这在线程池中创建了内存泄漏，因为线程无限期存活，累积孤立值。如果不显式调用remove()，过时的条目可能会在线程的生命周期内持续存在，有效地将值对象固定在内存中。
生活中的情况
一个金融交易平台利用ThreadLocal存储每个请求的市场数据快照，通过深层嵌套的服务调用。在使用固定的ThreadPoolExecutor时，该应用程序在生产负载下每12小时神秘耗尽堆内存。堆转储显示Thread对象通过ThreadLocalMap条目保留了大型**byte[]**数组，并且键为null，导致服务降级。
解决方案1：手动try-finally卫生
开发人员试图通过try-finally块包裹每个入口点，调用remove()。
解决方案2：具有自动清理的线程池包装
工程师考虑包装Runnable任务以捕获并在执行后清除所有ThreadLocals。
解决方案3：请求范围的依赖注入
将上下文存储迁移到Spring的RequestScope beans，具有自动代理清理。
选择的解决方案和结果
团队选择了一种混合方法，使用Servlet Filter和try-finally确保为所有请求范围的ThreadLocals调用remove()。这提供了集中执行而不进行架构重构的方式，防止了积累，即使在异常期间。堆保留量下降了90%，消除了强制重启周期，并满足了99.99%的正常运行时间SLA。持续监控确认在几周的运营中堆使用情况稳定。
候选人常常忽略的内容
为什么ThreadLocalMap使用WeakReference作为键，但对值使用强引用，而不是同时都使用弱引用？
如果值通过WeakReference持有，垃圾回收器可以在ThreadLocal键仍然可达时回收值对象。这将导致后续的get()调用意外返回null，违反了线程设置的值在该线程执行期间保持稳定的期望。强引用确保了值的稳定性，而弱键允许在ThreadLocal实例本身不再被应用逻辑引用时将条目标记为过时。
InheritableThreadLocal如何将值传播到子线程，并且这在线程池环境中引入了什么独特的内存泄漏风险？
InheritableThreadLocal在通过Thread.init()初始化Thread时，将父线程的条目复制到子线程的inheritableThreadLocals映射中。这种浅复制在线程创建时发生，这意味着线程池——其中线程被创建一次并重用——从偶然创建它的父线程继承值。如果该父线程持有大型上下文，池中的每个线程都将永远保留这些引用，可能在处理不同用户任务时泄漏敏感数据。
expungeStaleEntry方法在清理过程中重新哈希行为的目的是什么，为什么简单地将过时槽置为null会破坏映射的不变性？
ThreadLocalMap使用开放寻址和线性探测解决冲突。当移除过时条目时，简单地将其槽设为null会破坏因冲突而存储在其后的条目的探测链。expungeStaleEntry方法重新哈希探测序列中的所有后续条目，直到遇到一个null槽，将它们重新定位到正确的位置。如果没有这种重新哈希，对这些移位条目的查找操作将在null槽处过早终止，错误地返回null，尽管条目在表的后面仍然存在。