ThreadLocal实战之踩坑笔记

简要聊聊ThreadLocal

ThreadLocal提供线程内部的局部变量，我们可以将项目中的一些变量直接存放在当前线程中，在本线程内随时随地可取，隔离其他线程，获取保存的值时非常方便。

案例集锦

案例一：

public class RequestContextHolderEx {

    private static ThreadLocal REQUEST_THREAD_LOCAL = new ThreadLocal<>();

    public static void clear() {

        REQUEST_THREAD_LOCAL.remove();

    }

    public static HttpServletRequest getRequest() {

        HttpServletRequest request = REQUEST_THREAD_LOCAL.get();

        if (request != null)

            return request;

        ServletRequestAttributes requestAttributes = getRequestAttributes();

        if (requestAttributes != null)

            request = requestAttributes.getRequest();

        REQUEST_THREAD_LOCAL.set(request);

        return request;

    }

}

首先这是我们封装的一个处理Request相关的支持类，这个类我们定义了一个REQUEST_THREAD_LOCAL的ThreadLocal对象，专门用来存储HttpServletRequest对象

我们看看下面的这个getRequest()方法，方法里边，第一行就是直接调用ThreadLocal的get()方法，request对象不为空的话直接返回，为空的话通过getRequestAttributes().getRequest()重新查一遍request，查出来后再调用set()方法把request对象设置进去，等到同一线程下次再调用这个getRequest()方法时，就能够直接get()出request对象返回。

上面这段代码其实很简单，get()本地线程变量中存的值，存在的话直接返回，不存在的话，重新查一遍，把对象重新set()到本地线程变量中再返回。

emm…多看了几遍，好像有什么不对劲的地方，我们为啥要用本地线程呢，在这里我不用是不是也可以？答案是：可以。

确实，这个方法你直接这么写：

    public static HttpServletRequest getRequest() {

        ServletRequestAttributes requestAttributes = getRequestAttributes();

        if (requestAttributes != null)

            request = requestAttributes.getRequest();

        return request;

    }

说实话，没毛病，还少几行代码，还不会踩我案例二要说到的坑，但是我们引入ThreadLocal是不是真的多此一举了呢？

其实不然，你仔细想想，假如说整个请求多次调用这个方法，不用ThreadLocal的话，是不是每次都需要先getRequestAttributes()，再requestAttributes.getRequest()，没发现这样很多此一举吗，还很花费时间，如果你感觉这里耗时不多的话，那想过没有假如我们要查的值涉及很多逻辑，甚至是要查数据库，这个开销就大了啊；使用ThreadLocal的话，同一个请求查询多次这个方法，线程只会第一次调用该方法时跑一遍获取逻辑，再把值存储到本地线程中，其他时候直接从本地线程中获取就行了，方便多了，耗时少了，不会再重复的跑相同逻辑的事了，所以引入本地线程是很有必要的事啊。

那ThreadLocal这么好用，是不是可以到处都用呢？其实也不是啦，很简单嘛，假如你整个请求就调用一次这个方法，那使用ThreadLocal的意义在哪呢，这才是多此一举，所以只有那些一次请求有可能使用到多次的变量才存储到ThreadLocal中，像Request、SessionInfo信息等那些一次请求可能多次访问的数据都可以存储到ThreadLocal。

会了ThreadLocal使用姿势和使用场景，是不是就可以开始上手了呢，别急，咱们先踩个坑~

案例二：

public class SessionContext {

private static final ThreadLocal SESSION_INFO_THREAD_LOCAL = new ThreadLocal<>();

    public void clear() {

        SESSION_INFO_THREAD_LOCAL.remove();

    }

public SessionInfo getSessionInfo() {

        SessionInfo si = SESSION_INFO_THREAD_LOCAL.get();

        if (null != si) {

            return si;

        }

        //balabala...，省略一堆获取SessionInfo的逻辑

        SESSION_INFO_THREAD_LOCAL.set(si);

        return si;

    }

}

这个代码和案例一的代码基本一样，只不过案例二存储的是用户的登录信息SessionInfo，先说说现象：

其实就是一个用户getSessionInfo()获取到了其他人的用户登录信息，导致出现了一些偶发的神奇问题，这个问题出现的时候真是头疼，当时自己也不是很懂ThreadLocal，只是定位到应该是SessionInfo获取的有问题。

先别急着往下看，思考一下，是什么原因会导致获取到了别人的SessionInfo。

