关于threadlocal:说实话ThreadLocal真不是啥高级的东西

2次阅读

共计 8326 个字符，预计需要花费 21 分钟才能阅读完成。

从 Java 官网文档中的形容：ThreadLocal 类用来提供线程外部的局部变量。这种变量在多线程环境下拜访（通过get 和 set 办法拜访）时能保障各个线程的变量绝对独立于其余线程内的变量。ThreadLocal 实例通常来说都是 private static 类型的，用于关联线程和线程上下文。

咱们能够得悉 ThreadLocal 的作用是：提供线程内的局部变量，不同的线程之间不会互相烦扰，这种变量在线程的生命周期内起作用，缩小同一个线程内多个函数或组件之间一些公共变量传递的复杂度。

线程并发：在多线程并发的场景下
传递数据：咱们能够通过 ThreadLocal 在同一线程，不同组件之间传递公共变量（有点相似于 Session？）
线程隔离：每个线程的变量都是独立的，不会相互影响

在介绍 ThreadLocal 应用之前，咱们首先意识几个 ThreadLocal 的常见办法

咱们来看上面这个线程不平安的案例，感受一下 ThreadLocal 线程隔离的特点。

/**
 * 需要：线程隔离
 * 在多线程并发的场景下，每个线程中的变量都是互相独立的
 * 线程 A：设置变量 1，获取变量 2
 * 线程 B：设置变量 2，获取变量 2
 * @author: 陌溪
 */
public class MyDemo01 {
    // 变量
    private String content;

    public String getContent() {return content;}

    public void setContent(String content) {this.content = content;}

    public static void main(String[] args) {MyDemo01 myDemo01 = new MyDemo01();
        for (int i = 0; i < 5; i++) {new Thread(() -> {myDemo01.setContent(Thread.currentThread().getName() + "的数据");
                System.out.println("-----------------------------------------");
                System.out.println(Thread.currentThread().getName() + "\t" + myDemo01.getContent());
            }, String.valueOf(i)).start();}
    }
}

运行后的成果

-----------------------------------------
-----------------------------------------
-----------------------------------------
3      4 的数据
-----------------------------------------
2      4 的数据
-----------------------------------------
1      4 的数据
4      4 的数据
0      4 的数据

从下面咱们能够看到，呈现了线程不隔离的问题，也就是线程 1 取出了线程 4 的内容，那么如何解决呢？

这个时候就能够用到 ThreadLocal 了，咱们通过 set 将变量绑定到以后线程中，而后get 获取以后线程绑定的变量

/**
 * 需要：线程隔离
 * 在多线程并发的场景下，每个线程中的变量都是互相独立的
 * 线程 A：设置变量 1，获取变量 2
 * 线程 B：设置变量 2，获取变量 2
 * @author: 陌溪
 */
public class MyDemo01 {
    // 变量
    private String content;

    public String getContent() {return content;}

    public void setContent(String content) {this.content = content;}

    public static void main(String[] args) {MyDemo01 myDemo01 = new MyDemo01();
        ThreadLocal<String> threadLocal = new ThreadLocal<>();
        for (int i = 0; i < 5; i++) {new Thread(() -> {threadLocal.set(Thread.currentThread().getName() + "的数据");
                System.out.println("-----------------------------------------");
                System.out.println(Thread.currentThread().getName() + "\t" + threadLocal.get());
            }, String.valueOf(i)).start();}
    }
}

通过引入 ThreadLocal 后，查看运行后果如下：

-----------------------------------------
-----------------------------------------
4      4 的数据
-----------------------------------------
3      3 的数据
-----------------------------------------
2      2 的数据
-----------------------------------------
1      1 的数据
0      0 的数据

发现不会呈现下面的状况了，也就是以后线程只能获取线程线程存储的对象

对于上述的例子，齐全能够通过加锁的形式来实现这个性能，咱们来看一下用Synchronized 代码块实现的成果：

    public static void main(String[] args) {MyDemo03 myDemo01 = new MyDemo03();
        for (int i = 0; i < 5; i++) {new Thread(() -> {synchronized (MyDemo03.class) {myDemo01.setContent(Thread.currentThread().getName() + "的数据");
                    System.out.println("-----------------------------------------");
                    System.out.println(Thread.currentThread().getName() + "\t" + myDemo01.getContent());
                }
            }, String.valueOf(i)).start();}
    }

