ThreadLocal的应用及原理

1. ThreadLocal 是什么

JDK 对ThreadLocal的描述为：

此类提供线程局部变量。这些变量与普通变量的不同之处在于，每个访问一个变量的线程（通过其get或set方法）都有自己的、独立初始化的变量副本。ThreadLocal 实例通常是类中的私有静态字段，这些字段希望将状态与线程（例如，用户ID或事务ID）相关联。

说白了，ThreadLocal就是用来存放线程自身相关数据的一个容器，这个容器叫做ThreadLocalMap，它是ThreadLocal的一个静态内部类，同时作为Thread类的一个成员变量。ThreadLocal在使用时，先拿到当前线程的成员变量ThreadLocalMap，以当前的ThreadLocal对象作为key，变量作为value 存入ThreadLocalMap。然后每个线程取变量都是从线程各自的ThreadLocalMap中取值，自然是线程安全的了。因为变量只在自己线程的生命周期内起作用，所以说ThreadLocal 提供线程局部变量，或者叫线程本地变量。

ThreadLocal 的特点有3个：

线程并发：在多线程并发的场景下使用。
数据传递：通过 ThreadLocal ，在同一个线程中，不同组件中传递公共变量。
线程隔离：不同线程之间互不干扰，这种变量在线程的生命周期内起作用。

2. ThreadLocal 怎么用

ThreadLocal 的常用方法有：

public ThreadLocal()：通过构造器创建对象。
<S> ThreadLocal<S> withInitial(Supplier<? extends S> supplier)：初始化一个 ThreadLcoal。
void set(T value)：设置当前线程绑定的局部变量。
T get()：获取当前线程绑定的局部变量。
void remove()：删除当前线程绑定的局部变量。

2.1 使用入门

2.1.1 原始版本

现在模拟一个需求，一个线程在业务开始时初始化一个用户 id（类似在一次web请求中上下文中初始化一下用户信息），业务结束时获取这个用户 id（比如用来打印日志，或者作为一个公共变量运用到业务编码中），存在多个这样的线程。

public class ThreadLocalTest {
    private String userId;

    private String getUserId() {
        return userId;
    }

    private void setUserId(String userId) {
        this.userId = userId;
    }

    public static void main(String[] args) {
        ThreadLocalTest test = new ThreadLocalTest();
        for (int i = 1; i < 5; i++) {
            Thread thread = new Thread(() -> {
                // 当前线程初始化userId
                test.setUserId(Thread.currentThread().getName() + "的userId");
                // 执行其他业务代码
                System.out.println("===执行业务代码===");
                // 当前线程获取userId
                System.out.println(Thread.currentThread().getName() + "-->" + test.getUserId());
            });
            thread.setName("线程" + i);
            thread.start();
        }
    }
}

一种可能的结果：

===执行业务代码===
线程2-->线程1的userId
===执行业务代码===
线程1-->线程3的userId
===执行业务代码===
线程3-->线程3的userId
===执行业务代码===
线程4-->线程4的userId

由于线程调度的不确定性，可能线程1运行到一半，切换到了线程2，于是线程2获取到的 userId 是线程1设置的。也就是说，每个线程之间的变量不是隔离的，造成数据错误。

2.1.2 ThreadLocal 版本

每个线程中的变量都存放到自己的线程当中，所以这些变量叫做线程局部变量很形象。

public class ThreadLocalTest {
    private static ThreadLocal<String> context = new ThreadLocal<>();

    private String getUserId() {
        return context.get();
    }

    private void setUserId(String userId) {
        context.set(userId);
    }

    public static void main(String[] args) {
        ThreadLocalTest test = new ThreadLocalTest();
        for (int i = 1; i < 5; i++) {
            Thread thread = new Thread(() -> {
                test.setUserId(Thread.currentThread().getName() + "的userId");
                System.out.println("===执行业务代码===");
                System.out.println(Thread.currentThread().getName() + "-->" + test.getUserId());
                context.remove(); // 使用完清理线程局部变量
            });
            thread.setName("线程" + i);
            thread.start();
        }
    }
}

