多线程之ThreadLocal

ThreadLocal的作用是提供线程内的局部变量，这种变量在多线程环境下访问时能够保证各个线程里变量的独立性

下面会对其重点进行讲解：
重写的hash算法

// hash code
private final int threadLocalHashCode = nextHashCode();
 
// AtomicInteger类型，从0开始
private static AtomicInteger nextHashCode =
    new AtomicInteger();
 
// hash code每次增加1640531527 
private static final int HASH_INCREMENT = 0x61c88647;
 
// 下一个hash code
private static int nextHashCode() {
    return nextHashCode.getAndAdd(HASH_INCREMENT);
}

ThreadLocal通过它里面的ThreadLocalMap对象进行变量存储，值得一提的是ThreadLocalMap是一个Entry数组，解决hash冲突是通过线性探测法，索引值加一进行取模运算。

ThreadLocalMap底层基础数据结构是常用的Entry它继承了弱引用，若引用的作用在于：只要线程处于活动状态并且Threadocal实例可以访问，每个线程就拥有对其线程局部变量副本的隐式引用；在一个线程消失之后，线程本地实例的所有副本都会被垃圾收集（除非存在对这些副本的其他引用

内存泄漏问题：
从上面源码可以看出，ThreadLocalMap使用ThreadLocal的弱引用作为Entry的key，如果一个ThreadLocal没有外部强引用来引用它，下一次系统GC时，这个ThreadLocal必然会被回收，这样一来，ThreadLocalMap中就会出现key为null的Entry，就没有办法访问这些key为null的Entry的value。

我们上面介绍的get、set、remove等方法中，都会对key为null的Entry进行清除（expungeStaleEntry方法，将Entry的value清空，等下一次垃圾回收时，这些Entry将会被彻底回收）。

但是如果当前线程一直在运行，并且一直不执行get、set、remove方法，这些key为null的Entry的value就会一直存在一条强引用练：Thread Ref -> Thread -> ThreadLocalMap -> Entry -> value，导致这些key为null的Entry的value永远无法回收，造成内存泄漏。
如何避免内存泄漏？

为了避免这种情况，我们可以在使用完ThreadLocal后，手动调用remove方法，以避免出现内存泄漏。

总结：

每个线程都有一个ThreadLocalMap 类型的 threadLocals 属性。
ThreadLocalMap 类相当于一个Map，key 是 ThreadLocal 本身，value 就是我们的值。
当我们通过 threadLocal.set(new Integer(123)); ，我们就会在这个线程中的 threadLocals 属性中放入一个键值对，key 是 这个 threadLocal.set(new Integer(123))的threadlocal，value 就是值new Integer(123)。
当我们通过 threadlocal.get() 方法的时候，首先会根据这个线程得到这个线程的 threadLocals 属性，然后由于这个属性放的是键值对，我们就可以根据键 threadlocal 拿到值。 注意，这时候这个键 threadlocal 和 我们 set 方法的时候的那个键 threadlocal 是一样的，所以我们能够拿到相同的值。
ThreadLocalMap 的get/set/remove方法跟HashMap的内部实现都基本一样，通过 “key.threadLocalHashCode & (table.length - 1)” 运算式计算得到我们想要找的索引位置，如果该索引位置的键值对不是我们要找的，则通过nextIndex方法计算下一个索引位置，直到找到目标键值对或者为空。
hash冲突：在HashMap中相同索引位置的元素以链表形式保存在同一个索引位置；而在ThreadLocalMap中，没有使用链表的数据结构，而是将（当前的索引位置+1）对length取模的结果作为相同索引元素的位置：源码中的nextIndex方法，可以表达成如下公式：如果i为当前索引位置，则下一个索引位置 = (i + 1 < len) ? i + 1 : 0。