用了三年 ThreadLocal 今天才弄明白其中的道理

Posted 2020-11-28 aaaabbbb

ThreadLocal 对于大家并不陌生，每个人应该多少都用过，或者接触过，那么你真的了解她吗？我也是今天才揭开了她的神秘面纱。

看完这篇文章你将 GET 如下知识点：

1. 什么是 ThreadLocal？
2. ThreadLocal 真的会导致内存溢出吗？
3. ThreadLocal 源码浅析
4. ThreadLocal 最佳实践
5. ThreadLocal.remove 解决的到底是什么问题？

ThreadLocal 是什么？

ThreadLocal 字面意思是线程本地变量，那么什么是线程本地变量呢？他解决了什么问题？先看下面这个例子

public class ThreadLocalTest {
    public static void main(String[] args) {
        Task task = new Task();
        for (int i = 0; i < 3; i++) {
            new Thread(() -> System.out.println(Thread.currentThread().getName() + " : " + task.calc(10))).start();
        }
    }

    static class Task {
        private int value;

        public int calc(int i) {
            value += i;
            return value;
        }
    }
}

内容很简单，启动 3 个线程，分别调用 calc 方法，然后打印线程名字和计算内容，输出如下：

Thread-0 : 10
Thread-1 : 20
Thread-2 : 30

结果不难分析，因为这么 3 个线程共用一个 Task 对象，所以 value 内容会累加，那么结果是不是不是你预期呢？那么我们再看一个例子

public class ThreadLocalTest2 {
    public static void main(String[] args) {
        ThreadLocalTest2.Task task = new ThreadLocalTest2.Task();
        for (int i = 0; i < 3; i++) {
            new Thread(() -> System.out.println(Thread.currentThread().getName() + " : " + task.calc(10))).start();
        }
    }

    static class Task {
        ThreadLocal<Integer> value;

        public int calc(int i) {
            value = new ThreadLocal();
            value.set((value.get() == null ? 0 : value.get()) + i);
            return value.get();
        }
    }
}

运行结果如下

Thread-0 : 10
Thread-1 : 10
Thread-2 : 10

这次结果就对了吧，把 value 修改成了 ThreadLocal，然后每个线程就不会互相影响内容了，那么为什么他可以做到呢？这就是 ThreadLocal 的意义所在，他解决的就是线程私有变量，多线程不互相影响。我们去源码一看究竟

ThreadLocal 源码赏析

看源码最简单粗暴的方式就是从入口进行，我们直接看 ThreadLocal.set 方法，她直接获取了当前线程，然后调用了 getMap(t)，也就是当前线程的 threadLocals 变量，如果没有直接调用 createMap 创建，然后返回，那么看到这里我们就知道了，ThreadLocal 就是一个工具类，让我们可以把内容通过k-v的方式设置在当前线程上面(里面实际是使用ThreadLocalMap 进行存储，秒看一下代码和 HashMap 原理非常相似)，既然存储在当前线程上面那么当然不会有线程安全问题了，这就是线程本地变量的内容喽。

当然我们要尤为注意，key 是 this 也就是当前的 ThreadLocal 对象，记住这点下文要说呢。

  public void set(T value) {
      Thread t = Thread.currentThread();
      ThreadLocalMap map = getMap(t);
      if (map != null)
          map.set(this, value);
      else
          createMap(t, value);
  }

ThreadLocalMap getMap(Thread t) {
    return t.threadLocals;
}

void createMap(Thread t, T firstValue) {
   t.threadLocals = new ThreadLocalMap(this, firstValue);
}

ThreadLocal 会内存溢出吗？

不过还没有结束，大家最爱谈了的就是 ThreadLocal 的内存溢出问题，那么她真的会内存溢出么？

我们再看一个例子，例子和刚才不同的地方是只使用了一个线程(也就是 Main 线程)循环运行示例，每次创建新的 Task 对象，我们可想而知，这样每次创建不同的 Task，只要线程不结束，会不停的往当前线程的 threadLocals 里面 set 内容，因为每次都是新 Task ，自然 ThreadLocal 也是新的，那么如果循环足够大，并且线程一直存在，肯定会内存溢出呢呀！！！我们自己动手试试才知道啊。

下面的例子中，在 i == 80 的时候做了一次强制 GC，我们直接 DEBUG 看下效果。

public class ThreadLocalTest3 {
    public static void main(String[] args) {
        for (int i = 0; i < 100; i++) {
            new Task().calc(10);
            if (i == 80) {
                System.gc();
            }
        }
    }

    static class Task {
        ThreadLocal<Integer> value;

        public int calc(int i) {
            value = new ThreadLocal();
            value.set((value.get() == null ? 0 : value.get()) + i);
            return value.get();
        }
    }
}

在 for 循环行的左侧点击 debug，然后点击右键，设置条件如下图，这样 DEBUG 会停留在循环变量 i 等于 79 和 81 的地方，循环 100 次是为了更好的查看效果。好了我们可以直接观察一下 i == 80 前后的运行情况了

i == 79 || i == 81

 

那么开始我的表演，下图是 DEBUG 分别停在了 79 和 81 的位置上面，我们直接运行一下当前线程的内容获取到 threadLocals 的内容

Thread.currentThread().threadLocals

可以看到两个图片里面的 ThreadLocalMap 的 size 分别是 83 和 4，这说明了什么？GC的时候把 83-4 = 79 个 ThreadLocalMap 的内容回收了？

 

 

好吧，那我们继续看下代码吧

