ThreadLocal定义及内存泄漏

概述

ThreadLocal(线程局部变量) 的作用是提供线程内的局部变量，这种变量在线程的生命周期内起作用，减少同一个线程内多个函数或者组件之间一些公共变量的传递的复杂度。
一个线程对应着一个ThreadLocalMap，一个ThreadLocalMap存储着<ThredLocal，Value>的Entry。一个线程可以创建多个ThreadLocal，每个ThreadLocal对象代表当前线程范围内的一个共享变量。连续调用set()会更新ThreadLocal对象对应的值。所以每一个线程都可以独立地改变自己的副本，而不会影响其它线程所对应的副本。

ThreadLocal 也可以跟踪一个请求，从接收请求，处理请求，到返回请求，只要线程不销毁，就可以在线程的任何地方，调用这个参数。

ThreadLocal 实现原理

ThreadLocal的实现是这样的：每个Thread 维护一个 ThreadLocalMap 映射表，这个映射表的 key 是 ThreadLocal实例本身，value 是真正需要存储的 Object。

也就是说ThreadLocal 本身并不存储值，它只是作为一个 key 来让线程从 ThreadLocalMap 获取 value。值得注意的是图中的虚线，表示 ThreadLocalMap 是使用 ThreadLocal 的弱引用作为 Key 的，弱引用的对象在 GC 时会被回收。
ThreadLocalMap构造函数：

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);
        }

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为什么肯定会内存泄漏

ThreadLocalMap使用ThreadLocal的弱引用作为key，如果一个ThreadLocal没有外部强引用来引用它，那么系统 GC 的时候，这个ThreadLocal势必会被回收，这样一来，ThreadLocalMap（数组）中就会出现key为null的Entry，就没有办法访问这些key为null的Entry的value，如果当前线程再迟迟不结束的话，这些key为null的Entry的value就会一直存在一条强引用链：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value永远无法回收，造成内存泄漏。

其实，ThreadLocalMap的设计中已经考虑到这种情况，也加上了一些防护措施：在ThreadLocal的get()，set()，remove()的时候都会清除线程ThreadLocalMap里所有key为null的value。

但是这些被动的预防措施并不能保证不会内存泄漏：

使用static的ThreadLocal，延长了ThreadLocal的生命周期，可能导致的内存泄漏（参考ThreadLocal 内存泄露的实例分析）。
分配使用了ThreadLocal又不再调用get()，set()，remove()方法，那么就会导致内存泄漏。

所以得出一个结论就是只要这个线程对象被gc回收，就不会出现内存泄露，但在threadLocal设为null和线程结束这段时间不会被回收的，就发生了我们认为的内存泄露。最要命的是线程对象不被回收的情况，这就发生了真正意义上的内存泄露。比如使用线程池的时候，线程结束是不会销毁的，会再次使用的，就可能出现内存泄露。　　

ThreadLocal变量加不加static的区别

加了static，类加载的时候，就会初始化该Threadlocal变量。之后的每个线程访问的时候，都是引用到同一个ThreadLocal变量。不加static的时候，每个线程访问的时候都会创建新的ThreadLocal变量实例，造成空间浪费。加不加static都会有内存泄漏，这个是ThreadLocal的特性造成。
static的ThreadLocal变量是一个与线程相关的静态变量，即一个线程内，static变量是被各个实例共同引用的，但是不同线程内，static变量是隔开的。定义为static的ThreadLocal，只要类不卸载，ThreadLocal变量永远不会被gc掉，故在线程生命周期内，当前ThreadLocalMap一直保持ThreadLocal的引用。

为什么使用弱引用

key 使用强引用：ThreadLocal被设置为null，由于ThreadLocalMap持有ThreadLocal的强引用，如果没有手动删除Entry和ThreadLocalMap的关系，那么ThreadLocal不会被回收，导致内存泄漏。
key 使用弱引用：ThreadLocal被设置为null，由于ThreadLocalMap持有ThreadLocal的弱引用，如果没有手动删除Entry和ThreadLocalMap的关系，ThreadLocal仍会被回收！这时ThreadLocalMap中存在key为 null的Entry。如果创建ThreadLocal的线程一直持续运行，那么这个Entry对象中的value就有可能一直得不到回收，发生内存泄露。value在下一次ThreadLocalMap调用set，get，remove的时候会被清除。

