美文网首页
ThreadLocal初步探秘

ThreadLocal初步探秘

作者: lhsjohn | 来源:发表于2019-05-31 23:57 被阅读0次

    ThreadLocal是什么?

    ThreadLocal是java语言实现的一种线程本地存储的方式,有时候我们会遇到这样一种需求:每条线程都要去存取一个同名的变量,但是每条线程中该变量的值都是不一样的,那么如果让我们去实现的话,会采用什么方式去实现呢? 也许你会认为你可以去使用一个线程共享的Map<Thread,Object>, 其中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<String> 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<ThreadLocal<?>> {
                /** 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<ThreadLocal<?>,在构造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

    相关文章

      网友评论

          本文标题:ThreadLocal初步探秘

          本文链接:https://www.haomeiwen.com/subject/xlgntctx.html