private ThreadLocalMap(ThreadLocalMap parentMap) {
            Entry[] parentTable = parentMap.table;
            int len = parentTable.length;
            setThreshold(len);
            table = new Entry[len];

            for (int j = 0; j < len; j++) {
                Entry e = parentTable[j];
                if (e != null) {
                    @SuppressWarnings("unchecked")
                    ThreadLocal<Object> key = (ThreadLocal<Object>) e.get();
                    if (key != null) {
                        Object value = key.childValue(e.value);
                        Entry c = new Entry(key, value);
                        int h = key.threadLocalHashCode & (len - 1);
                        while (table[h] != null)
                            h = nextIndex(h, len);
                        table[h] = c;
                        size++;
                    }
                }
            }
        }

static class Entry extends WeakReference<ThreadLocal<?>> {
            /** The value associated with this ThreadLocal. */
            Object value;

            Entry(ThreadLocal<?> k, Object v) {
                super(k);
                value = v;
            }
        }

原来 ThreadLocal 的 ThreadLocalMap 里面存的每一个 Entry 是一个 WeakReference，WeakReference 会在 GC 的时候进行回收，回收的其实是 key，也就是弱引用的 referent， 然后 ThreadLocal 会在 set 和 get 的时候对 key 为空的 value 进行删除，所以这样就完美解决了当前线程生命周期不结束的时候，不同的 ThreadLocal 不停的追加到当前线程上面，导致内存溢出。

等等，那我自己写个程序，遇到 GC 不是就获取不到 ThreadLocal 对象了吗？不是的，因为一个对象只有仅仅被 WeakReference 引用才会被回收。

哎，一激动我画了一个图来说明这个问题。看下面的图，如果 work1 的引用不在了，并且 Entry 对 ThreadLocal 的引用是弱引用才会回收，是不是很巧妙的解决了这个问题？

 

所以 WeakReference 解决的就是内存溢出问题，如果持有 ThreadLocal 对象被回收了，内存自然会被回收，如果 ThreadLocal 的对象一直存在不被回收，并不能称之为内存溢出。

ThreadLocal 最佳实践

千呼万唤始出来，因为 ThreadLocal 这个特性，深受各种框架喜欢，比如 MyBatis，Spring 大量的使用的 ThreadLocal，下面是用一个最常用的案例说明一下，首先我有一个拦截器，每次请求来，使用当前的 sl 的内容 + 10，我是为了模拟效果，通常这个做法是用于传递当前登录态，以便一次请求在任何地方都可以轻松的获取到登录态。

public class SessionInterceptor implements HandlerInterceptor {
    public static ThreadLocal<Integer> sl = new ThreadLocal();

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
        Integer value = sl.get();
        if (value != null) {
            sl.set(value + 10);
        } else {
            sl.set(10);
        }
        return true;
    }

    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, @Nullable ModelAndView modelAndView) throws Exception {

    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, @Nullable Exception ex) throws Exception {

    }
}

然后我在 controller 里面获取 ThreadLocal 里面的内容，并打印当前线程的名称和内容

@RestController
public class IndexController {
    @RequestMapping("/")
    public Integer test() {
        System.out.println(Thread.currentThread().getName() + " : " + SessionInterceptor.sl.get());
        return SessionInterceptor.sl.get();
    }
}

接下来我们启动服务，运行我编写好的 Spring Boot Application

@SpringBootApplication(exclude = {DataSourceAutoConfiguration.class})
public class MainBootstrap {
    public static void main(String[] args) {
        SpringApplication.run(MainBootstrap.class, args);
    }
}

浏览器访问 https://localhost:8080，疯狂的刷新浏览器，控制台打印的效果如下

http-nio-8080-exec-1 : 10
http-nio-8080-exec-3 : 10
http-nio-8080-exec-4 : 10
http-nio-8080-exec-1 : 20
http-nio-8080-exec-2 : 10
http-nio-8080-exec-3 : 20
http-nio-8080-exec-4 : 20
http-nio-8080-exec-1 : 30
http-nio-8080-exec-2 : 20
http-nio-8080-exec-3 : 30
http-nio-8080-exec-4 : 30

呀，和我想象的不一样啊，我这可是浏览器的请求，不应该是每个请求一个线程，使用自己的 ThreadLocal 吗，怎么值也累加了？

别慌问题出现在这里，在池化技术流行的年代，自然 Tomcat 也用了池化基础，其实每个请求过来，是直接在 Tomcat 的线程池里面获取一个线程，然后运行，所以一个请求结束如果 ThreadLocal 的内容不重置，就会影响其他请求，想象如果你这个地方是做的用户登录的绑定，那么岂不是资源乱套了？

那么怎么解决呢？还记得刚才的 SessionInterceptor 类么，直接在里面的 afterCompletion 添加 sl.remove()即可，意思是在请求结束的时候，把当前线程的私有变量删除，这样就不影响其他线程了。

网上的一些说这个操作是为了更好的 GC 回收没用的实例，如果不设置也会自动回收，其实是不对的。为了让上下文都可以获取到 ThreadLocal 的内容，所以比如是静态的 ThreadLocal 所以持有的引用一直存在，并不会被回收，所以其实是在恢复线程的状态，不影响其他请求。

 @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, @Nullable Exception ex) throws Exception {
        sl.remove();
    }

修改以后我们重新狂刷浏览器，是不是问题就解决了呢？好的如果你有任何关于 ThreadLocal 的问题欢迎给我留言其他讨论，如果有不对的地方也欢迎指正。