运行后果如下所示，发现通过加锁能够实现与 ThreadLocal 线程隔离的性能，然而并发性升高了。

-----------------------------------------
0      0 的数据
-----------------------------------------
4      4 的数据
-----------------------------------------
3      3 的数据
-----------------------------------------
2      2 的数据
-----------------------------------------
1      1 的数据

尽管 ThreadLocal 模式与 Synchronized 关键字都用于解决多线程并发拜访变量的问题，不过两者解决问题的角度和思路不同。

总结：在刚刚的案例中，尽管应用 ThreadLocal 和 Synchronized 都能解决问题，然而应用 ThreadLocal 更为适合，因为这样能够使程序领有更高的并发性。

通过以上的介绍，咱们曾经根本理解 ThreadLocal 的特点，然而它具体是使用在什么场景中的呢？接下来让咱们看一个案例：事务操作

这里首先构建一个简略的转账场景：有一个数据表 account，外面有两个用户 jack 和Rose，用户 Jack 给用户Rose 转账。这个案例的实现次要是用 mysql 数据库，JDBC 和C3P0 框架，以下是具体代码

这里们先构建一个简略的转账场景：有一个数据表 account，外面有两个用户 jack 和Rose，用户 Jack 给用户Rose 转账。案例的实现次要是用 mysql 数据库，JDBC 和C3P0 框架，以下是具体代码

案例中转账波及两个 DML 操作：一个转出，一个转入。这些操作是须要具备原子性的，不可分割。不然有可能呈现数据批改异常情况。

public class AccountService {public boolean transfer(String outUser, String isUser, int money) {AccountDao ad = new AccountDao();
        try {
            // 转出
            ad.out(outUser, money);
            // 模仿转账过程中的异样
            int i = 1/0;
            // 转入
            ad.in(inUser, money);
        } catch(Exception e) {e.printStackTrace();
            return false;
        }
        return true;
    }
}

所以这里就须要操作事务，来保障转入和转出具备原子性，要么胜利，要么失败。

JDBC 中对于事务操作的 API

开启事务的留神点

为了保障所有操作在一个事务中，案例中应用的连贯必须是同一个；
service 层开启事务的 connection 须要跟 dao 层拜访数据库的 connection 保持一致
线程并发状况下，每个线程只能操作各自的 connection，也就是线程隔离

基于下面给出的前提，大家通常想到的解决办法

从 service 层将 connection 对象向 dao 层传递
加锁

进步代码的耦合度（因为咱们须要从 service 层传入 connection 参数）
升高程序的性能（加了同步代码块，失去了并发性）

这个时候就能够通过 ThreadLocal 和以后线程进行绑定，来升高代码之间的耦合

针对下面呈现的状况，咱们须要对原来的 JDBC 连接池对象进行更改

将原来从连接池中获取对象，改成间接获取以后线程绑定的连贯对象
如果连贯对象是空的
再去连接池中获取连贯
将此连贯对象跟以后线程进行绑定

ThreadLocal<Connection> tl = new ThreadLocal();
public static Connection getConnection() {Connection conn = tl.get();
    if(conn == null) {conn = ds.getConnection();
        tl.set(conn);
    }
    return conn;
}

从上述的案例中咱们能够看到，在一些特定场景下，ThreadLocal 计划有两个突出的劣势：

传递数据：保留每个线程绑定的数据，在须要的中央能够间接获取，防止参数间接传递带来的代码耦合问题
线程隔离：各线程之间的数据互相隔离却又具备并发性，防止同步形式带来的性能损失

通过以上的学习，咱们对 ThreadLocal 的作用有了肯定的意识。当初咱们一起来看一下ThreadLocal 的内部结构，探索它可能实现线程数据隔离的原理。

如果咱们不去看源代码的话，可能会猜想 ThreadLocal 是这样子设计的：每个ThreadLocal 都创立一个 Map，而后用线程作为 Map 的 key，要存储的局部变量作为Map 的 value，这样就能达到各个线程的局部变量隔离的成果。这是最简略的设计办法，JDK 最晚期的 ThreadLocal 的确是这样设计的，但当初早已不是了。

然而，JDK 前面优化了设计方案，在 JDK8 中 ThreadLocal 的设计是：每个 Thread保护一个ThreadLocalMap，这个 Map 的 key 是 ThreadLocal 实例自身，value 才是真正要存储的值 object。具体的过程是这样的：

