ThreadLocal是否会引发内存泄露的分析（转）

这篇文章，主要解决一下疑惑：

1. ThreadLocal.ThreadLocalMap中提到的弱引用，弱引用究竟会不会被回收？

2. 弱引用什么情况下回收？

3. JAVA的ThreadLocal和在什么情况下会内存泄露？

带着这些疑问，自己模拟了一下ThreadLocal.ThreadLocalMap的结构，先展示下自己涉及的结构：

自己实现一个simple的ThreadLocalMap,里面用一个entry用来存放由自己模拟的ThreadLocal调用set方法set进去的值。

并且和JDK的ThreadLocalMap一样里面Entry对象的key用weakReference封装。

Main方法如下：

设置运行参数：

-verbose:gc

看输出结果:

这里我已经模拟出了内存泄露的问题，可以看到FULL
GC以后，内存还是被占用，且仔细观察可以看到，这个map中的Key已经有为null了。换句话说你通过Key已经不能获取到value了，当然map.get(null)也是可以的，不过

JAVA里的ThreadLocal不会这么去做，因为Map中key==null的元素可能不唯一。

从我的Main方法中可以看到，我有th=null的操作，但是还是有内存泄露，原因稍后分析。但有一点可以确定：th=null在这里不能如我们想象的将ThreadLocal th
的引用释放掉后，里面的key,value对象也释放，可能会有疑问我这里持有了ThreadLocalMap的引用tm所以不会回收，但实际上，手动设置JAVA的ThreadLocal为null时，当前线程任然持有ThreadLocalMap的引用，所以不会回收我这里和JAVA是类似的。

回到刚开始提出的3个问题，一一解答：

1. ThreadLocal.ThreadLocalMap中提到的弱引用，弱引用究竟会不会被回收？

会被回收，如上图所示。key
已经有null的情况了。第一个Key不为null，原因在第二点。在经历过FULL GC后所有的key都被回收了。

2. 弱引用什么情况下回收？

弱引用在GC(包括MinitorGC和Full
GC)时，被扫描到就会被回收，但是有一个前提，该弱引用在外部没有被引用到（这个时候外部的引用等于强引用）。

换句话说，如果我main方法中持有一个key的引用，哪怕他put进Map后被设置为弱引用的，也不会被回收。见下图: