单例模式多线程不安全，浅解析ThreadLocal类

最新推荐文章于 2024-04-14 11:13:55 发布

向你跑

最新推荐文章于 2024-04-14 11:13:55 发布

阅读量1.9k

点赞数

分类专栏： java

本文链接：https://blog.csdn.net/qq_42217505/article/details/82053302

版权

java 专栏收录该内容

10 篇文章 0 订阅

订阅专栏

1、单例模式下出现的安全问题

先看下面小段代码，一个controller，一个service。

   controller.Java代码：
……..
@Autowired
 private XXXService xxxService;
……..
@RequestMapping(“/doXXX.do”)
public void doXXX(){
    …..
    xxxService.saveXXX(String content,….);
    …..
}
XXXService.java代码：
private String content；
……
private void init(){//清空请求参数
    content = null;
    ……
}
public boolean saveXXX(String content, ……){
    this.init(content, …);
    this.content = content;
    //业务逻辑处理
｝

以上这段代码在访问量不构成并发时不会出现什么问题。但当一个请求还未完成，另一个请求已经开始执行的情况下就会出现问题（并发）：第二个请求执行执行init()方法会将第一个请求的content变量设置为null或它本身的值，这样数据就被篡改了。
编码者这样写的目的是因为content等变量需要在多个方法中使用，而且变量很多，但又不想通过方法参数的方式来传递，故使用成员变量。
先看看为什么会出现这种情况。由于系统采用springmvc框架，springmvc核心控制器DispatcherServlet 默认为每个controller生成单一实例来处理所有用户请求，所以在这个单一实例的controller中，它的XXXService也是一个实例处理所有请求，这样XXXService的成员变量就被所有请求共享。这样就会出现并发请求时变量内容被篡改的问题。
那么出现这种问题如何解决呢？
第一种方式：既然是全局变量惹的祸，那就将全局变量都编程局部变量，通过方法参数来传递。
第二种方式： jdk提供了java.lang.ThreadLocal,它为多线程并发提供了新思路。（当使用ThreadLocal维护变量时，ThreadLocal为每个使用该变量的线程提供独立的变量副本，所以每一个线程都可以独立地改变自己的副本，而不会影响其它线程所对应的副本）
那么在什么地方使用ThreadLocal呢？什么变量是请求公用的就将该变量托付给ThreadLocal来管理其线程副本，所以我们在xxxService中使用它。
XXXService.java代码：
private ThreadLocal contentTL = new ThreadLocal();
//private String content；使用contentTL代替content;
……
public boolean saveXXX(String content, ……){
this.contentTL.set(content);
//业务逻辑处理
//在各方法中使用content时候用this.contentTL.get()代替
｝
此类并发篡改数据的问题，可以在开发工具中设置断点调试的方式来模拟并发。即第一次请求运行到断点时，查看content内容，并且不让程序继续往下运行，同时再发起一个请求，查看content内容。如内容是第一次请求的内容，并且让第一个请求跑完后，第二个请求到断线处的content正确时，可以确定不会出现并发问题。

2、浅解析ThreadLocal

在上面谈到了对ThreadLocal的一些理解，那我们下面来看一下具体ThreadLocal是如何实现的。

　　先了解一下ThreadLocal类提供的几个方法：

public T get() { }
public void set(T value) { }
public void remove() { }
protected T initialValue() { }

　　get()方法是用来获取ThreadLocal在当前线程中保存的变量副本，set()用来设置当前线程中变量的副本，remove()用来移除当前线程中变量的副本，initialValue()是一个protected方法，一般是用来在使用时进行重写的，它是一个延迟加载方法，下面会详细说明。

　　首先我们来看一下ThreadLocal类是如何为每个线程创建一个变量的副本的。

　　先看下get方法的实现：
这里写图片描述

第一句是取得当前线程，然后通过getMap(t)方法获取到一个map，map的类型为ThreadLocalMap。然后接着下面获取到key,value键值对，注意这里获取键值对传进去的是 this，而不是当前线程t。
　　如果获取成功，则返回value值。
　　如果map为空，则调用setInitialValue方法返回value。
　　我们上面的每一句来仔细分析：
　　首先看一下getMap方法中做了什么：
这里写图片描述
可能大家没有想到的是，在getMap中，是调用当期线程t，返回当前线程t中的一个成员变量threadLocals。
　　那么我们继续取Thread类中取看一下成员变量threadLocals是什么：

实际上就是一个ThreadLocalMap，这个类型是ThreadLocal类的一个内部类，我们继续取看ThreadLocalMap的实现：
这里写图片描述
可以看到ThreadLocalMap的Entry继承了WeakReference，并且使用ThreadLocal作为键值。

　　然后再继续看setInitialValue方法的具体实现：
这里写图片描述

3、ThreadLocal的应用场景及使用

尽管ThreadLocal与并发问题相关，可是很多程序猿只将它作为一种用于“方便传參”的工具，觉得这或许并非ThreadLocal设计的目的，它本身是为线程安全和某些特定场景的问题而设计的。
ThreadLocal是什么呢。
每一个ThreadLocal能够放一个线程级别的变量，可是它本身能够被多个线程共享使用，并且又能够达到线程安全的目的，且绝对线程安全。
比如：

public final static ThreadLocal RESOURCE = new ThreadLocal();
RESOURCE代表一个能够存放String类型的ThreadLocal对象。此时不论什么一个线程能够并发訪问这个变量，对它进行写入、读取操作，都是线程安全的。比方一个线程通过RESOURCE.set(“aaaa”);将数据写入ThreadLocal中，在不论什么一个地方，都能够通过RESOURCE.get();将值获取出来。
可是它也并不完美，有很多缺陷，就像大家依赖于它来做參数传递一样。接下来我们就来分析它的一些不好的地方。
为什么有些时候会将ThreadLocal作为方便传递參数的方式呢？比如当很多方法相互调用时，最初的设计可能没有想太多，有多少个參数就传递多少个变量，那么整个參数传递的过程就是零散的。进一步思考：若A方法调用B方法传递了8个參数。B方法接下来调用C方法->D方法->E方法->F方法等仅仅须要5个參数，此时在设计API时就涉及5个參数的入口。这些方法在业务发展的过程中被很多地方所复用。
某一天。我们发现F方法须要加一个參数，这个參数在A方法的入口參数中有，此时，假设要改中间方法牵涉面会非常大。并且不知道改动后会不会有Bug。
作为程序猿的我们可能会随性一想，ThreadLocal反正是全局的，就放这里吧。确实好解决。
可是此时你会发现系统中这样的方式有点像在贴补丁。越贴越多，我们必需要求调用相关的代码都使用ThreadLocal传递这个參数，有可能会搞得乱七八糟的。换句话说，并非不让用。而是我们要明白它的入口和出口是可控的。
诡异的ThreadLocal最难琢磨的是“作用域”，尤其是在代码设计之初非常乱的情况下，假设再添加很多ThreadLocal。系统就会逐渐变成神龙见首不见尾的情况。有了这样一个省事的东西。可能很多小伙伴更加不在意设计，由于大家都觉得这些问题都能够通过变化的手段来解决。胖哥觉得这是一种恶性循环。
对于这类业务场景。应当提前有所准备。须要粗粒度化业务模型。即使要用ThreadLocal，也不是加一个參数就加一个ThreadLocal变量。比如，我们能够设计几种对象来封装入口參数，在接口设计时入口參数都以对象为基础。

或许一个类无法表达全部的參数意思，并且那样easy导致强耦合。
通常我们依照业务模型分解为几大类型对象作为它们的參数包装，而且将依照对象属性共享情况进行抽象，在继承关系的每个层次各自扩展对应的參数，或者说加參数就在对象中加，共享參数就在父类中定义，这种參数就逐步规范化了。
我们回到正题，探讨一下ThreadLocal究竟是用来做什么的？为此我们探讨下文中的几个话题。
应用场景及使用方式
为了说明ThreadLocal的应用场景。我们来看一个框架的样例。Spring的事务管理器通过AOP切入业务代码，在进入业务代码前，会依据相应的事务管理器提取出相应的事务对象，假如事务管理器是DataSourceTransactionManager，就会从DataSource中获取一个连接对象，通过一定的包装后将其保存在ThreadLocal中。而且Spring也将DataSource进行了包装，重写了当中的getConnection()方法，或者说该方法的返回将由Spring来控制，这样Spring就能让线程内多次获取到的Connection对象是同一个。
为什么要放在ThreadLocal里面呢？由于Spring在AOP后并不能向应用程序传递參数。应用程序的每一个业务代码是事先定义好的，Spring并不会要求在业务代码的入口參数中必须编写Connection的入口參数。此时Spring选择了ThreadLocal，通过它保证连接对象始终在线程内部，不论什么时候都能拿到，此时Spring很清楚什么时候回收这个连接，也就是很清楚什么时候从ThreadLocal中删除这个元素

从Spring事务管理器的设计上能够看出。Spring利用ThreadLocal得到了一个非常完美的设计思路，同一时候它在设计时也十分清楚ThreadLocal中元素应该在什么时候删除。由此，我们简单地觉得ThreadLocal尽量使用在一个全局的设计上。而不是一种打补丁的间接方法。
了解了基本应用场景后，接下来看一个样例。定义一个类用于存放静态的ThreadLocal对象，通过多个线程并行地对ThreadLocal对象进行set、get操作，并将值进行打印。来看看每一个线程自己设置进去的值和取出来的值是否是一样的。

代码例如以下：
代码清单5-8 简单的ThreadLocal样例

public class ThreadLocalTest {

static class ResourceClass {

    public final static ThreadLocal<String> RESOURCE_1 =
                                   new ThreadLocal<String>();

    public final static ThreadLocal<String> RESOURCE_2 =
                                   new ThreadLocal<String>();

}

static class A {

    public void setOne(String value) {
        ResourceClass.RESOURCE_1.set(value);
    }

    public void setTwo(String value) {
        ResourceClass.RESOURCE_2.set(value);
    }
}

static class B {
    public void display() {
        System.out.println(ResourceClass.RESOURCE_1.get()
                    + ":" + ResourceClass.RESOURCE_2.get());
    }
}

public static void main(String []args) {
    final A a = new A();
    final B b = new B();
    for(int i = 0 ; i < 15 ; i ++) {
        final String resouce1 = "线程-" + I;
        final String resouce2 = " value = (" + i + ")";
        new Thread() {
            public void run() {
            try {
                a.setOne(resouce1);
                a.setTwo(resouce2);
                b.display();
            }finally {
                ResourceClass.RESOURCE_1.remove();
                ResourceClass.RESOURCE_2.remove();
            }
        }
    }.start();
    }
}

}
关于这段代码，我们先说几点。

◎ 定义了两个ThreadLocal变量。终于的目的就是要看最后两个值能否相应上。这样才有机会证明ThreadLocal所保存的数据可能是线程私有的。

◎ 使用两个内部类仅仅是为了使測试简单，方便大家直观理解，大家也能够将这个样例的代码拆分到多个类中，得到的结果是同样的。
◎ 測试代码更像是为了方便传递參数。由于它确实传递參数非常方便，但这不过为了測试。
◎ 在finally里面有remove()操作，是为了清空数据而使用的。

为何要清空数据，在后文中会继续介绍细节。

測试结果例如以下：
线程-6: value = (6)
线程-9: value = (9)
线程-0: value = (0)
线程-10: value = (10)
线程-12: value = (12)
线程-14: value = (14)
线程-11: value = (11)
线程-3: value = (3)
线程-5: value = (5)
线程-13: value = (13)
线程-2: value = (2)
线程-4: value = (4)
线程-8: value = (8)
线程-7: value = (7)
线程-1: value = (1)
大家能够看到输出的线程顺序并不是最初定义线程的顺序，理论上能够说明多线程应当是并发运行的，可是依旧能够保持每一个线程里面的值是相应的，说明这些值已经达到了线程私有的目的。
不是说共享变量无法做到线程私有吗？它又是怎样做到线程私有的呢？这就须要我们知道一点点原理上的东西。否则用起来也没那么放心，具体ThreadLocal类上面已经介绍完毕。

4、ThreadLocal的坑

通过上面的分析。我们能够认识到ThreadLocal事实上是与线程绑定的一个变量，如此就会出现一个问题：假设没有将ThreadLocal内的变量删除（remove）或替换，它的生命周期将会与线程共存。
因此，ThreadLocal的一个非常大的“坑”就是当使用不当时，导致使用者不知道它的作用域范围。
大家可能觉得线程结束后ThreadLocal应该就回收了。假设线程真的注销了确实是这种，可是事实有可能并不是如此。比如在线程池中对线程管理都是採用线程复用的方法（Web容器通常也会採用线程池）。在线程池中线程非常难结束甚至于永远不会结束。这将意味着线程持续的时间将不可预測，甚至与JVM的生命周期一致。

那么对应的ThreadLocal变量的生命周期也将不可预測。
或许系统中定义少量几个ThreadLocal变量也无所谓。由于每次set数据时是用ThreadLocal本身作为Key的，同样的Key肯定会替换原来的数据。原来的数据就能够被释放了，理论上不会导致什么问题。但世事无绝对，假设ThreadLocal中直接或间接包装了集合类或复杂对象，每次在同一个ThreadLocal中取出对象后，再对内容做操作，那么内部的集合类和复杂对象所占用的空间可能会開始膨胀。
抛开代码本身的问题。举一个极端的样例。假设不想定义太多的ThreadLocal变量，就用一个HashMap来存放，这貌似没什么问题。由于ThreadLocal在程序的不论什么一个地方都能够用得到，在某些设计不当的代码中非常难知道这个HashMap写入的源头，在代码中为了保险起见。一般会先检查这个HashMap是否存在，若不存在，则创建一个HashMap写进去。若存在，通常也不会替换掉。由于代码编写者一般会“害怕”由于这样的替换会丢掉一些来自“其它地方写入HashMap的数据”。从而导致很多不可预见的问题。
在这种情况下。HashMap第一次放入ThreadLocal中或许就一直不会被释放，而这个HashMap中可能開始存放很多Key-Value信息，假设业务上存放的Key值在不断变化（比如，将业务的ID作为Key），那么这个HashMap就開始不断变长，并且非常可能在每一个线程中都有一个这种HashMap，逐渐地形成了间接的内存泄漏。以前有非常多人吃过这个亏，并且吃亏的时候发现这种代码可能不是在自己的业务系统中。而是出如今某些二方包、三方包中（开源并不保证没有问题）。
要处理这样的问题非常复杂，只是首先要保证自己编写的代码是没问题的。要保证没问题不是说我们不去用ThreadLocal。甚至不去学习它。由于它肯定有其应用价值。在使用时要明确ThreadLocal最难以捉摸的是“不知道哪里是源头”（一般是代码设计不当导致的），仅仅有知道了源头才干控制结束的部分。或者说我们从设计的角度要让ThreadLocal的set、remove有始有终，通常在外部调用的代码中使用finally来remove数据，仅仅要我们细致思考和抽象是能够达到这个目的的。有些是二方包、三方包的问题，对于这些问题我们须要学会的是找到问题的根源后解决，关于二方包、三方包的执行跟踪，可參看第3.7.9节介绍的BTrace工具。

补充：在不论什么异步程序中（包含异步I/O、非堵塞I/O），ThreadLocal的參数传递是不靠谱的，由于线程将请求发送后。就不再等待远程返回结果继续向下运行了，真正的返回结果得到后，处理的线程可能是还有一个。

###############################个人总结

Thread.java源代码中:

ThreadLocal.ThreadLocalMap threadLocals = null;
即:每一个Thread对象都有一个ThreadLocal.ThreadLocalMap成员变量,ThreadLocal.ThreadLocalMap是一个ThreadLocal类的静态内部类(例如以下所看到的),所以Thread类能够进行引用.
static class ThreadLocalMap {
所以每一个线程都会有一个ThreadLocal.ThreadLocalMap对象的引用
当在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;
}

首先获取当前线程的引用,然后获取当前线程的ThreadLocal.ThreadLocalMap对象(t.threadLocals变量就是ThreadLocal.ThreadLocalMap的变量),假设该对象为空就创建一个,例如以下所看到的:
void createMap(Thread t, T firstValue) {
t.threadLocals = new ThreadLocalMap(this, firstValue);
}
这个this变量就是ThreadLocal的引用,对于同一个ThreadLocal对象每一个线程都是同样的,可是每一个线程各自有一个ThreadLocal.ThreadLocalMap对象保存着各自ThreadLocal引用为key的值,所以互不影响,并且:假设你新建一个ThreadLocal的对象,这个对象还是保存在每一个线程同一个ThreadLocal.ThreadLocalMap对象之中,由于一个线程仅仅有一个ThreadLocal.ThreadLocalMap对象,这个对象是在第一个ThreadLocal第一次设值的时候进行创建,如上所述的createMap方法.
ThreadLocalMap(ThreadLocal firstKey, Object firstValue) {
table = new Entry[INITIAL_CAPACITY];
int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
table[i] = new Entry(firstKey, firstValue);
size = 1;
setThreshold(INITIAL_CAPACITY);
}

5、总结:

深入研究java.lang.ThreadLocal类:http://blog.csdn.net/xiaohulunb/article/details/19603611

API说明:

ThreadLocal(),T get(),protected T initialValue(),void remove(),void set(T value)

典型实例:

1.Hiberante的Session 工具类HibernateUtil

2.通过不同的线程对象设置Bean属性，保证各个线程Bean对象的独立性。

ThreadLocal使用的一般步骤:

1、在多线程的类（如ThreadDemo类）中。创建一个ThreadLocal对象threadXxx，用来保存线程间须要隔离处理的对象xxx。
2、在ThreadDemo类中。创建一个获取要隔离訪问的数据的方法getXxx()，在方法中推断，若ThreadLocal对象为null时候，应该new()一个隔离訪问类型的对象，并强制转换为要应用的类型。
3、在ThreadDemo类的run()方法中。通过getXxx()方法获取要操作的数据。这样能够保证每一个线程相应一个数据对象，在不论什么时刻都操作的是这个对象。
与Synchonized的对照:

ThreadLocal和Synchonized都用于解决多线程并发訪问。可是ThreadLocal与synchronized有本质的差别。synchronized是利用锁的机制，使变量或代码块在某一时该仅仅能被一个线程訪问。而ThreadLocal为每个线程都提供了变量的副本，使得每个线程在某一时间訪问到的并非同一个对象，这样就隔离了多个线程对数据的数据共享。而Synchronized却正好相反，它用于在多个线程间通信时可以获得数据共享。

Synchronized用于线程间的数据共享，而ThreadLocal则用于线程间的数据隔离。

向你跑

关注

0
点赞
踩
5

收藏

觉得还不错? 一键收藏
0
评论
单例模式多线程不安全，浅解析ThreadLocal类

1、单例模式下出现的安全问题先看下面小段代码，一个controller，一个service。 controller.Java代码：……..@Autowired private XXXService xxxService;……..@RequestMapping(“/doXXX.do”)public void doXXX(){ ….. xxxServ...
复制链接

扫一扫