每个 Thread 线程外部都有一个 Map（ThreadLocalMap）
Map 外面存储 ThreadLocal 对象key 和线程的变量正本 value
Thread 外部的 Map 是由 ThreadLocal 保护的，由 ThreadLocal 负责向 map获取和设置线程的变量值。
对于不同的线程，每次获取正本值时，别的线程并不能获取到以后线程的正本值，造成了正本的隔离，互不烦扰。

从下面变成 JDK8 的设计有什么益处？

每个 Map 存储的 Entry 数量变少，因为原来的 Entry 数量是由 Thread 决定，而当初是由 ThreadLocal 决定的。实在开发中，Thread 的数量远远大于ThreadLocal 的数量
当 Thread 销毁的时候，ThreadLocalMap 也会随之销毁，因为 ThreadLocal 是寄存在 Thread 中的，随着 Thread 销毁而隐没，能升高开销。

在剖析 ThreadLocal 办法的时候，咱们理解到 ThreadLocal 的操作实际上是围绕ThreadLocalMap 开展的。ThreadLocalMap 的源码绝对比较复杂，咱们从以下三个方面进行探讨。

ThreadLocalMap 是 ThreadLocal 的外部类，没有实现 Map 接口，用独立的形式实现了 Map 的性能，其外部的 Entry 也是独立实现。

/**
* 初始容量 - 必须是 2 的整次幂
**/
private static final int INITIAL_CAPACITY = 16;

/**
* 存放数据的 table，Entry 类的定义在上面剖析，同样，数组的长度必须是 2 的整次幂
**/
private Entry[] table;

/**
* 数组外面 entrys 的个数，能够用于判断 table 以后使用量是否超过阈值
**/
private int size = 0;

/**
* 进行扩容的阈值，表使用量大于它的时候进行扩容
**/
private int threshold; // Default to 0

跟 HashMap 相似，INITIAL_CAPACITY 代表这个 Map 的初始容量；table 是一个Entry 类型的数组，用于存储数据；size 代表表中的存储数目；threshold 代表须要扩容时对应的 size 的阈值。

/*
*Entry 继承 WeakRefefence，并且用 ThreadLocal 作为 key.
如果 key 为 nu11（entry.get（）==nu11），意味着 key 不再被援用，* 因而这时候 entry 也能够从 table 中革除。*/
static class Entry extends weakReference<ThreadLocal<?>>{

object value；Entry（ThreadLocal<？>k，object v）{super(k);
    value = v;
}}

在 ThreadLocalMap 中，也是用 Entry 来保留 K-V 构造数据的。不过 Entry 中的key 只能是 ThreadLocal 对象，这点在构造方法中曾经限定死了。

另外，Entry 继承 WeakReference，也就是 key（ThreadLocal）是弱援用，其目标是将 ThreadLocal 对象的生命周期和线程生命周期解绑。

有些程序员在应用 ThreadLocal 的过程中会发现有内存透露的状况产生，就猜想这个内存透露跟 Entry 中应用了弱援用的 key 有关系。这个了解其实是不对的。

咱们先来回顾这个问题中波及的几个名词概念，再来剖析问题。

Memory overflow：内存溢出，没有足够的内存提供申请者应用。

Memory leak：内存透露是指程序中己动态分配的堆内存因为某种原因程序未开释或无奈开释，造成零碎内存的节约，导致程序运行速度减慢甚至零碎溃等严重后果。I 内存透露的沉积终将导致内存溢出。

Java 中的援用有 4 种类型：强、软、弱、虚。以后这个问题次要波及到强援用和弱援用：

强援用：就是咱们最常见的一般对象援用，只有还有强援用指向一个对象，就能表明对象还“活着”，垃圾回收器就不会回收这种对象。

弱援用：垃圾回收器一旦发现了只具备弱援用的对象，不论以后内存空间足够与否，都会回收它的内存。

假如 ThreadLocalMap 中的 key 应用了强援用，那么会呈现内存透露吗？

此时 ThreadLocal 的内存图（实线示意强援用）如下：

假如在业务代码中应用完 ThreadLocal，threadLocal Ref被回收了
然而因为 threadLocalMap 的 Entry 强援用了 threadLocal，造成threadLocal 无奈被回收。
在没有手动删除这个 Entry 以及 CurrentThread 仍然运行的前提下，始终有强援用链 threadRef->currentThread->threadLocalMap->entry，Entry 就不会被回收（Entry 中包含了 ThreadLocal 实例和 value），导致 Entry 内存透露。

