1.ThreadLocalMap.Entry中的key为什么不会被错误清理？
    一个对象在只有弱引用指向它时，垃圾回收一旦运行，就会被回收，但是ThreadLocal对象除了在Entry中有弱引用（它的key），还在业务代码中会被引用（否则也没必要创建它了不是），而业务代码中的引用一般都是强引用，所以对象如果在业务代码中还有引用，那么即使它被弱引用指向，垃圾回收时也不会被清理。
    
2.既然有remove方法可以清理这个Entry,为什么还需要弱引用？

    remove方法确实可以解决垃圾问题，但是它只有在你调用时才会起作用（: 你在不用一个map时会去remove其中的元素吗）。而一旦用户忘记调用该方法，（且假如ThreadLocalMap.Entry中的key是强引用的话 ）,与天地（所在线程）同寿的ThreadLocalMap中就会一直存在这么一个钉子户，占据内存使之不能被正确回收，这种情况就可以称为内存泄漏了。
    
    假如这个线程是个可复用线程，且它要做的每一次任务都会向ThreadLocalMap中放值，那这个垃圾堆起来可不是开玩笑的，轻则系统卡顿，重则oom。
    
    而当前的做法是，使用弱引用，即使用户忘记调用remove方法，这个ThreadLocal对象在不用时也会被回收，一旦回收，任何对ThreadLocalMap的get和remove操作都会触发对持有无效key的Entry的清理。这样的话，即使你粗心大意，最多也只会在下一次垃圾回收，以及当前线程下一次操作它的ThreadLocalMap之前，允许这个Entry占一会内存。时机一到，expungeStaleEntry方法这个剃刀和gc这个推土机和配合起来，就会让滥竽充数的无用Entry消失于无形。