这样每个线程就互不干扰，不会取错变量值。一种可能的结果如下：

===执行业务代码===
线程1-->线程1的userId
===执行业务代码===
线程4-->线程4的userId
===执行业务代码===
线程2-->线程2的userId
===执行业务代码===
线程3-->线程3的userId

2.1.3 synchronized 版本

如果只看结果的正确性，用 synchronized 给业务代码块加锁也是可以完成的。如下：

Thread thread = new Thread(() -> {
    synchronized (ThreadLocalTest.class) {
        test.setUserId(Thread.currentThread().getName() + "的userId");
        System.out.println("===执行业务代码===");
        System.out.println(Thread.currentThread().getName() + "->" + test.getUserId());
    }
});

这样完全可以实现需求，但是 synchronized 的问题是什么呢？我们总说谁谁谁是线程安全的类，因为它有 synchronized 修饰。就是因为 synchronized 让多线程变成了单线程，它一次只允许一个线程执行，它能不安全吗？但它带来的代价是性能的下降，它不能并发执行，而 ThreadLocal 可以并发执行。

2.1.4 ThreadLocal 和 synchronized 对比

综上，synchronized 和 ThreadLocal 两个处理问题的角度和场景是不同的。

synchronized 的侧重点在于保证操作的原子性，保证并发场景下共享变量的数据一致性。
ThreadLocal 强调线程隔离性，不同的线程互不干扰，保证并发场景下数据传递的正确性。在web请求上下文中较为常见。

3. ThreadLocal 的原理

3.1 代码结构

ThreadLocal 的原理要从它的set(T value)、get()方法的源码入手。

点击查看代码

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

public T get() {
	Thread t = Thread.currentThread();
	ThreadLocalMap map = getMap(t);
	if (map != null) {
		ThreadLocalMap.Entry e = map.getEntry(this);
		if (e != null) {
			@SuppressWarnings("unchecked")
			T result = (T)e.value;
			return result;
		}
	}
	return setInitialValue();
}

在 set 值的时候，首先会获取当前线程一个的成员变量ThreadLocalMap，ThreadLocalMap的 key 是当前ThreadLocal对象，value 是要存入的值。

这个 key 和 value 会存到哪里呢？

ThreadLocalMap还有个内部类Entry，这个Entry继承了WeakReference，key 赋值给弱引用，也就是当前的ThreadLocal对象，value 则赋值给Entry的成员变量value。ThreadLocalMap也是一个哈希表（所谓哈希表，也叫散列表，它基于数组，通过某种哈希算法计算出一系列关键字对应的散列值，然后以这些散列值作为数组索引将数据存放到对应位置，达到快速查找的目的），它内部维护一个Entry数组，来存储键值对。存数据的时候也是通过哈希函数计算ThreadLocal 对象对应的数组下标，然后放入Entry数组中。

3.2 内存泄漏问题

ThreadLocal 会发生内存泄漏吗？我们结合代码慢慢分析。

在 2.1.1 节中有这样的代码：

public class ThreadLocalTest {
    private static ThreadLocal<String> threadLocal = new ThreadLocal<>();

    private void setUserId(String userId) {
        threadLocal.set(userId);
    }
    // ...
}

首先，我们new了一个 ThreadLocal 对象，这里存在一个强引用：threadLocal引用变量指向 ThreadLocal 对象。其次，当其他线程执行setUserId方法时，ThreadLocal 的set方法最终是把数据存到了ThreadLocalMap中的Entry，看源码我们会发现，存数据最终是调用Entry的构造器Entry(ThreadLocal<?> k, Object v)完成的，而k这个参数是传入的this对象，说明什么？我们使用 ThreadLocal 对象调用set，那this肯定是当前new出来的 ThreadLocal 对象！因此，我们new出来的 ThreadLocal 对象有两个引用指向它：

threadLocal变量的强引用。
在Entry中 key 的弱引用。

