ThreadLocal初步探秘

ThreadLocal是什么？

ThreadLocal是java语言实现的一种线程本地存储的方式,有时候我们会遇到这样一种需求:每条线程都要去存取一个同名的变量,但是每条线程中该变量的值都是不一样的,那么如果让我们去实现的话,会采用什么方式去实现呢? 也许你会认为你可以去使用一个线程共享的Map, 其中Map中的key为线程对象而value则是我们需要存储的值,然后通过map.get(Thread.currentThread())来获取本线程中该变量的值.

如果不考虑同步和效率的问题的话,这种实现方式是完全可以的,但是,问题的关键在于,如果有很多线程进行操作这个Map呢?为了保证线程的安全性,势必要对Map进行加锁,每当有一个线程在操作这个map时,其他线程只能去等待锁资源的释放,这种性能是我们不能够容忍的。

也许你会反驳说我们可以使用java.util.concurrenct.*包下面的ConcurrencyHashMap来提高并发率,但是它只是降低了锁的粒度,并没有从根本上避免同步锁,而jdk提供的ThreadLocal则很好的解决了这个问题。

我们首先先来看一下ThreadLocal的简单用法

//为不同的线程关联不同的用户ID
public class ThreadLocalDemo {

    private static volatile ThreadLocal userID = new ThreadLocal<>();

    public static void main(String[] args) {

        Runnable r = new Runnable() {
            @Override
            public void run() {
                String name = Thread.currentThread().getName();
                if (name.equals("A")){
                    userID.set("aaaaaaa");
                }else if (name.equals("B")){
                    userID.set("bbbbbbb");
                }


                System.out.println("ThreadName:"+name+" userID: "+userID.get());

            }
        };

        Thread t1 = new Thread(r);
        Thread t2 = new Thread(r);
        t1.setName("A");
        t2.setName("B");
        t1.start();
        t2.start();
    }

}

输出结果

ThreadName:A userID: aaaaaaa
ThreadName:B userID: bbbbbbb

从这个例子中我们可以看出,虽然说是共享了同一个ThreadLocal,但是对于每一个线程来说,它们可以存储自己的值,不同线程存储的内容互不相干。

看完了ThreadLocal的简单用法之后,让我们再去探索一下ThreadLocal的使用原理

我使用的是jdk1.8,通过分析源码我们可以发现,不同线程和本地存储的变量值的映射关系是由一个称之为ThreadLoaclMap的类来实现的,从名字中我们可以看出,它是一个Map,对于Map来说,就应该有键值对,现在我们已经知道值是我们存储的变量值了,那么键是什么呢？这可能跟我们最初的想法不一样,它的键并不是我们原以为的Thread对象,而是一个ThreadLocal。那你可能会产生疑问,那它又是怎样实现Thread和value的关联的呢？

在这里它采用的方式是由Thread类来管理ThreadLocalMap对象.

打开Thread.class我们可以看到, Thread类持有一个ThreadLocalMap

threadlocalmap.png

从类型的定义来看,我们可以看出ThreadLocalMap是ThreadLocal的内部类,那么这个内部类又是怎么定义的呢?让我们进入ThreadLocal的源码实现去看一下

 static class ThreadLocalMap {
  
        static class Entry extends WeakReference> {
            /** The value associated with this ThreadLocal. */
            Object value;

            Entry(ThreadLocal k, Object v) {
                super(k);
                value = v;
            }
        }
      private Entry[] table;

    //.......省略以下代码

 }

从这里我们可以看出来,ThreadLocalMap是由一个Entry数组table构成的,也就是说,是由一个一个的Entry构成的,我们还可以发现,Entry继承了 WeakReference,在构造Entry的时候也调用了super(k),这里为什么会牵扯到弱引用呢?这跟使用ThreadLocal可能会造成的内存泄露的风险有关系,如果key是弱引用,当没有指向key的强引用后,在进行垃圾回收时,就会把这个key回收掉,至于具体的原因,我们会到后面进行分析。

大体结构我们应该清楚了,也就是说,ThreadLocalMap实际存储本地值,ThreadLocalMap是ThreadLocal的一个静态内部类,ThreadLocal实例的set(),get()等方法是对ThreadLocalMap的实际操作来设置线程本地存储的值和获取该值,而ThreadLocalMap又是由Thread来管理的。。。到了这里你如果没有被绕晕,那么恭喜你到目前为止的内容你大概都理解了,如果被绕晕的话,也没关系,我们还有下面这一张图。

ThreadLocal.jpg

