猜想问题(二)——关于ThreadLocal的实用性

先说一下场景，主要一个登录系统，我们用ThreadLocal存session做一个快速访问，然后多线程去异步设计这个登录操作，然后我们用了线程池去做整体的架构设计，然后ThreadLocal的key是session，value是个人信息，用这种设计模式去做登录。

然后我们来想想可不可行，ThreadLocal的特性我们大约都知道了，不知道的可以去查查，我就直接讲了。

如果我们用多线程的话，线程用完了回收，但是如果我们之前给这个线程使用过ThreadLocal，那么ThreadLocal回去之后，重新又接了个任务，之前的ThreadLocal你们觉得还在吗，答案是在的。

假如我们不去执行remove方法的话，ThreadLocal也就不会去清除掉被gc掉的key所在的那一行，就会出现一些问题，那么问题就来了，我们执行remove，就不会出现问题了吗？如果回到线程池之后，它再被GC呢？那不就无法解决空key的问题了。

这个时候问题就来了，新的key就有可能会和别人的session绑定到一起，这样就会让A登录B的号，产生问题。

不过实际上ThreadLocal实用性也不高，面试背过一些底层的原理，但是确实没在实际用过，解决方法就是，不用ThreadLocal。