多线程与并发-ThreadLocal

什么是ThreadLocal?

ThreadLocal 并不是一个线程，而是保存线程本地化对象的容器。当运行于多线程环境的某个对象使用ThreadLocal维护变量时，ThreadLocal提供了get与set等访问接口或方法，为每个使用该变量的线程分配一个独立的变量副本。

我们来看下ThreadLocal的结构，如下图

• 一个线程对应一个ThreadLocalMap ，可以存储多个ThreadLocal对象。get()就是当前线程获取自己的ThreadLocalMap.

• ThreadLocal对象作为key、独享数据作为value。

• ThreadLocalMap可参考HashMap，在ThreadMap里面存在Entry数组也就是一个Entry一个键值对。

• 线程根据使用那一小块的Threadlocal，根据ThreadLocal对象作为key，去获取存储于ThreadLocalMap中的值。

 

 

注意：每个Thread线程内部都有一个Map。Map里面存储key是线程本地对象即ThreadLocal。Thread内部的Map是由ThreadLocal维护的，由ThreadLocal负责向map获取和设置线程的变量值。

对于不同的线程，每次获取副本值时，别的线程并不能获取到当前线程的副本值，形成了副本的隔离，互不干扰。我们可以看到Thread 源码中有 关于ThreadLocal部分 

public class Thread implements Runnable {    /* ThreadLocal values pertaining to this thread. This map is maintained     * by the ThreadLocal class. */    ThreadLocal.ThreadLocalMap threadLocals = null;}

关于Thread、ThreadLocal、ThreadLocalMap具体的关系，可以看下面这张图。

 

因为ThreadLocal实例实际上也是被其创建的类持有（更顶端应该是被线程持有）。而ThreadLocal的值其实也是被线程实例持有。

它们都是位于堆上，只是通过一些技巧将可见性修改成了线程可见。

 

ThreadLocal 的作用是什么？

防止任务在共享资源上产生冲突，防止对可变的单实例变量或全局变量进行共享。线程本地存储是一种自动化机制，可以为使用相同变量的每个不同的线程都创建不同的存储。

从前面的介绍里我们能知道 ThreadLocal是一个本地线程副本变量工具类。主要用于将私有线程和该线程存放的副本对象做一个映射，各个线程之间的变量互不干扰，在高并发场景下，可以实现无状态的调用，特别适用于各个线程依赖不同的变量值完成操作的场景。

ThreadLocal 可以维持线程封闭性，这个类能使线程中的某个值与保存值的对象关联起来。ThreadLocal提供了get与set等访问接口或方法，这些方法为每个使用该变量的线程都存有一份独立的副本，因此get总是返回由当前线程在调用set时设置的最新值。通常用于防止对可变的单实例变量或全局变量进行的共享。

当某个频繁执行的操作需要一个临时对象，例如一个缓冲区，而同时又希望避免在每次执行时都重新分配该临时对象，就可使用该技术。

 

下面我们就来通过源码，分析ThreadLocal一些常用的方法。

首先是get() 方法。get()方法用于获取当前线程的副本变量值。 ThreadLocal.set()、ThreadLocal.get()方法，就相当于把数据存储于线程本地，取也是在本地内存读取。就不会像synchronized需要频繁的修改主内存的数据，再把数据复制到工作内存，也大大提高访问效率。

 

• 获取当前线程的ThreadLocalMap对象threadLocals

• 从map中获取线程存储的K-V Entry节点。

• 从Entry节点获取存储的Value副本值返回。

• map为空的话返回初始值null，即线程变量副本为null，在使用时需要注意判断NullPointerException。

public T get() {    Thread t = Thread.currentThread();    ThreadLocalMap map = getMap(t);    if (map != null) {        ThreadLocalMap.Entry e = map.getEntry(this);        if (e != null)            return (T)e.value;    }    return setInitialValue();}
ThreadLocalMap getMap(Thread t) {    return t.threadLocals;}
private T setInitialValue() {    T value = initialValue();    Thread t = Thread.currentThread();    ThreadLocalMap map = getMap(t);    if (map != null)        map.set(this, value);    else        createMap(t, value);    return value;}
protected T initialValue() {    return null;}

 