我们再看一张图，可更清晰的看到引用关系（这张图被广泛引用，感谢原图作者😂）：

堆内存里面有个 ThreadLocal 对象，它被两个箭头指着，实线代表强引用，虚线代表弱引用。
有两个引用链，一个是我们手动创建的threadLocal的引用变量指向的，即图中的 ThreadLcoal Ref 对应示例代码中的threadLocal变量；一个是由于调用了 ThreadLocal 的set或get方法，初始化了当前线程的ThreadLocalMap，再初始化 Map 中的Entry对象，再初始化Entry对象中的 key 和 value，形成一个由当前线程对象到它内部变量的引用链，即上图中的 Current Thread Ref，它对应set方法源码中的这一行Thread t = Thread.currentThread();中的变量t。

那问题来了，如果这个手动创建的 ThreadLocal 对象的『引用变量』被回收了，那 ThreadLocal 对象是不是只剩下Entry中 key 的弱引用了？而弱引用的对象会随时被 GC 回收，即Entry中的 key 会在 GC 后变为null了。我们知道，ThreadLocalMap的 key 是当前的 ThreadLocal 对象，那 key 为null了之后，就无法获取到Entry，也取不到 value 的值了。在Entry对象没有被主动删除，或者当前线程没有终结的情况下，该Entry一直处在一个由当前线程指向的强引用链中。由于这个Entry获取不到，就一直占用着内存，又因为强引用不能被 GC 回收，所以这个Entry就发生了内存泄漏。如果这个线程是一个普通线程，在线程终止的时候，整个线程对象被回收了，那内存泄漏的时间比较短；如果该线程一直不终止，比如线程池中的核心线程，那内存泄露问题就一直存在了。

注意，上面说的“如果这个手动创建的 ThreadLocal 对象的『引用变量』被回收了”，应该会有人疑惑这种情况什么时候会发生呢？第一种情况，手动把这个引用变量置为null，虽然概率小，但也不是没可能；第二种情况，引用变量是存在栈内存中，当方法执行完，就会立即回收栈内存中的引用变量，即堆内存中的实际对象失去引用指针了。这种情况就比如 ThreadLocal 是在方法中创建的局部变量。

3.3 为什么使用弱引用

Entry的 key 使用弱引用有内存泄漏风险，那为什么 JDK 还是使用弱引用而不是强引用？

我们分两种情况讨论：

key 使用强引用：ThreadLocal 的引用变量被回收了，这句话意味着什么呢？引用变量被回收了，意味着代码中不再使用 ThreadLocal 这个对象了，因为要使用 ThreadLocal 这个对象，我们需要用它的引用变量取调set、get方法，现在引用变量没了，我们就用不了 ThreadLocal 这个对象了。但问题是，ThreadLocalMap还持有ThreadLocal对象的强引用，当前线程到Entry的强引用链依然存在。注意，前面提到了，ThreadLocal 对象已经不再使用了，也就是说Entry就获取不到了。如果Entry没有手动删除，或者线程没有结束，这个没用的Entry也会一直保留，依然发生内存泄漏（要明白内存泄漏是对象没用了，还存在内存中不被回收的情况）。
key 使用弱引用：前面已经分析过了，ThreadLocal 的引用变量被回收了，ThreadLocal对象也被回收，导致Entry的 key 变成null，在没有手动删除Entry或线程不结束时依然发生内存泄漏。

归根结底，由于ThreadLocalMap的生命周期跟Thread一样长，在 ThreadLocal 的引用变量消失后，如果线程不结束，原来的Entry就不会回收，这就是内存泄漏的本质。虽然 ThreadLocal 在每次读写数据的时候，都会将key为null的Entry清空，但是，既然 ThreadLocal 的引用变量都消失了，我们也没机会再set或get了。

那为什么使用弱引用？我也不知道！我还没想明白，如果正在阅读的你知道，请你告诉我下，谢谢😅。虽然ThreadLocalMap的注释中解释了：

