ThreadLocal本质是线程访问自身ThreadLocalMap的“钥匙”，数据实际存于Thread对象的threadLocals（ThreadLocalMap）中；其底层含三个核心：1.Thread内独有threadLocals字段；2.ThreadLocalMap为定制哈希表，固定长度、线性探测；3.Entry以弱引用作key、强引用作value。
回答 ThreadLocal 面试题拿高分，关键不是背定义，而是讲清“为什么这样设计”“用在哪、怎么用、为什么容易错”。面试官想看的是你是否真正理解它的运行逻辑和工程权衡，而不是复述 API 文档。
一、被问“什么是 ThreadLocal？”——别只说“线程私有变量”
直接点出本质：它不是 ThreadLocal 自己存数据，而是每个 Thread 对象内部自带一个 ThreadLocalMap，ThreadLocal 只是访问这个 map 的“钥匙”。
类比要贴切：就像公司给每位员工配了一把专属钥匙（ThreadLocal 实例），员工用这把钥匙打开自己工位下的抽屉柜（Thread.threadLocals），往里面放或取自己的东西（value），别人拿不到也打不开。
二、被问“底层原理？”——必须点出三个核心结构
1. Thread 类里的 threadLocals 字段：类型是 ThreadLocalMap，每个线程独有一份，是真正的数据容器。
2. ThreadLocalMap 是定制哈希表：不是 HashMap，没有扩容链表，用线性探测解决冲突，数组长度固定为 2 的幂。
3. Entry 是弱引用 Key + 强引用 Value：key 是 WeakReference
三、被问“为什么会有内存泄漏？”——要结合线程池场景讲透
重点不是“有泄漏”，而是“为什么在线程池里特别危险”：
• 普通线程执行完就销毁，threadLocals 整个 Map 也被回收；
• 线程池中的线程被复用，长期存活，如果忘了调 remove()，value 就一直卡在 map 里；
• key 已被 GC 成 null，value 却无法被回收，越积越多，最终 OOM。
所以结论要明确：remove() 不是可选项，是使用 ThreadLocal 的强制操作规范。
立即学习“Java免费学习笔记（深入）”；
四、被问“实际用过吗？”——用一个闭环场景体现工程判断力
举“用户上下文透传”例子，但要说清决策依据：
• 为什么不用方法参数传递？→ 避免污染 Service 层接口，解耦拦截器与业务逻辑；
• 为什么不用 InheritableThreadLocal？→ 子线程（如异步任务）不需要继承上下文，反而可能造成信息泄露；
• 怎么保证清理？→ 在过滤器/拦截器 finally 块中调用 remove()，或用 try-with-resources 封装；
• Spring 中类似实践？→ RequestContextHolder 就是基于 ThreadLocal 实现的，说明它是主流框架认可的方案。