我们要注意的是

• 一个线程对应一个ThreadLocalMap，get()就是当前线程获取自己的ThreadLocalMap。

• 线程根据使用那一小块的threadlocal，根据ThreadLocal对象作为key，去获取存储于ThreadLocalMap中的值。

接下来是 set() 方法。set()方法用于保存当前线程的副本变量值。

• 获取当前线程的成员变量map

• map非空，则重新将ThreadLocal和新的value副本放入到map中。

• map空，则对线程的成员变量ThreadLocalMap进行初始化创建，并将ThreadLocal和value副本放入map中。

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);}

还有些常用的方法，比如initialValue()为当前线程初始副本变量值、remove()方法移除当前前程的副本变量值。就不逐一进行分析了。

 

ThreadLocalMap 内部结构

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

在ThreadLocalMap中，也是用Entry来保存K-V结构数据的。但是Entry中key只能是ThreadLocal对象，这点被Entry的构造方法已经限定死了。这里大家可以看到，继承的是 WeakReference 对象，后面会讲到。

static class Entry extends WeakReference<ThreadLocal> {    /** The value associated with this ThreadLocal. */    Object value;    Entry(ThreadLocal k, Object v) {        super(k);        value = v;    }}

如何解决Hash冲突

和HashMap的最大的不同在于，ThreadLocalMap结构非常简单，没有next引用，也就是说ThreadLocalMap中解决Hash冲突的方式并非链表的方式，而是采用线性探测的方式，所谓线性探测，就是根据初始key的hashcode值确定元素在table数组中的位置，如果发现这个位置上已经有其他key值的元素被占用，则利用固定的算法寻找一定步长的下个位置，依次判断，直至找到能够存放的位置。

ThreadLocalMap解决Hash冲突的方式就是简单的步长加1或减1，寻找下一个相邻的位置。ThreadLocalMap采用线性探测的方式解决Hash冲突的效率很低，如果有大量不同的ThreadLocal对象放入map中时发送冲突，或者发生二次冲突，则效率很低。

如果每个线程只存一个变量，这样的话所有的线程存放到map中的Key都是相同的ThreadLocal，如果一个线程要保存多个变量，就需要创建多个ThreadLocal，多个ThreadLocal放入Map中时会极大的增加Hash冲突的可能。

 

ThreadLocal 内存泄露问题

上面写到， Entry继承的是 WeakReference 对象。由于ThreadLocalMap的key是弱引用，而Value是强引用。这就导致了一个问题，ThreadLocal在没有外部对象强引用时，发生GC时弱引用Key会被回收，而Value不会回收，如果创建ThreadLocal的线程一直持续运行，那么这个Entry对象中的value就有可能一直得不到回收，发生内存泄露。

只要这个线程对象被gc回收，就不会出现内存泄露，但在threadLocal设为null和线程结束这段时间不会被回收的，就发生了我们认为的内存泄露。最要命的是线程对象不被回收的情况，这就发生了真正意义上的内存泄露。比如使用线程池的时候，线程结束是不会销毁的，会再次使用的。就可能出现内存泄露。

 

如何避免泄漏

既然Key是弱引用，那么我们要做的事，就是在调用ThreadLocal的get()、set()方法时完成后再调用remove方法，将Entry节点和Map的引用关系移除，这样整个Entry对象在GC Roots分析后就变成不可达了，下次GC的时候就可以被回收

