ThreadLocal原理以及内存泄漏的问题
ThreadLocal的整体的结构
ThreadLocal的整体的结构
可以通过上图看到,ThreadLocal内部是基于一个ThreadLocalMap来实现,而ThreadLocalMap内部又是一个Entry的数据结构。这个Entry的数据结构最终是基于弱引用来使用。我们看源码的定义。
static class Entry extends WeakReference<ThreadLocal<?>> { /** The value associated with this ThreadLocal. */ Object value; Entry(ThreadLocal<?> k, Object v) { super(k); value = v; } }
内部数据结构之间的通信
从图一,我们知道了ThreadLocal的数据结构与内部组件。下面,我们来看看他的这些内部组件是怎样进行一个沟通访问的。
我们通过看源码中的get()操作看看大致是一个怎样的过程。
public T get() { Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) { ThreadLocalMap.Entry e = map.getEntry(this); if (e != null) { @SuppressWarnings("unchecked") T result = (T)e.value; return result; } } return setInitialValue(); }
我们想一下,Thread都说是线程之间相互隔离的,那么相互隔离的话,这个内部维护的数据就应该是每个线程他自己所持有的。我们可以看到getMap(t);的实现证实了我们这个想法:
ThreadLocalMap getMap(Thread t) { return t.threadLocals;}
而Thread的内部也恰好维护了ThreadLocalMap。
/* ThreadLocal values pertaining to this thread. This map is maintained * by the ThreadLocal class. */ ThreadLocal.ThreadLocalMap threadLocals = null;
所以,我们可以了解成一个Thread就有个自己的ThreadMap.而自己维护自己的数据相互独立。但是,这里要注意一点,假如在线程中,在创立一个线程,这个时候,就不能通过ThreadLocal进行get数据了,这个时候已经做了线程之间的切换了,假如想要获子线程能够访问到父线程的数据,这个时候就要使用InheritableThreadLocal这个继承的ThreadLocal来操作了。
OK,我们通过ThreadLocal的get操作大致明白了他的一个内部数据之间是怎样一个联络。那么我们再来看看ThreadLocal的set操作又是怎样做的。线上源码:
public void set(T value) { Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) map.set(this, value); else createMap(t, value); } private void set(ThreadLocal<?> key, Object value) { // We don't use a fast path as with get() because it is at // least as common to use set() to create new entries as // it is to replace existing ones, in which case, a fast // path would fail more often than not. 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)]) { ThreadLocal<?> k = e.get(); if (k == key) { e.value = value; return; } if (k == null) { replaceStaleEntry(key, value, i); return; } } tab[i] = new Entry(key, value); int sz = ++size; if (!cleanSomeSlots(i, sz) && sz >= threshold) rehash(); }
set方法的前两步没问题,通过当前Thread取得自己的ThreadLocalMap。假如ThreadLocalMap为空就进行一个创立,非空就是一个填值。而create的时候就是简单的new ThreadLocalMap(), 并且这个时候是绑定当前线程的value为一个null,而后赋值给当前ThreadLocal。
/** * The initial capacity -- MUST be a power of two. */ private static final int INITIAL_CAPACITY = 16; /** * The table, resized as necessary. * table.length MUST always be a power of two. */ private Entry[] table; /** * The number of entries in the table. */ private int size = 0; /** * The next size value at which to resize. */ private int threshold; // Default to 0 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); }
ThreadLocalMap并不像我们平时使用的HashMap那样维护一个链表,而是单纯的一个数组。而他的hashCode是从0x61c88647开始,没使用一次,进行一个加1. 将我们的key 和value维护到了Entry中,而后在放入我们的Entry数组中。并记录ThreadLocalMap的扩容阈值。因为他是使用了一个AtomicInteger的getAndAdd方法来获取hashCode,所以,我们想的hash冲突就迎刃而解了。
那么我们重点来关注他下面的set方法。
这个过程中。通过hash值算出在ThreadLocalMap中的table中的具体下标索引。
这里的大致过程就是通过key去寻觅对应的Entry能否存在。这里为什么要这么做?由于Entry使用的是一个弱引用,弱引用在获取值的时候,可能已经被上一次GC所回收了值,这个时候,我们就要进行一个重新赋值。
而这个地方最有意思的就是在最下面的扩容了,由于前面的赋值只是少量常规的操作“有,覆盖;无,创立”,并且使用的是一个弱引用而已,可扩容的地方就要再看一看了。
int sz = ++size;if (!cleanSomeSlots(i, sz) && sz >= threshold) rehash();
cleanSomeSlots这个地方就是我们前面说的,因为是弱引用,所以这个地方,他在进行一个填充值的时候,进行了一个额外的删除已经被GC的Key对应的Value(至于为什么要说是已经被GC的Key对应的Value我们下面再说。),这个动作相当于是一个懒式的操作。
下面我们跟进rehash():
private void rehash() { expungeStaleEntries(); // Use lower threshold for doubling to avoid hysteresis if (size >= threshold - threshold / 4) resize(); }
expungeStaleEntries这个其实就是cleanSomeSlots的内部实现,用法不解释了。而当容量大于阈值的3/4的时候,就需要resize了。
private void resize() { Entry[] oldTab = table; int oldLen = oldTab.length; int newLen = oldLen * 2; Entry[] newTab = new Entry[newLen]; int count = 0; for (int j = 0; j < oldLen; ++j) { Entry e = oldTab[j]; if (e != null) { ThreadLocal<?> k = e.get(); if (k == null) { e.value = null; // Help the GC } else { int h = k.threadLocalHashCode & (newLen - 1); while (newTab[h] != null) h = nextIndex(h, newLen); newTab[h] = e; count++; } } } setThreshold(newLen); size = count; table = newTab; }
从这里可以看到,他的扩容是两倍两倍的进行扩容,而后将老的数据从老的table中拿出,而后重新hash得到一个新的index,而后填充到新的table中。这就是一个简单的两个数组的拷贝,而后重新设置了一下阈值。好吧,原来就是这么简单。。。。
再谈内存泄漏的问题
从第一张图中,我们知道了ThreadLocalMap中的内部是一个Entry的数据结构,而Entry的数据结构又是一个弱引用WeakReference<ThreadLocal<?>>.这里要注意了, 弱引用里面的泛型是ThreadLocal,而这个从之前的代码里面可以发现,传递到这里的ThreadLocal就是this,再结合一下弱引用的特性想一下,假如ThreadLocal这个对象被回收了,但是我当前的线程还是在继续运行,注意哦,我们的ThreadLocalMap是在线程Thread里面的哦,所以ThreadLocal在弱引用的时候被GC,我们的线程还在继续运行,ThreadLocalMap也是还会继续存活的,但是,这个时候,TheadLocalMap的key已经不存在了, 但是,我们的value可不是WeakReference弱引用,并没有被GC。这样,这个value只需线程还在继续运行,就永远不会被GC掉。
static class Entry extends WeakReference<ThreadLocal<?>> { /** The value associated with this ThreadLocal. */ Object value; Entry(ThreadLocal<?> k, Object v) { super(k); value = v; } }
所以,这就出现了内存泄漏的现象。避免出现这种现象的方法一般都是在ThreadLocal使用完了之后,进行一个TreadLocal.remove()方法操作。
总结
ThreadLocal在面试的过程中也经常被问到,这里主要要关注的就是他的内部是一个怎么的结构,resize的过程,内存泄漏是怎样发生(主要结合弱引用的特性)。
1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长!
2. 分享目的仅供大家学习和交流,您必须在下载后24小时内删除!
3. 不得使用于非法商业用途,不得违反国家法律。否则后果自负!
4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解!
5. 如有链接无法下载、失效或广告,请联系管理员处理!
6. 本站资源售价只是摆设,本站源码仅提供给会员学习使用!
7. 如遇到加密压缩包,请使用360解压,如遇到无法解压的请联系管理员
开心源码网 » ThreadLocal原理以及内存泄漏的问题