在我们调用ThreadLocal.set（）的时候，会做一个将Key== null 的元素清理掉的工作，具体做法是：

第一步：ThreadLocalMap 拿threadLocalHashCode与map长度减一相与，求出哈希表的位置 i 。

第二步：遍历Entry，如果找到key相等的，覆盖原值或者找到key==null的，将值set进去，并且将遍历时路过的key==null的元素和他的value都置为null，释放内存。

第三步：最后一个if条件时，做rehash的动作，即:将Entry里的元素重新计算一下Hash值，放到合适的位置去，猜想是为了加快下次访问的速度。

总结

比较两种情况，我们可以发现：由于ThreadLocalMap的生命周期跟Thread一样长，如果都没有手动删除对应key的Entry，都会导致内存泄漏，但是使用弱引用可以多一层保障：ThreadLocal实例没有外部强引用的情况下，在GC时可以正常回收ThreadLocal的内存，但对应的value在下一次ThreadLocalMap调用set，get，remove的时候会被清除。

既然Key是弱引用，那么我们要做的事，就是在调用ThreadLocal的get()、set()方法时完成后再调用remove方法，将Entry节点和Map的引用关系移除，这样整个Entry对象在GC Roots分析后就变成不可达了，下次GC的时候就可以被回收。

因此，ThreadLocal内存泄漏的根源是：由于ThreadLocalMap的生命周期跟Thread一样长，如果没有手动删除key对应的Entry就会导致内存泄漏，而不是因为弱引用。

ThreadLocalMap Hash冲突怎么解决

ThreadLocalMap结构非常简单，没有next引用，也就是说ThreadLocalMap中解决Hash冲突的方式并非链表的方式，而是采用线性探测的方式，所谓线性探测，就是根据初始key的hashcode值确定元素在table数组中的位置，如果发现这个位置上已经有其他key值的元素被占用，则利用固定的算法寻找一定步长的下个位置，依次判断，直至找到能够存放的位置。

ThreadLocalMap解决Hash冲突的方式就是简单的步长加1或减1，寻找下一个相邻的位置。

每个线程只存一个变量，这样的话所有的线程存放到map中的Key都是相同的ThreadLocal，如果一个线程要保存多个变量，就需要创建多个ThreadLocal，多个ThreadLocal放入Map中时会极大的增加Hash冲突的可能。

synchronized 与 ThreadLocal的区别

ThreadLocal和线程同步机制都是为了解决多线程中相同变量的访问冲突问题。

在同步机制中，通过对象的锁机制保证同一时间只有一个线程访问变量。这时该变量是多个线程共享的，使用同步机制要求程序慎密地分析什么时候对变量进行读写，什么时候需要锁定某个对象，什么时候释放对象锁等繁杂的问题，程序设计和编写难度相对较大。

而ThreadLocal则从另一个角度来解决多线程的并发访问。ThreadLocal会为每一个线程提供一个独立的变量副本，从而隔离了多个线程对数据的访问冲突。因为每一个线程都拥有自己的变量副本，从而也就没有必要对该变量进行同步了。ThreadLocal提供了线程安全的共享对象，在编写多线程代码时，可以把不安全的变量封装进ThreadLocal。

对于多线程资源共享的问题，同步机制采用了“以时间换空间”的方式，而ThreadLocal采用了“以空间换时间”的方式。前者仅提供一份变量，让不同的线程排队访问，而后者为每一个线程都提供了一份变量，因此可以同时访问而互不影响。

总结

ThreadLocalMap内部Entry中key使用的是ThreadLocal对象的弱引用，这为避免内存泄露是一个进步，因为如果是强引用，那么即使其他地方没有对ThreadLocal对象的引用，ThreadLocalMap中的ThreadLocal对象还是不会被回收，而如果是弱引用则这时候ThreadLocal引用是会被回收掉的，虽然对于的value还是不能被回收，这时候ThreadLocalMap里面就会存在key为null但是value不为null的entry项，虽然ThreadLocalMap提供了set，get，remove方法在一些时机下会对这些Entry项进行清理，但是这是不及时的，也不是每次都会执行的，所以一些情况下还是会发生内存泄露，所以在使用完毕后调用remove方法才是解决内存泄露的王道。