这篇balabala了一堆，其实上面的问题就是和ThreadLocal有关，你们发现没，我两个案例都写了一个一个我没有提到的方法，是的，clear()方法，案例二出现的原因就是因为请求结束没有remove()掉保存在本地线程中的信息。

我们来看看到底是不是因为没有remove掉原信息

理论推断：我们知道一个线程使用完之后并不会销毁，而是会回到线程池进行复用，也就是说，如果你不调用remove()的话，保存在当前线程中的变量实例还是绑定在线程上的，当下一个用户使用了其他用户使用过的线程处理请求，直接get()的话，就会把原来在该线程中保存的信息给获取出来，这就直接导致获取到了别人的用户信息，这是非常危险的。

验证：先来一段代码

public class ThreadLocalTest {

    /**

    * 创建只有一个线程的线程池

    */

    private static ExecutorService executor = Executors.newFixedThreadPool(1);

    /**

    * 测试用的ThreadLocal

    */

    private static ThreadLocal TEST_THREAD_LOCAL = new ThreadLocal<>();

    @Test

    public void test() {

        //循环三次，模拟三个不同用户的请求

        for (int i = 1; i <= 3; i++) {

            int finalI = i;

            executor.execute(() -> {

                System.out.println("模拟【第" + finalI + "个】用户请求");

                //先get()一遍本地线程中的信息

                System.out.println("线程【" + Thread.currentThread().getName() + "】的ThreadLocal保存的信息：" + TEST_THREAD_LOCAL.get());

                //重新set()用户信息

                TEST_THREAD_LOCAL.set("用户" + finalI + "的信息");

                //再get()一次用户信息

                System.out.println("线程【" + Thread.currentThread().getName() + "】的ThreadLocal保存的信息：" + TEST_THREAD_LOCAL.get() + "\n");

                //当前线程结束，移除本地线程中保存的信息

                //TEST_THREAD_LOCAL.remove();

            });

        }   

        //记得关闭线程池

        executor.shutdown();

    }

}

来看一下代码，第一行创建只有一个线程的线程池1，创建一个线程是便于测试，这里循环三次模拟了三个用户发起的三次请求，不同用户都使用同一个线程，在不调用remove()方法的前提下，看看后面的用户是否会get()到前面用户保存的信息，结果：

模拟【第1个】用户请求

线程【pool-1-thread-1】的ThreadLocal保存的信息：null

线程【pool-1-thread-1】的ThreadLocal保存的信息：用户1的信息

模拟【第2个】用户请求

线程【pool-1-thread-1】的ThreadLocal保存的信息：用户1的信息(X)

线程【pool-1-thread-1】的ThreadLocal保存的信息：用户2的信息

模拟【第3个】用户请求

线程【pool-1-thread-1】的ThreadLocal保存的信息：用户2的信息(X)

线程【pool-1-thread-1】的ThreadLocal保存的信息：用户3的信息

1234567891011

猜想没错，结果中（X）的两行获取到了之前用户保存的信息，我们把代码中remove()方法打开注释再跑一遍，看看结果：

模拟【第1个】用户请求

线程【pool-1-thread-1】的ThreadLocal保存的信息：null

线程【pool-1-thread-1】的ThreadLocal保存的信息：用户1的信息

模拟【第2个】用户请求

线程【pool-1-thread-1】的ThreadLocal保存的信息：null

线程【pool-1-thread-1】的ThreadLocal保存的信息：用户2的信息

模拟【第3个】用户请求

线程【pool-1-thread-1】的ThreadLocal保存的信息：null

线程【pool-1-thread-1】的ThreadLocal保存的信息：用户3的信息

1234567891011

线程结束的时候remove()掉保存的信息，现在的结果正确，我们前面的推断没有问题，整个验证到此结束。

最后来个思考题

问：我们这段验证代码是最后一行调用的remove()方法，那在项目中应该什么时候调用remove()方法合理呢？在请求结束时？好像行不通啊，请求什么时候结束，线程什么时候回到线程池？而且要清理的是所有线程请求，不是某一个业务接口请求，好像都没法在请求结束时统一处理。

先思考一分钟…

答：其实我们的目的是要保证，每个线程在处理请求之前是干净的就行了，所以说只要在请求处理业务之前调用remove()接口就可以了，有什么东西能够保证所有请求都经过呢，过滤器，我们只要在过滤器那边调用remove()方法就行。

注意一定要使用线程池，也就是说要保证线程处理完请求后直接回到线程池，不能被销毁 ↩︎

————————————————

版权声明：本文为CSDN博主「木兮同学」的原创文章，遵循CC 4.0 by-sa版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/qq_36221788/article/details/94884591