在校验登录状态时，后端从session获取用户并判断用户是否存在，存在的话保存用户到ThreadLocal中，为什么要保存在ThreadLocal中而不直接从session拿用户的信息呢？

目录

一、简述

二、原因

1、减少session查找的开销

2、提高代码的可读性和维护性

3、线程安全

4、减少不必要的网络传输

5、面对高并发场景

三、总结

---

一、简述

我们在做项目的时候，免不了要做登录功能，其中就要实现校验登录状态，一般校验登录状态的流程图如下：

在校验登录状态时，后端从session获取用户并判断用户是否存在，存在的话保存用户到ThreadLocal中，为什么要保存在ThreadLocal中而不直接从session拿用户的信息呢？

主要有以下原因

二、原因

1、减少session查找的开销

session一般都是存储在服务器端的，如果每次都要从session中查找用户信息，那都要去服务器的内存或存储系统去查找对应的session对象，这肯定会带来一定的性能开销。

那你用TheadLocal就直接把对象放在当前线程里面，想用直接在当前线程找，效率肯定就会高很多。

2、提高代码的可读性和维护性

直接在session里面拿用户信息，听着很直接很简单，实则需要调用多个层级才能找到，代码特别复杂且冗余，直接用TheadLocal拿用户信息肯定就更方便且直观。

3、线程安全

ThreadLocal为每个线程提供了一个独立的变量副本，这意味着在多线程环境下，每个线程都可以安全地访问自己的用户信息，而不会与其他线程发生冲突。如果直接操作Session，需要额外的同步机制来保证线程安全。

4、减少不必要的网络传输

当你的用户量特别多，你不先拿到TheadLocal里面，那session里面的用户信息会越来越多，Session可能需要在多个服务器之间同步，这会增加网络传输的开销。

5、面对高并发场景

在高并发的应用场景下，频繁地访问Session可能会导致性能瓶颈。而​​​​​​​ThreadLocal由于其线程局部性，可以提供更好的性能表现。

三、总结

我们用一个不太恰当的例子来说明这个问题，你现在需要一个钥匙（用户信息）来开门，你把你的钥匙放在了一个开锁匠（session）那里，每次要用钥匙（用户信息）就去开锁匠（session）那里找，而不放在自己口袋（TheadLocal）里。久而久之，存放在开锁匠的钥匙越来越多，开锁匠找你的钥匙的速度就越来越慢（session查找的开销），而且他身上的钥匙也越来越重，行动起来也越来越困难（网络传输），而且还可能把你的钥匙拿错给别人（线程安全）。