ThreadLocal如何解决并发问题

水深无声 2022-11-26 08:42 190阅读 0赞

## 前言 ##

到底什么是线程的不安全？为什么会存在线程的不安全？线程的不安全其实就是多个线程并发的去操作同一共享变量没用做同步所产生意料之外的结果。那是如何体现出来的呢？我们看下面的一个非常经典的例子:两个操作员同时操作同一个银行账户，A操作员存钱，100B操作员取钱50。我们看一下流程。

![format_png][]

两个操作员同时处理，没用做同步这个时候我们发现银行账户最终余额剩余950元，在我们想的最终结果银行账户应该剩余1000+100-50=1050元，在执行过程中我们没有加锁，最终导致了运行结果偏离预期。那么如何解决的？一般的解决措施就是加锁，加同步锁所以这就需要使用者一定要知道锁是什么。我们来看一下加锁之后的效果是不是我们所预期的。

![format_png 1][]

在添加同步锁后我们可以看到，A操作员和B操作员同时去操作账户，但是A先抢占到资源，所以B就只能等待A操作员释放锁才能去操作银行账户，那么最终结果是我们所预期的吗？答案是的。

同步的话一般都是加锁，如果现在我想创建多个线程每个线程都是访问的自己的变量呢？各个线程之间毫无关联？

答案是有的。

## ThreadLocal问题 ##

`ThreadLocal`是JDK提供的，它提供了线程本地变量。什么是线程本地变量呢？其实就是你创建了一个`Threadlocal`变量，每个访问`Threadlocal`变量的线程都有一个本地副本。我们看下面的图：

![format_png 2][]从上面看出你创建一个`ThreadLocal`变量,每个访问该的线程都会复制到自己的本地，所以线程操作的都是本地的副本，这也就是说每个线程都是操作的自己本地的变量，那就完美的避免了线程安全的问题。

在这里还有一个问题。我在写这篇文章的时候看过很多文章，总的来说就是`ThreadLocal`就是为了解决多线程并发问题而提供的一种方法，还有一种解释就是`ThreadLocal`的最终目的就是为了解决多线程访问共享资源所产生的。真的对吗？`ThreadLocal`并没有共享那么从何而来的同步呢？

## 自己的想法 ##

在看了`Java并发编程之美`后我所理解的`Threadlocal`提供了线程本地变量的副本，每个线程实际操作的时自己本地的变量副本，也就是说该变量副本只能当前线程访问，就不存在多个线程共享的问题，从`Threadlocal`名字我们也能看出`本地线程`。那那那它也就不存在去解决并发问题了。

## 如何使用 ##

我们来看下面的例子。

![format_png 3][]

> 输出结果:
> 
> Thread\[Thread-1,5,main\]====57
> 
> Thread\[Thread-0,5,main\]====75

创建了两个线程,它们都在`threadlocal`上面都set了一个随机数,我们看最后得输出结果每个都是不同得值,那么我们如果把`threadlocal`替换成一个集合会发生什么,由于两个线程时上个线程生成的随机数57会被第二个线程覆盖掉,而在`Threadlocal`中两个线程都是操作的自己的本地副本,那么两个线程互不影响都无法操控到对方的数据,因此它们存取的都是不同的值。

## 实现原理 ##

那么`Threadlocal`是如何实现的呢？在研究`Threadlocal`的实现原理我们先看一下`Thread`的内部属性。

![format_png 4][]

*  threadLocals 此线程保存的`Threadlocal`的值

inheritableThreadLocals等到后面再说。

在`Thread`的内部属性中我们看到了这两个默认为null的属性，threadLocals用来保存`Threadlocal`的本地副本，默认是为null只有调用`Threadlocal`的set时才会创建。也就是说`Threadlocal`就类似一个工具，它的作用就是把value的值通过set存在线程每个线程的threadLocals 中，只要线程一直存在threadLocals 也就一直存在。所以当不需要使用本地变量的时候可以调用`Threadlocal`的remove来清空本地变量。而threadLocals 为什么继承鱼ThreadLocalMap呢?ThreadLocalMap是一个定制的HashMap，而使用Map的原因就是可以每个线程关联多个`Threadlocal`变量。

## set方法 ##

我们来看一下set方法是如何实现的。

![format_png 5][]

可以看出流程非常简单，首先获取当前线程然后在进行下一步操作，我们在看一下getMap做了什么

![format_png 6][]

getMap主要就是返回了当前threadLocals的属性。那如果map为空呢？

![format_png 7][]

如果map为空的话就直接创建一个新的ThreadLocalMap。

