ThreadLocal操作不当引起的bug

背景

项目是简单的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()

标签：拦截器,duid,ThreadLocal,线程,不当,数据,bug
来源： https://www.cnblogs.com/woooodlin/p/threadlocal_data_not_remove.html