面试必问：ThreadLocal 到底有哪些缺点？答不好直接挂！
有一阵子，面试官们都跟中了 ThreadLocal 的毒一样——但凡简历里写个“多线程”三字，十有八九要你现场来一段 ThreadLocal。仿佛这东西会了就是并发高工，不会就等着被一纸拒信喽。话虽说得夸张，但说到 ThreadLocal 的“坑”，那是真数不胜数。今天我就跟大家唠唠，ThreadLocal 问题是怎么把我头发一点点薅没的。
写代码时的小天真
一开始，ThreadLocal 在我眼里就是大救星。
- 跨方法却不好传递的数据？
- 担心线程安全？
- 想偷懒让线程各玩各的？
——全都交给 ThreadLocal！锅都不用刷，数据妥妥“封印”在线程里。
写法更是潇洒：
private static final ThreadLocal<User> localUser = new ThreadLocal<>();
void setUser(User user) {
localUser.set(user);
}
// ……
User user = localUser.get();
帅就一个字。但爽不过三天，ThreadLocal 很快就让我吃土了。
踩坑瞬间
下面这些场面，哪个不是噩梦初醒：
-
内存泄漏了！
某服务上线两周，内存慢慢被“吞”，线程越多越刺激。原来用的线程池+ThreadLocal，set 之后懒得 remove，任务一执行完就没人管了，留在线程里的对象再大点，JVM 都要自己骂街。 -
数据“回魂”
以为用完 ThreadLocal 数据一定会消失，结果线程池里上个请求的脏数据下一波客户接着用，差点被领导来个全员警告。 -
调试像玩迷宫
Trace ID、用户信息啥的全靠 ThreadLocal 传，debug 时你根本搞不明白这个线程里的数据哪来的，stacktrace 跟AI生成的一样谜。 -
并发量大就搞笑
一上高并发，内存里堆满 ThreadLocalMap，老哥本来想加个缓存优化，最后发现比直接用 Map 还慢。
ThreadLocal 那些见不得人的“缺点”
理一下，问面试官其实可以从这几个角度说：
| 缺点 | 听起来很“挂人” |
|---|---|
| 内存泄漏风险 | 特别是在线程池场景，不 remove 会挂 |
| 数据残留 | 跨请求的数据没清理，新线程重用出锅 |
| 难以追踪 | 调试、排查复杂，数据来路成谜 |
| 设计复杂 | 滥用容易设计成“全局变量”地狱 |
| 不适合异步 | 新线程拿不到 ThreadLocal 数据 |
| 隐式依赖 | 代码“耦合”且不可见，易踩坑 |
你要是能把这里头故事随口一说，比死记 API 效果好了十条街。
经验启示
千言万语，最后还是给自己写两行 memo 吧：
- ThreadLocal 能不用就不用。除了确实需要隔离线程数据比如日志 trace，否则别碰。
- 如果用，一定写好 remove，比如 finally 块或者 Spring 的拦截器清理，不要手欠漏写。
- 在线程池里用 ThreadLocal，一定小心数据残留，不要给自己挖坑。
- 真要全局数据、上下文优雅传递？优先参数传递，其次才想 ThreadLocal，别觉得自己架构师附体。
- 面试答：别死背，结合实际工作、踩的坑讲例子，面试官会觉得你真干过。
这 ThreadLocal，用的时候感觉像开了挂，用崩的时候自己才能体会啥叫“挂"
随时随地看视频
