以后再也不用担心提起ThreadLocal两眼干瞪的窘境了

1.背景

什么是ThreadLocal?

    ThreadLocal类可以理解为线程本地变量。也就是说如果定义了一个ThreadLocal,每个线程往这个ThreadLocal中读写是线程隔离,互不影响的。它提供了一种将可变数据通过每个线程有自己的独立副本从而实现线程封闭的机制。

它的实现思路是什么?

   ThreadLocal类有一个类型为ThreadLocal.ThreadLocalMap,也就是说每个线程都有一个自己的ThreadLocalMap。ThreadLocalMap有自己的独立实现,可以将ThreadLocal视作它的key,value为代码中放入的值(其实实际上key并不是ThreadLocal本身,而是它的一个弱引用《这涉及到JVM的回收机制,下一篇博客会阐述》)。每个线程往Thread Local中存值都是存在了ThreadLocalMap中。当取值时也是以ThreadLocal为key(一个弱引用),然后找到对应的值,从而实现了线程隔离。

 

2.Thread和ThreadLocal有什么联系?

Thread和ThreadLocal是绑定的,ThreadLocal依赖于Thread去执行,Thread将需要隔离的数据存放到ThreadLocal(ThreadLocalMap)中,来实现多线程处理。

 

3.ThreadLocal的内存泄露

    关于ThreadLocal内存泄漏问题,网上一搜一大堆,也是面试经常会问到的问题。其实看过ThreadLocal的源码的开发大都知道为什么一个类似Map的存储结构怎么会出现内存泄漏的问题。

 static class ThreadLocalMap {

        /**
         * The entries in this hash map extend WeakReference, using
         * its main ref field as the key (which is always a
         * ThreadLocal object).  Note that null keys (i.e. entry.get()
         * == null) mean that the key is no longer referenced, so the
         * entry can be expunged from table.  Such entries are referred to
         * as "stale entries" in the code that follows.
         */
        static class Entry extends WeakReference<ThreadLocal<?>> {
            /** The value associated with this ThreadLocal. */
            Object value;

            Entry(ThreadLocal<?> k, Object v) {
                super(k);
                value = v;
            }
        }
    ...

   其实主要是ThreadLocalMap中Entry的设计,Entry继承了WeakReference<ThreadLocal<?>>,而它的key值赋值则调用了父类的有参构造,即Entry的key是一个弱引用,所以key会在垃圾回收的时候被回收,而key对应的value则不会被回收,即Entry的key 为null,但value是有值的,如此往复,value累加就会导致内存泄漏。

这个问题我想当时设计ThreadLocal类的Josh Bloch、Doug Lea这两大神估计也想到了:

//删除无效的value  
private int expungeStaleEntry(int staleSlot) {
            Entry[] tab = table;
            int len = tab.length;

            // expunge entry at staleSlot
            tab[staleSlot].value = null;
            tab[staleSlot] = null;
            size--;

            // Rehash until we encounter null
            Entry e;
            int i;
            for (i = nextIndex(staleSlot, len);
                 (e = tab[i]) != null;
                 i = nextIndex(i, len)) {
                ThreadLocal<?> k = e.get();
                if (k == null) {
                    e.value = null;
                    tab[i] = null;
                    size--;
                } else {
                    int h = k.threadLocalHashCode & (len - 1);
                    if (h != i) {
                        tab[i] = null;

                        // Unlike Knuth 6.4 Algorithm R, we must scan until
                        // null because multiple entries could have been stale.
                        while (tab[h] != null)
                            h = nextIndex(h, len);
                        tab[h] = e;
                    }
                }
            }
            return i;
        }

这个expungeStaleEntry方法就是用来清除key为null而value有值的无效数据的,阅读源码后发现,ThreadLocal的API中的get()、set()、remove()方法中都间接调用了expungeStaleEntry(int staleSlot)这个方法。下面以remove()方法为例,看看源码:

 
 public void remove() {
         ThreadLocalMap m = getMap(Thread.currentThread());
         if (m != null)
             m.remove(this);
     }
ThreadLocal类中的remove()方法又调用了ThreadLocalMap中的remove()方法


       /**
         * Remove the entry for key.
         */
        private void remove(ThreadLocal<?> key) {
            Entry[] tab = table;
            int len = tab.length;
            int i = key.threadLocalHashCode & (len-1);
            for (Entry e = tab[i];
                 e != null;
                 e = tab[i = nextIndex(i, len)]) {
                if (e.get() == key) {
                    e.clear();
                    expungeStaleEntry(i);
                    return;
                }
            }
        }

所以阅读过源码之后我们可以推断:在使用ThreadLocal的过程中,用完之后调用remove方法是个很好的编程习惯,这样就可以避免内存泄漏。

那么问题来了,既然弱引用导致内存泄漏,那为什么不把key设置为强引用?

如果key设置为强引用,当ThreadLocal实例释放后,threadlocal就成Null了,但是ThreadLocal还有强引用指向ThreadLocalMap,而ThreadLocalMap.Entry又强引用ThreadLocal,这样就会导致GC不能正常回收ThreadLocal,又会导致内存泄漏

4.扩展---spring如何保证数据库事务在同一个连接下执行?

DataSourceTransactionManager是spring的数据源事务管理器,它会在你调用getConnection()的时候从数据库连接池中获取一个connection,然后将其与ThreadLocal绑定,事务完成后解除绑定。这样就保证了事务在同一个连接下完成。

 

 

越努力,越幸运!

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值