为什么使用ThreadLocal?
关于会话,一般是采用 cookie 和 session ,而 session 分布式部署时需要解决共享问题,一般就采用 DB 来替代它。现在我们用的是MySQL,将来会换成 Redis 。我们在会话里存的是用户的登录凭证,而不是用户信息本身。我们可以通过拦截器,在请求开始将凭证置换成用户信息。为了便于在本次请求的后续部分获取到登录用户,所以我通过 ThreadLocal ,将其与当前线程绑定。那么问题来了,request 对象就是本次请求,我们可以在请求结束前的任意时刻,从 request 对象里获取与本次请求有关的数据。实际上,确实可以通过 request 来持有用户数据的。但是从设计上、代码分层上来说,这样不好。在 Spring MVC 框架中, request 是一个比较底层的数据对象,一般我们不直接使用它,看看你处理请求的代码就知道了。而且并不是任意的位置都方便获取 request 对象,因为它不被容器管理,不是随便就能注入给一个 Bean 的。因为不鼓励这样做,requerst 是表现层的对象,要是随便注入,你很可能会将其注入给 service,从而产生耦合。所以,我们自己写一个组件,单独解决这个问题。原则上可以,但事实上不会,这是从代码合理性角度考量的。
解决办法
每次点击请求,都会让拦截器的 preHandle 方法从 request 中获取 token ,用 token 去验证用户信息。
每次请求都需要重新处理,重新分配资源的。因为你不知道这个人还会不会有下一次请求,你也不知道它的登录状态是不是会过期。这不是长连接,所以就必须每次判断。