ThreadLocal内存泄漏的真实原因

温馨提醒：本文只适用于对ThreadLocal有中级了解的同学，不然读起来可能会云里雾里。实在读不懂的，可以留言，我再出一期"ThreadLocal从入门到踢门"的学习文章。

看留言需求：ThreadLocal从入门到踢门

图解ThreadLocal的前世今生

Thread维护了一个threadLocals(类型为ThreadLocalMap)，threadLocals其实里面就是一个Entry数组，而Entry数组则有key和value，其中key就是当前操作线程所创建的threadLocal，value则为我们set进去的值。

再用一下这张图解释一下内存泄漏：

图中，我们可以看出Entry的key是弱引用，从JVM的GC角度分析弱引用，当发生GC时，被弱应用的对象会被GC，然而此时的value是强引用类型，不会被回收

(强引用链路：Thread->threadLocals->Entry->value)

此时就发生了内存泄漏(内存泄漏：指无需再使用到的东西还再占用着空间【古话就是：占着茅坑不拉屎】)

解决方案：

将key设置为强引用类型，使用完调用其remove方法

图解使用线程池操作ThreadLocal发生内存泄漏的情况

线程池里的线程都是复用的，因此派发出去的线程池终究是会回收回来的。这就会造成一个问题，Thread还是被使用，那么发生GC回收时，只会将key回收，而value依然游离，也称内存泄漏，其实也跟单线程操作一样。但是单线程终究会随着业务的执行而结束，而线程池不会(线程复用)，那么则永远无法处理value这个内存泄漏问题。

解决方案：

将key设置为强引用，业务结束调用ThreadLocal的remove方法，对Entry进行回收。

读完上面，回过头来想，内存泄漏罪魁祸首就是因为key的引用类型呀？这个问题是网上大多数文章所重点讨论的，此时应该回过头来想，为什么要将key设置为弱引用类型？

我：当你的业务线很长的时候，然而ThreadLocal的业务块已经处理完了，那么此时应该是把它回收掉了，这样也就能节省一些堆空间。那问题又来了，为什么此时不把value也给回收掉？好问题，因为我们无法确定后面业务线是否会用到这个value，他是个强引用类型，如果后面有用到那我们就可以复用它，无需再继续多余的new。所以value是需要考虑业务的，所以也就有了remove这个方法，根据个人情况而定去GC。

所以key设置为弱引用，其实是帮助我们去节省一些堆空间，而不是造成内存泄漏的根本原因。

如果不设置为弱引用，那么就不止value申请的这块堆空间发生内存泄漏，同时key申请的这块空间也会发生内存泄漏。