不规范使用ThreadLocal导致bug分析解决

因为线程重用导致的信息错乱的bug

ThreadLocal一般用于线程间的数据隔离，通过将数据缓存在ThreadLocal中，可以极大的提升性能。但是，如果错误的使用Threadlocal，可能会引起不可预期的bug，以及造成内存泄露。

有时我们会在一个接口中缓存某些数据到ThreadLocal中，但是我们要意识到，处理请求的这些线程是由tomcat提供的，而tomcat提供的线程都是配置在一个线程池中的。

也就是说，线程是可能被重用的，如果线程一旦被重用，而ThreadLocal的数据没有及时重置，就会导致数据被混乱使用。

以下方的接口为例，先获取当前线程中保存的数据信息，将参数中的name保存到ThreadLocal中以后，再获取一次。

@GetMapping(value = "/threadLocal")
public ResponseEntity<Object> threadLocal(String name) {
 String before = Thread.currentThread().getName() + ":" + threadLocal.get();
 //先获取值，理论上应该是null
 System.out.println("before:" + before);
 threadLocal.set(name);
 String after = Thread.currentThread().getName() + ":" + threadLocal.get();
 //设置完参数值再获取一次
 System.out.println("after:" + after);
 return ResponseEntity.ok().build();
}

为了尽快复现线程重用导致的问题，我们将servlet.tomcat.threads.max设置为1，这样每次请求使用的都是同一个线程。

第一次请求接口，数据看起来很正常：

但是第二次请求接口时，可以看到线程仍然是http-nio-8080-exec-1，但是before却打印出了第一次请求的参数test。

这就是因为没有及时重置ThreadLocal导致的数据错误。

正确使用的姿势

修正的办法就是处理完接口之后要及时清理ThreadLocal。

@GetMapping(value = "/threadLocal")
public ResponseEntity<Object> threadLocal(String name) {
 try {
   String before = Thread.currentThread().getName() + ":" + threadLocal.get();
   //先获取值，理论上应该是null
   System.out.println("before:" + before);
   threadLocal.set(name);
   String after = Thread.currentThread().getName() + ":" + threadLocal.get();
   //设置完参数值再获取一次
   System.out.println("after:" + after);
 } finally {
   //清理数据
   threadLocal.remove();
 }
 return ResponseEntity.ok().build();
}

更优雅的处理方式

可能也有的朋友会说，每次都要使用try finally处理线程数据，未免也太麻烦了。其实，我们可以使用 * 或者过滤器自动帮我们完成数据的初始化以及清理工作。

最后

我们在写业务代码时，正确的理解线程的全生命周期以及执行原理，对我们提升代码的健壮性其实很有帮助。有时我们觉得底层原理很枯燥乏味，开发业务就是写增删改查，多线程用的也很少，但我们只是没有意识到，我们的代码一直跑在tomcat提供的线程池中，本身就是一个多线程的环境。

除了tomcat的线程池，我们自定义的线程池其实也会有这个问题，大家可以看看自己的业务代码是否踩过这个坑。

来源：https://juejin.cn/post/7186122423040180281