ThreadLocal 残留数据引发的随机业务错乱

开发中为了传递上下文、存储登录用户信息、临时缓存参数，很多项目都会用到 ThreadLocal。使用起来很方便，不用反复传参，整个线程链路随时可以获取上下文数据。
但线上很多偶发的诡异问题，都是它悄悄造成的。最头疼的是这类问题没有固定复现逻辑，随机出现，测试环境几乎抓不到，只能靠线上日志慢慢溯源。
我之前遇到过用户偶尔串号、接口拿到别人数据、后台操作记录归属用户错乱的问题，排查了很久权限代码、登录逻辑、拦截器，最后才定位到是 ThreadLocal 未清理导致的脏数据残留。
Java Web 服务的线程都是线程池复用的，请求结束后线程不会销毁，会放回池子里等待下次复用。
很多人只用 set 存数据，请求结束不做 remove 清理。当下一次新请求拿到这个旧线程，线程内部还保留着上一次的上下文数据。
新请求没有重新覆盖赋值的情况下，代码会读取到旧线程残留的信息，直接造成数据混淆。
这种错乱非常隐蔽，完全取决于线程池是否复用线程。
服务刚重启时，线程都是全新的，基本不会出问题。服务运行时间越久，线程复用越频繁，脏数据概率越来越高。白天流量大、线程切换频繁，问题高发；夜间流量低，线程空闲重置，第二天又短暂恢复正常。
很多人因此误以为是服务器抖动、缓存异常，没人会第一时间怀疑上下文存储。
还有一个很容易踩的坑，是异常分支跳过清理代码。
大部分人会在接口正常结束的位置清理 ThreadLocal，但是一旦业务中途报错、抛出异常、手动 return，收尾代码直接跳过，清理逻辑根本执行不到。
异常场景越多，残留的脏线程越多，后续请求踩坑的概率就越大。长期积累下来，线上错乱问题越来越频繁。
团队开发中，滥用 ThreadLocal 静态变量的问题也很严重。
多个模块共用同一个静态线程变量，A模块存用户信息，B模块存业务参数，C模块不清理直接复用。不同业务的数据互相干扰，上下文彻底混乱，排查起来根本分不清是哪个模块遗留的数据。
最麻烦的是，出问题时日志看不出任何端倪。
日志打印的是当前请求参数，业务执行却用了残留的旧上下文数据。参数正常、逻辑正常，最终结果却错得离谱，链路日志完全对不上，极大增加排查难度。
真正稳妥的写法，从来不是靠结尾手动清理。
正确的处理方式是用 try-finally 结构，无论正常结束还是异常终止，finally 强制清空线程变量。保证每一条线程退出业务逻辑时，上下文都是干净的，不会残留任何历史数据。
写代码久了能发现，很多工具类看似简化开发，实则对使用者功底要求极高。ThreadLocal 本身没有Bug，所有线上问题，都是使用不规范、忽略线程池复用特性造成的人为隐患。
线上稳定性，往往就是这些不起眼的资源释放细节决定的。