背景
项目是简单的web项目，多用户登陆的商家管理系统，使用ThreadLocal缓存登陆用户的信息（duid，用户唯一id）
bug描述
在测试环境多次登陆后，调用查询接口查出的数据时有时无
排查过程
通过商户id和用户的duid给日志打上唯一标识（测试环境日志太多了），以便grep，排查后发现数据和日志还是时有时无，在排查中发现duid有时对有时错，于是duid便成了突破口。顺藤摸瓜，找到了拦截器缓存的duid数据，然而发现拦截器缓存的没有问题。对比别的项目的拦截器后发现了问题，拦截器有个方法没有重写且本地线程的数据也没有remove
@Override
public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
DataUserHolder.clear();
super.afterCompletion(request, response, handler, ex);
}
这个加上了，bug就解决了。
思考
为什么threadlocal的数据会错乱（被覆盖）？
画了一张简图来表示ThreadLocal的内部结构。
ThreadLocal内部实际使用了ThreadLocalMap来缓存数据。
一个entry即一个对象，可以理解为一个键值对。
ThreadLocalMap内部使用Entry[]来存储对象。
到目前为止，我们尚未分析源码，但并不妨碍我们根据结果以及加粗文字推导问题原因。
如果我们简单的把ThreadLocalMap理解为HashMap，是不是问题就显而易见了？
以当前线程为key，以登陆用户数据为value，在线程不变的情况下，用户数据变了，有没有这个可能？
有可能。
此处应有理论（个人）：服务端只认请求线程，不认请求数据
为什么这么说呢？
比如在同一个浏览器上前后登陆两个账号，最后一定登陆的是后面的账号，服务器认的是请求线程而不是账号密码。
代码模拟bug过程
public class TestMain {
@Test
public void test() {
final ThreadLocal<UserCacheVO> local = new ThreadLocal<>();
final UserCacheVO vo1 = new UserCacheVO();
vo1.setDuid("12345");
vo1.setPhone("123434324123");
local.set(vo1);
UserCacheVO vo2 = new UserCacheVO();
vo2.setDuid("xxxx");
vo2.setPhone("yyygyjbjh");
local.set(vo2);
System.out.println(local.get());
}
}
UserCacheVO(phone=yyygyjbjh, duid=xxxx, userInfoMap=null)
Process finished with exit code 0
代码流程：本来的业务需求是使用vo1的数据去db查询结果，结果vo1的数据能正常查到结果，此时我用vo2的数据再次去查询，就查不到了（数据已覆盖）
对应页面流程：页面登录，拦截器缓存数据，查询结果，正常页面展示；换账号登录后，拦截器缓存数据，覆盖之前的请求线程的数据，导致数据的duid覆盖，此时查询的结果已不是我们想要的业务结果，在服务器里使用 merchantId+duid查询数据就会发现没这个日志，就出现莫名其妙的bug了。
修改bug后的代码流程：页面登录，拦截器缓存数据，查询结果，拦截器remove缓存，正常页面展示。
注：登陆这个模块是单独的服务，且登陆服务由前端直接调用，正确登陆前端则获取ticket做业务调用
源码分析
private void set(ThreadLocal<?> key, Object value) {
// We don't use a fast path as with get() because it is at
// least as common to use set() to create new entries as
// it is to replace existing ones, in which case, a fast
// path would fail more often than not.
Entry[] tab = table;
int len = tab.length;
int i = key.threadLocalHashCode & (len-1);
for (Entry e = tab[i];
e != null;
e = tab[i = nextIndex(i, len)]) {
ThreadLocal<?> k = e.get();
// 重点
if (k == key) {
e.value = value;
return;
}
if (k == null) {
replaceStaleEntry(key, value, i);
return;
}
}
tab[i] = new Entry(key, value);
int sz = ++size;
if (!cleanSomeSlots(i, sz) && sz >= threshold)
rehash();
}
如果ThreadLocal 相同，则Entry直接覆盖。
总结
org.springframework.web.servlet.handler.HandlerInterceptorAdapter共有四个方法，分别是
preHandle
进入controller接口前执行
postHandle
在 DispatcherServlet 呈现视图（ModelAndView）之前调用，在前后端分离后好像就没有视图一说了，不甚了解
afterCompletion
请求处理完成后的回调，即渲染视图后。执行完controller接口后执行，可以做资源清理。
afterConcurrentHandlingStarted
并发执行时调用，一般用不到
此bug重点在于本地线程的数据用完后没有清理，即未调用afterCompletion并DataUserHolder.clear()