也就是说，ThreadLocalMap 中的 key 应用了强援用，是无奈完全避免内存透露的。

同样假如在业务代码中应用完 ThreadLocal，threadLocal Ref 被回收了。
因为 ThreadLocalMap 只持有 ThreadLocal 的弱援用，没有任何强援用指向threadlocal 实例，所以threadlocal 就能够顺利被 gc 回收，此时 Entry 中的key=null。
然而在没有手动删除这个 Entry 以及 CurrentThread 仍然运行的前提下，也存在有强援用链 threadRef->currentThread->threadLocalMap->entry-> value，value 不会被回收，而这块 value 永远不会被拜访到了，导致 value 内存透露。

也就是说，ThreadLocalMap 中的 key 应用了弱援用，也有可能内存透露。

比拟以上两种状况，咱们就会发现，内存透露的产生跟 ThreadLocalMap 中的 key 是否应用弱援用是没有关系的。那么内存透露的的真正起因是什么呢？

仔细的同学会发现，在以上两种内存透露的状况中，都有两个前提：

没有手动删除这个 Entry
CurrentThread 仍然运行

第一点很好了解，只有在应用完 ThreadLocal，调用其 remove 办法删除对应的Entry，就能防止内存透露。

第二点略微简单一点，因为 ThreadLocalMap 是 Thread 的一个属性，被以后线程所援用，所以它的生命周期跟 Thread 一样长。那么在应用完 ThreadLocal 的应用，如果以后 Thread 也随之执行完结，ThreadLocalMap 天然也会被 gc 回收，从本源上防止了内存透露。

综上，ThreadLocal 内存透露的本源是：因为 ThreadLocalMap 的生命周期跟Thread 一样长，如果没有手动删除对应 key 就会导致内存透露。

依据方才的剖析，咱们晓得了：无论 ThreadLocalMap 中的 key 应用哪种类型援用都无奈完全避免内存透露，跟应用弱援用没有关系。

要防止内存透露有两种形式：

应用完 ThreadLocal，调用其 remove 办法删除对应的 Entry
应用完 ThreadLocal，以后 Thread 也随之运行完结

绝对第一种形式，第二种形式显然更不好管制，特地是应用线程池的时候，线程完结是不会销毁的，而是接着放入了线程池中。

也就是说，只有记得在应用完 ThreadLocal 及时的调用 remove，无论 key 是强援用还是弱援用都不会有问题。那么为什么 key 要用弱援用呢？

事实上，在 ThreadLocalMap 中的 set / getEntry 办法中，会对 key 为 null（也即是 ThreadLocal 为null）进行判断，如果为 null 的话，那么是会对 value 置为null 的。

这就意味着应用完 ThreadLocal，CurrentThread 仍然运行的前提下，就算遗记调用 remove 办法，弱援用比强援用能够多一层保障：弱援用的ThreadLocal 会 被回收，对应的 value 在下一次 ThreadLocalMap 调用set，get，remove 中的任一办法的时候会被革除，从而防止内存透露。

正文完

threadlocal

发表至： threadlocal

2022-06-30

0

关于threadlocal:ThreadLocal线程中的全局变量-京东云技术团队

关于threadlocal:知道ThreadLocal吗一起聊聊到底有啥用

关于threadlocal:阿里-TransmittableThreadLocal-代码简读

关于threadlocal:说实话ThreadLocal真不是啥高级的东西

关于程序员:附下载渗透测试神器Nessus安装及使用

关于threadlocal:说实话ThreadLocal真不是啥高级的东西

什么是 ThreadLocal？

根本应用

应用案例

ThreadLocal 类和 Synchronized 关键字

Synchronized 同步形式

ThreadLocal 与 Synchronized 的区别

使用场景

转账案例

引入事务

惯例解决办法

惯例解决办法的弊病

应用 ThreadLocal 解决

ThreadLocal 实现的益处

ThreadLocal 的内部结构

常见误会

当初的设计

ThreadLocalMap 源码剖析

根本构造

成员变量

存储构造 – Entry

弱援用和内存透露

内存透露相干概念

弱援用相干概念

如果 key 应用强援用，那么会呈现内存透露？

如果 key 应用弱援用，那么会呈现内存透露？

呈现内存透露的实在起因

为什么要应用弱援用？

站内搜索