-
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对象在一个线程中，只能存储一个对象
image-20210612124541065.png
如果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();
}
image-20210612140215761.png
如上图所示，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的回收问题即可。内部的归内部管理，外部的归外部管理，各司其职。
网友评论