To help deal with very large and long-lived usages, the hash table entries use WeakReferences for keys.

为了帮助处理非常大和长期的使用，哈希表条目使用WeakReferences作为键。

我觉得没必要取纠结这个问题，只要规范的使用 ThreadLocal，几乎不会发生内存泄漏。

3.4 如何防止内存泄漏

把 ThreadLocal 对象申明为类变量。类变量的生命周期跟 JVM 是同步的，这样 ThreadLocal 的强引用就一直存在，不会被 GC 回收，Entry的key就不会发生null的情况了。
使用完 ThreadLocal 后，用remove()方法，清空当前ThreadLocal 对应的数据，对应的Entry就不占内存了。

第一种情况虽热能避免Entry的key为null的情况，但是如果后续线程不再访问这个 key，且线程不结束时，这个 key 对应的数据也会一直存在内存中，容易造成内存溢出的问题。所以最好的办法就是在 ThreadLocal 使用完之后，使用remove()方法清除数据。

4. ThreadLocal 如何存多个变量

上面的示例代码中，ThreadLocal 只存了一个变量，实际情况不可能只存一个吧，多个变量如何存，如何取？

要知道 ThreadLocal 使用set方法存数据时，key 用的this对象，就是当前正在使用的 ThreadLocal 对象，说明一个 ThreadLocal 对象，在一个线程中，只能存一个线程本地变量。多个线程虽然都是用的是一个 key，但是不同的线程用的是不同的ThreadLocalMap。

第一种方案是多 new 几个 ThreadLocal 对象，每个 ThreadLocal 对象对应一个业务变量。

第二种方案是给 ThreadLocal 初始化一个HashMap，用HashMap存储多个公共数据，这是最常规的做法。比如：

public class ThreadLocalTest {
    private static final ThreadLocal<Map<String, Object>> context = ThreadLocal.withInitial(HashMap::new);

    private String getUserId() {
        return String.valueOf(context.get().get("userId"));
    }

    private void setUserId(String userId) {
        context.get().put("userId", userId);
    }

    public void setUserName(String userName) {
        context.get().put("userName", userName);
    }

    public String getUserName() {
        return String.valueOf(context.get().get("userName"));
    }

    public static void main(String[] args) {
        ThreadLocalTest test = new ThreadLocalTest();
        for (int i = 1; i < 5; i++) {
            Thread thread = new Thread(() -> {
                String threadName = Thread.currentThread().getName();
                test.setUserId(threadName + "的userId");
                test.setUserName(threadName + "的userName");
                System.out.println("===执行业务代码===");
                System.out.println(threadName + "-->" + test.getUserId() + "," + test.getUserName());
            });
            thread.setName("线程" + i);
            thread.start();
        }
    }
}

一种可能的结果：

===执行业务代码===
线程2-->线程2的userId,线程2的userName
===执行业务代码===
线程4-->线程4的userId,线程4的userName
===执行业务代码===
线程3-->线程3的userId,线程3的userName
===执行业务代码===
线程1-->线程1的userId,线程1的userName

5. 为什么用 ThreadLocal

5.1 ThreadLocal的使用场景

线程的上下文传递。企业中最常见的是应用到web请求的上下文，一个 Http 请求会经过一系列拦截器，过滤器最后到达服务层，在这个调用链路中，会频繁的使用到一些公共数据，如用户信息或请求的ID，把这些公共数据放到 ThreadLocal 中，会在请求的链路中非常方便的使用这些信息。

还有一些框架中会使用 ThreadLocal 来管理数据库连接，避免了线程之间的竞争。比如 Mybatis 就是用 ThreadLocal 来存储 Sqlsession 对象。

5.2 使用 ThreadLocal 的好处

使用 ThreadLocal 的好处是并发场景下减少了同一个线程内多个函数或组件之间传递公共变量的复杂度，且提高了使用这些共享变量的安全性。

posted @ 2023-05-25 14:36 yfhu 阅读(526) 评论(0) 编辑收藏举报

刷新页面返回顶部

厚积薄发