这样一来,Thread,ThreadLocalMap,ThreadLocal这三者的关系我们已经清楚了,那么ThreadLocal是怎样具体实现对本地存储值的set()和get()呢？

继续从源码开始探究。。

public void set(T value) {
    //当执行set方法的时候,首先会获取当前线程的对象
    Thread t = Thread.currentThread();
    //根据线程对象获取指定线程里面持有的ThreadLocalMap
    ThreadLocalMap map = getMap(t);
    //如果我们获取到了map,这个map存在不为空
    if (map != null)
        //对map进行set操作,key为调用该set方法的ThreadLocal对象,值为我们需要存储的值
        map.set(this, value);
    else
        //如果map为空,则调用createMap()来创建一个
        createMap(t, value);
}

public T get() {
    //首先获得当前线程
    Thread t = Thread.currentThread();
     //根据线程对象获取指定线程里面持有的ThreadLocalMap
    ThreadLocalMap map = getMap(t);
      //如果我们获取到了map,这个map存在不为空
    if (map != null) {
        //以调用该方法的ThreadLocal对象,也就是this为key,获取Entry
        ThreadLocalMap.Entry e = map.getEntry(this);
        //如果获取的Entry不为空
        if (e != null) {
            @SuppressWarnings("unchecked")
            //获取Entry的value值返回
            T result = (T)e.value;
            return result;
        }
    }
    //如果为空,调用setInitialValue()并返回
    return setInitialValue()并返回
}

//根据线程对象获取指定线程里面持有的ThreadLocalMap
ThreadLocalMap getMap(Thread t) {
    return t.threadLocals;
}

由于每一条线程均含有各自私有的ThreadLocalMap容器，这些容器相互独立互不影响，因此不会存在线程安全性问题，从而也无需使用同步机制来保证多条线程访问容器的互斥性。

关注一下ThreadLocal内存泄露的问题

在ThreadLocalMap中，只有key是弱引用，value仍然是一个强引用。当某一条线程中的ThreadLocal使用完毕，没有强引用指向它的时候，这个key指向的对象就会被垃圾收集器回收，从而这个key就变成了null；然而，此时value和value指向的对象之间仍然是强引用关系，只要这种关系不解除，value指向的对象永远不会被垃圾收集器回收，从而导致内存泄漏！

不过不用担心，ThreadLocal提供了这个问题的解决方案。

每次操作set、get、remove操作时，ThreadLocal都会将key为null的Entry删除，从而避免内存泄漏。

那么问题又来了，如果一个线程运行周期较长，而且将一个大对象放入LocalThreadMap后便不再调用set、get、remove方法，此时该仍然可能会导致内存泄漏。

这个问题确实存在，没办法通过ThreadLocal解决，而是需要程序员在完成ThreadLocal的使用后要养成手动调用remove的习惯，从而避免内存泄漏。

ThreadLocal的 应用场景

1.Web系统Session的存储就是ThreadLocal一个典型的应用场景。

Web容器采用线程隔离的多线程模型，也就是每一个请求都会对应一条线程，线程之间相互隔离，没有共享数据。这样能够简化编程模型，程序员可以用单线程的思维开发这种多线程应用。

当请求到来时，可以将当前Session信息存储在ThreadLocal中，在请求处理过程中可以随时使用Session信息，每个请求之间的Session信息互不影响。当请求处理完成后通过remove方法将当前Session信息清除即可。

2.Spring的事务管理器通过AOP切入业务代码，在进入业务代码前，会根据对应的事务管理器提取出相应的事务对象,为了获得同一个Connection,Spring在这里也巧妙利用了ThreadLocal的特性

假如事务管理器是DataSourceTransactionManager，就会从DataSource中获取一个连接对象，通过一定的包装后将其保存在ThreadLocal中。并且Spring也将DataSource进行了包装，重写了其中的getConnection()方法，或者说该方法的返回将由Spring来控制，这样Spring就能让线程内多次获取到的Connection对象是同一个。

为什么要放在ThreadLocal里面呢？因为Spring在AOP后并不能向应用程序传递参数，应用程序的每个业务代码是事先定义好的，Spring并不会要求在业务代码的入口参数中必须编写Connection的入口参数。此时Spring选择了ThreadLocal，通过它保证连接对象始终在线程内部，任何时候都能拿到，此时Spring非常清楚什么时候回收这个连接，也就是非常清楚什么时候从ThreadLocal中删除这个元素

该篇博客是我的一些总结,很多内容是参考了大闲人柴毛毛的博客总结,加上我的一些个人总结,为了尊重原作,

我附上了他的博客地址https://juejin.im/post/5aa74967f265da23a334e373

作者:lhsjohn