ThreadLocal使用场景

ThreadLocal使用场景

ThreadLocal在设计之初就是为解决并发问题⽽提供⼀种⽅案，每个线程维护⼀份⾃⼰的数据，达到线程隔离的效果

场景一:代替参数的显式传递

当我们在写API接口的时候，通常Controller层会接受来自前端的入参，当这个接口功能比较复杂的时候，可能我们调用的Service层内部还调用了很多其他的很多方法，通常情况下，我们会在每个调用的方法上加上需要传递的参数,当参数很多时，就会使得传参麻烦。

此时可以使用过滤器，将参数等相关数据存入ThreadLocal中，那么就不用显式的传递参数了，而是只需要ThreadLocal中获取即可。
使用完成后，再调用remove进行清除。

场景二:全局存储用户信息

在用户登录后，用户信息会保存在Session或者Token中。这个时候，我们如果使用常规的手段去获取用户信息会很费劲,拿Session来说，我们要在接口参数中加上HttpServletRequest对象，然后调用getSession方法，且每一个需要用户信息的接口都要加上这个参数，才能获取Session，这样实现就很麻烦了。
此时我们使用ThreadLocal, 我们会选择在拦截器的业务中，获取到保存的用户信息，然后存入ThreadLocal,那么当前线程在任何地方如果需要拿到用户信息都可以使用ThreadLocal的get()方法(异步程序中ThreadLocal是不可靠的)
当用户登录后，会将用户信息存入Token中返回前端,当用户调用需要授权的接口时,需要在header中携带Token，然后拦截器中解析Token，获取用户信息，调用自定义的类(AuthNHolder)存入ThreadLocal中，当请求结束的时候，将
ThreadLocal存储数据清空,中间的过程无需在关注如何获取用户信息，只需要使用工具类的get方法即可。

场景三：解决线程安全问题

在Spring的Web项⽬中，我们通常会将业务分为Controller层，Service层，Dao层， 我们都知道@Autowired注解默认使⽤单例模式，那么不同请求线程进来之后，由于Dao层使⽤单例，那么负责数据库连接的Connection也只有⼀个， 如果每个请求线程都去连接数据库，那么就会造成线程不安全的问题，Spring是如何解决这个问题的呢？

在Spring项⽬中Dao层中装配的Connection肯定是线程安全的，其解决⽅案就是采⽤ThreadLocal⽅法，当每个请求线程使⽤Connection的时候， 都会从ThreadLocal获取⼀次，如果为null，说明没有进⾏过数据库连接，连接后存⼊ThreadLocal中，如此⼀来，每⼀个请求线程都保存有⼀份 ⾃⼰的Connection。于是便解决了线程安全问题

慎⽤的场景

1.线程池中线程调⽤使⽤ThreadLocal 由于线程池中对线程管理都是採⽤线程复⽤的⽅法。在线程池中线程⾮常难结束甚⾄于永远不会结束。这将意味着线程持续的时间将不可预測，甚⾄与JVM的⽣命周期⼀致

2.异步程序中，ThreadLocal的參数传递是不靠谱的， 由于线程将请求发送后。就不再等待远程返回结果继续向下运⾏了，真正的返回结果得到后，处理的线程可能是其他的线程。Java8中的并发流也要考虑这种情况

3.使⽤完ThreadLocal ，最好⼿动调⽤ remove() ⽅法，防⽌出现内存溢出，因为中使⽤的key为ThreadLocal的弱引⽤， 如果ThreadLocal 没有被外部强引⽤的情况下，在垃圾回收的时候会被清理掉的，但是如果value是强引⽤，不会被清理， 这样⼀来就会出现 key 为 null 的 value。

ThraedLocal详细介绍：由浅入深，全面解析ThreadLocal