hash冲突问题首先看一下ThreadLocal的这一段源码:
public class ThreadLocal<T> { // 创建ThreadLocal对象时立马初始化threadLocalHashCode private final int threadLocalHashCode = nextHashCode(); // 所有ThreadLocal对象共享 private static AtomicInteger nextHashCode = new AtomicInteger(); // 魔数,自增步长 private static final int HASH_INCREMENT = 0x61c88647; // 每次自增固定的值 private static int nextHashCode() { return nextHashCode.getAndAdd(HASH_INCREMENT); } } 复制代码
- 根据上面代码的解析,可以看出,每次new一个ThreadLocal对象,threadLocalHashCode的值都会在上一个对象的threadLocalHashCode值基础上自增一个固定长度“0x61c88647”。
public void set(T value) { // 获取当前线程 Thread t = Thread.currentThread(); // 获取线程中的ThreadLocalMap容器对象 ThreadLocalMap map = getMap(t); // 如果线程中已经有这个ThreadLocalMap容器对象了,那么直接把数据存进去 if (map != null) { // 注意,这里的this指的就是当前的ThreadLocal对象本身 map.set(this, value); } else { // 如果当前线程中还没有这个ThreadLocalMap容器对象,那么就现在创建一个 createMap(t, value); } } // 说明ThreadLocalMap是线程中的一个对象 ThreadLocalMap getMap(Thread t) { return t.threadLocals; } // 创建一个ThreadLocalMap容器对象,并且赋值给指定线程 void createMap(Thread t, T firstValue) { t.threadLocals = new ThreadLocalMap(this, firstValue); } // 创建ThreadLocalMap容器对象 ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) { // 初始化table数组 table = new Entry[INITIAL_CAPACITY]; // 通过threadLocalHashCode计算目标索引值 int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1); // 把ThreadLocal对象作为key,需要存储在线程中的数据作为value table[i] = new Entry(firstKey, firstValue); size = 1; setThreshold(INITIAL_CAPACITY); } 复制代码
- 通过上述代码,可以看出:
- 每一个线程中都会有一个ThreadLocalMap容器,这个容器就是一个【key:value】数组。
- ThreadLocal是把自己本身作为key,存储对象作为value。
- 每一个ThreadLocal对象都有不同的threadLocalHashCode,以便于它们更好地离散分布在ThreadLocalMap中。
- 一个ThreadLocal对象在一个线程中,只能存储一个对象
- 如果ThreadLocal达到一定数量,通过threadLocalHashCode & (INITIAL_CAPACITY - 1)的算法计算目标索引值,必定会存在两个不同的ThreadLocal命中同一个索引值的情况。
private void set(ThreadLocal<?> key, Object value) { Entry[] tab = table; int len = tab.length; // 计算索引值 int i = key.threadLocalHashCode & (len-1); // 在这个for循环中,只判断了 // 1.索引值下的key是否和当前ThreadLocal相等 // 2.索引值下的key是否为null // 那么剩下的情况就是产生了hash冲突的情况 for (Entry e = tab[i]; e != null; // 3.如果产生hash冲突了,那么需要计算下一个目标索引位置下的Entry e = tab[i = nextIndex(i, len)]) { // 获取目标索引值下的key ThreadLocal<?> k = e.get(); // 1.如果和当前的ThreadLocal是一个对象,那么直接取值 if (k == key) { e.value = value; return; } // 2.如果这个索引值下的key已经被回收掉了,那么肯定是直接覆盖掉这个位置 if (k == null) { // replaceStaleEntry里面做了一些清理工作 replaceStaleEntry(key, value, i); return; } } tab[i] = new Entry(key, value); int sz = ++size; if (!cleanSomeSlots(i, sz) && sz >= threshold) rehash(); } // 写一个索引值就是一直向后自增,超过了整个容器大小,又回到索引0位置。 // 注意:容器是有扩容策略的,如果ThreadLocal数量不是特别多的话,一般是不会到0索引位的。 private static int nextIndex(int i, int len) { return ((i + 1 < len) ? i + 1 : 0); } // 检查是否需扩容 private void rehash() { expungeStaleEntries(); // 检查是否大于等于四分之三 if (size >= threshold - threshold / 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 (Entry e : oldTab) { 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; } 复制代码
- 所以在ThreadLocalMap中,一旦出现hash冲突的情况,就会通过线性探测的方式寻找下一个可以存放数据的位置。
get()方法也是一样,如果发现目标位置的key与当前的ThreadLocal不是一个对象,那么也会通过线性探测的方式寻找目标位置,直至满足条件。 - 内存泄漏问题
首先,如果我们的线程不会循环使用的话,本身是不存在内存泄漏的问题的。因为线程属性threadLocals会随着线程的消亡被回收,也就不可能内存泄漏。
因为线程资源宝贵,为了减少线程的创建,对线程做了循环利用。那么就会导致线程中的threadLocals在下一次使用前还有[key:value]键值对,并且因为一直有一个强引用指定value,那么gc并不会导致value的回收,在不断的循环利用过程中,必然会导致更多的value被创建而不被gc回收,最终导致内存泄漏。
1.如果Entry中的key使用强引用的话,那么需要使用者手动将ThreadLocal置为null,否则ThreadLocal对象始终会有一个强引用被ThreadLocalMap持有,那么永远不会被回收,导致内存泄漏。
2.如果Entry中的key使用弱引用的话,当ThreadLocal没有被任何对象任何强引用的时候,也就是该被回收的时候,那么就直接被回收了,不会因为ThreadLocalMap持有它的弱引用,导致它一直无法被回收而造成内存泄漏。
其实从设计层面来说的话,也体现了ThreadLocal的封装性,既然不让开发者关心具体的key如何操作,那么自身内部就应该保证使用ThreadLocal的内存安全性,而不应该让使用者来处理和关心ThreadLocalMap对ThreadLocal的引用问题。
为了证明一下只要ThreadLocal没有任何其他强引用,那么经过gc后就会立马被回收,我写了下面这段代码:
public static void main(String[] args) throws InterruptedException { CountDownLatch countDownLatch = new CountDownLatch(1); new Thread( () -> { // 创建一个ThreadLocal对象 ThreadLocal<String> threadLocal = new ThreadLocal<>(); threadLocal.set("hello world"); // 让ThreadLocal对象没有任何强引用 threadLocal = null; System.gc(); // 获取当前线程 Thread currentThread = Thread.currentThread(); // 可以在这一行打断点,查看currentThread里面的threadLocals对象 countDownLatch.countDown(); }) .start(); countDownLatch.await(); } 复制代码
如上图所示,gc后referent属性值为null,说明此时Entry中的key已经被回收了,但是value依然存在。
如何处理value的强引用?
可参照以下模版:
ThreadLocal<String> threadLocal = new ThreadLocal<>(); try{ threadLocal.set("hello world"); // todo }finally{ threadLocal.remove(); } 复制代码
无论key是强引用还是弱引用,threadLocal都必须要在代码逻辑执行完毕后调用remove()将value的强引用删掉,否则就会导致内存泄漏。
也就是说,ThreadLocal不需要开发者关心key的回收问题,开发者只需要关心自己操作的value的回收问题即可。内部的归内部管理,外部的归外部管理,各司其职。