通常在项目中,用户登录后,我们会将用户的信息存到session,如果想在其它地方获取session中的用户信息,我们需要先获取HttpServletRequest,再通过request.getSession得到HttpSession。
但是这样操作会很麻烦,每次要获取session都要传递Request请求参数,尤其是service层或者dao层也要使用到user的信息,而通常在一个大型项目中,service层和dao层都是和web层分离开来,
都是单独的工程,不依赖servlet api,大家也不会为了在service层或者dao层获取登录用户信息而这么做,这样显得会很奇怪,所以我们只能在action中调用service的时候,将用户信息以参数形式传过去。
对于session中的用户信息,我们不仅想要在action中随用随取,还想在其它普通类中取,即使不依赖servlet api, 我们也要在方法里随用随取,anywhere!
你可能回想到用全局变量的方式来解决这个问题,
定义一个全局的session变量,类似常量的处理。每次访问时重置一下就行了,问题好像解决了!
但考虑过并发问题吗?两个人登录,A置成自己的session了,B又置成他的session了,两人开始打架了,是不是。我们还能做什么吗?答案当然是肯定的。
我们引入ThreadLocal,多么伟大的发明啊!
首先它不是用来解决多线程并发共享一类问题的,它解决的是在一个线程中参数的传递。
ThreadLocal,顾名思义,就是本地线程,可是这个名字实在容易让人误解,因为其实它是本地线程局部变量的意思,首先我们要知道,我们每个请求都会对应一个线程,
这个ThreadLocal就是这个线程使用过程中的一个变量,该变量为其所属线程所有,各个线程互不影响。
这里我们要了解一下ThreadLocal的三个方法:
ThreadLocal.set(T value); //设置值
ThreadLocal.get(); //获取值
ThreadLocal.remove(); //移除值
所以我们可以借助这个ThreadLocal来存储登录用户的信息,在一个请求中,所有调用的方法都在同一个线程中去处理,这样就实现了在任何地方都可以获取到用户信息了,从而摆脱了HttpServletRequest的束缚。
于是在action层将user添加到TreadLocal中,然后我们可以在任意的一层service或者dao里获取当前线程的user信息了。
好处:避免了跨层之间的参数传递,实现了层与层之间的松耦合。
可是这时候又出现了问题,在一个线程结束后,我又发起了一次后台请求,这个时候,处理这个请求的线程变成了另外一个线程,线程切换了!!!而这个线程中我们并没有set用户信息到它的ThreadLocal中去,此时我们想要获取用户信息就获取不到了,前面说过,
ThreadLocal为各个线程所私有,各线程间不共享,也互不影响,那么问题来了,我们只是在登录的时候,查询用户信息并将其放进当前线程的ThreadLocal,而后续其它请求一旦切换到别的线程,
我们的功能就玩不转了,所以我们需要借助一个方法来过滤所有的后台请求(排除非必须登录才能访问的url),给用户信息做个检查,一旦SessionLocal.getUser()为空,那么我们就set进去,so,我们可以借助一个Filter来达到我们的目的。
可是上面我们并没有将用户信息放到session中,此时,我们还是绕回去了,我们依然不得不把用户信息给放到session中,不然我们在Filter中如何获取用户信息并set进ThreadLocal,总不能再查一次数据库。
我们在Filter中就可以先判断SessionLocal.getUser()是否为空,如果为空,则从session中取用户,如果session中有,则将用户放到TheadLocal,否则,跳转到首页或者登录页。
利用ThreadLocal管理登录用户信息实现随用随取