ThreadLocal<Ingeger> threadLocal = new ThreadLocal<Integer>();try {    threadLocal.set(1);    // 其它业务逻辑} finally {    threadLocal.remove();}

 

在ThreadLocalMap中的set/getEntry方法中，会对key为null（也即是ThreadLocal为null）进行判断，如果为null的话，那么是会对value置为null的。 怕的情况就是，threadLocal对象设null了，开始发生“内存泄露”，然后使用线程池，这个线程结束，线程放回线程池中不销毁，这个线程一直不被使用，或者分配使用了又不再调用get,set方法，那么这个期间就会发生真正的内存泄露。 

Threadlocal里面使用了一个存在弱引用的map,当释放掉threadlocal的强引用以后,map里面的value却没有被回收.而这块value永远不会被访问到了. 所以存在着内存泄露. 最好的做法是将调用threadlocal的remove方法。

总结

• JVM利用设置ThreadLocalMap的Key为弱引用，来避免内存泄露。

• JVM利用调用remove、get、set方法的时候，回收弱引用。

• 当ThreadLocal存储很多Key为null的Entry的时候，而不再去调用remove、get、set方法，那么将导致内存泄漏。

• 当使用static ThreadLocal的时候，延长ThreadLocal的生命周期，那也可能导致内存泄漏。因为，static变量在类未加载的时候，它就已经加载，当线程结束的时候，static变量不一定会回收。那么，比起普通成员变量使用的时候才加载，static的生命周期加长将更容易导致内存泄漏危机。

   

那为什么ThreadLocalMap的key使用弱引用的ThreadLcal对象？

1. Key使用强引用：也就是上述说的情况，引用 ThreadLocal 的对象被回收了，ThreadLocal 的引用ThreadLocalMap 的 Key 为强引用并没有被回收，如果不手动回收的话，ThreadLocal将不会回收那么将导致内存泄漏。

2. Key使用弱引用：引用的ThreadLocal的对象被回收了，ThreadLocal 的引用 ThreadLocalMap 的 Key 为弱引用，如果内存回收，那么将 ThreadLocalMap 的 Key 将会被回收，ThreadLocal 也将被回收。value在 ThreadLocalMap 调用get、set、remove的时候就会被清除。

3. 比较两种情况，我们可以发现：由于ThreadLocalMap的生命周期跟Thread一样长，如果都没有手动删除对应key，都会导致内存泄漏，但是使用弱引用可以多一层保障：弱引用ThreadLocal不会内存泄漏，对应的value在下一次ThreadLocalMap调用set,get,remove的时候会被清除。

 

应用场景举例

每个线程访问数据库都应当是一个独立的Session会话，如果多个线程共享同一个Session会话，有可能其他线程关闭连接了，当前线程再执行提交时就会出现会话已关闭的异常，导致系统异常。此方式能避免线程争抢Session，提高并发下的安全性。

private static final ThreadLocal<Session> threadLocal = new ThreadLocal<Session>();//获取Sessionpublic static Session getCurrentSession(){    Session session =  threadLocal.get();    //判断Session是否为空，如果为空，将创建一个session，并设置到本地线程变量中    try {        if(session ==null&&!session.isOpen()){            if(sessionFactory==null){                rbuildSessionFactory();// 创建Hibernate的SessionFactory            }else{                session = sessionFactory.openSession();            }        }        threadLocal.set(session);    } catch (Exception e) {        // TODO: handle exception    }    return session;}

 

ThreadLocal 与 Thread 同步机制的比较

ThreadLocal 与 线程同步机制都是为了解决多线程中相同变量的访问冲突问题。

在同步机制中，通过对象的锁机制保证同一时间只有一个线程访问变量。这时该变量是多个线程共享的，使用同步机制要求程序缜密地分析什么时候对变量进行读/写、什么时候需要锁定某个对象、什么时候释放对象所等繁杂的问题，程序设计难度较大。

而ThreadLocal 从另一个角度来解决多线程的并发问题。ThreadLocal 为每个线程提供了一个独立的变量副本，从而隔离了多个线程对访问数据的冲突。因为每个线程都拥有自己的变量副本，因而也就没有必要对改变量进行同步。ThreadLocal 提供了线程安全的对象封装，在编写多线程代码时，可以把不安全的变量封装进ThreadLocal。

对多线程共享资源

同步机制：以时间换空间、访问串行化、对象共享化。仅提供一份变量，让不同的线程排队访问。

ThreadLocal：以空间换时间、访问并行化、对象独享化。为每个线程都提供了一份变量，可以同时访问互不影响

 

欢迎关注公众号，让我们一起学习探讨问题