一、Entry的key为什么要设计成弱引用
1.1、四大引用类型
Java中的四种引用
1.2、Entry源码
1.3、为什么设计为弱引用
1.3.1、官网
To help deal with very large and long-lived usages, the hash table entries use WeakReferences for keys。
1.3.2、ThreadLocal引用示意图
再说ThreadLocal的key设计为弱引用之前，先来说说如果设计为强引用，会有什么问题？
key使用强引用：假设在业务代码中使用完ThreadLocal，ThreadLocal中的ref被回收了，但是因为ThreadLocalMap的Entry的key强引用了ThreadLocal，造成ThreadLocal无法回收，在没 有删除这个Entry以及当前线程依然在运行的前提下，始终有一条强引用链，即：Thread ref===>Thread obj===>ThreadLocalMap obj===>Entry，Entry就不会被回收（Entry中包括ThreadLocal实例和value），导致Entry内存泄漏；
key使用弱引用：同样假设在业务代码中使用完ThreadLocal，ThreadLocal ref被回收了，由于ThreadLocalMap的Entry的key使用的是弱引用，当gc时ThreadLocal obj能够顺利被回收，此时Entry中的key为null，但是在没有手动删除这个Entry以及当前线程依然在运行的前提下，也始终存在着一条强引用链，即：Thread ref===>Thread obj===>ThreadLocalMap obj===>Entry===>value，value不会被回收，而这块value永远不会被访问到了，导致value内存泄漏；
总结：既然key设计为强引用和弱引用都有可能出现内存泄漏的问题，那么为什么要设计为强引用呢？事实上，在ThreadLocalMap中的set()、getEntry() 方法中，会对key是否为null（key为ThreadLocal）进行判断，如果key为null的话，那么会对value设置为null，这就意味着使用完ThreadLocal，当前线程依然运行的前提下，就算忘记调用remove()方法了，弱引用也比强引用多一层保障，所引用的key（ThreadLocal）会被回收，对应的value会在下次ThreadLocalMap中调用set()、getEntry()、remove()中的任一方法时都会被清除，从而避免内存泄露。