我们来看一下流程图。

![format_png 8][]

## get方法 ##

看一下Get方法

![format_png 9][]

首先根据当前线程获取实例如果存在就返回，如果不存在就先初始化一个空值，然后判断如果当前threadLoacals不为空就直接set一个空，否则就创建一个变量。

## remove方法 ##

![format_png 10][]

remove方法相对来说比较简单。

## 总结 ##

`Threadlocal`的实现原理其实就是通过set把value set到线程的threadlocals属性中，`threadlocals`类型是Map其中的Key就是`Threadlocal`的this引用，value就是我们所set的值，如果当前线程不销毁的话`threadlocals`会一直存在。一直存在的话可能会造成内存溢出，所以使用完之后尽量remove一下。不过在这里又有一个问题那就是如果我的线程想要读取主线程的变量要怎么做？我们上面的例子都是设置的新创建的线程，那么现在我在主线程中set一个值，这个时候我在新创建的线程中可以读取到吗？答案是不可以，因为`Threadlocal`不支持继承性。

我们看下面的例子：

![format_png 11][]

> 输出结果：
> 
> Thread\[Thread-0,5,main\]====null

也就是说`Threadlocal`不支持继承性，主线程设置了值，在子线程中是获取不到的。那我现在想要获取主线程里面的值要怎么做？

`Threadlocal`是实现不了的，不过`Threadlocal`有一个子类可以实现。`InheritableThreadLocal`，`InheritableThreadLocal`是`Threadlocal`的实现，我们来看一个简单的例子。

![format_png 12][]

> 输出结果：
> 
> Thread\[Thread-0,5,main\]====1000

运行结果发现子线程是可以获取到主线程设置的值的，那它是如何实现的？

我们看一下代码实现：

![format_png 13][]

`InheritableThreadLocal`是继承`Threadlocal`的，并且把`threadlocals`给替换成`inheritableThreadLocals`了所以上面的`inheritableThreadLocals`我要留在最后说，那么替换成`inheritableThreadLocals`后子线程就可以获取到主线程设置的属性了吗？我们在看一下Thread的实现。

![format_png 14][]

看`Thread`的初始化方法可以看出，先获取了当前线程(主线程)判断主线程的`inheritableThreadLocals`不为空的话就调用createInheritedMap方法赋值给子线程中的`inheritableThreadLocals`。具体这里解释太多。有机会在写一篇文章来解释。

## 关于慎用ThreadLocal ##

**使用ThreadLocal要注意remove ！**

ThreadLocal的实现是基于一个所谓的ThreadLocalMap ， 在ThreadLocalMap中，它的key是一个弱引用。通常弱引用都会和引用队列配合清理机制使用，但是ThreadLocal是个例外，它并没有这么做。

这意味着，废弃项目的回收依赖于显式地触发，否则就要等待线程结束，进而回收相应ThreadLocalMap ！这 就 是 很 多

OOM的来源，**所以通常都会建议，应用一定要自己负责remove ， 并 且 不 要 和 线 程 池 配合，因为worker 线 程 往 往 是 不 会 退 出 的 。**

[format_png]: /images/20221124/6e07018013444e54aa8a812fd21d2452.png
[format_png 1]: /images/20221124/896c4ab225274dff9f331d260b8a8417.png
[format_png 2]: /images/20221124/591f2f86373f4aa88ab545218e098f53.png
[format_png 3]: /images/20221124/1d22d6151d3e4533b838b5849836697c.png
[format_png 4]: /images/20221124/236ff55f1ea44c7e9104d752254bc6c2.png
[format_png 5]: /images/20221124/ca8e01c7a30549e2a3ccafdf78ff8c3f.png
[format_png 6]: /images/20221124/9c07e906ce854266b0fe70de1994794b.png
[format_png 7]: /images/20221124/58311030ed5c42f397e0d17bee1fee99.png
[format_png 8]: /images/20221124/5baf5e3466a04b98af3d4c02c3a02688.png
[format_png 9]: /images/20221124/994f4484ee7d4caf95e306560daedee6.png
[format_png 10]: /images/20221124/18df308323be461cab108bc583bf6806.png
[format_png 11]: /images/20221124/b95ec68150c340a588e866d59cc0c7a0.png
[format_png 12]: /images/20221124/656fc94ef80040e09f151c95dd8981cc.png
[format_png 13]: /images/20221124/45a9863fa62d419881f31c0461ba789b.png
[format_png 14]: /images/20221124/65fb22c18d034653b79fd482af89f8d0.png