ThreadLocal一般用于线程间的数据隔离，通过将数据缓存在ThreadLocal中，可以极大的提升性能。但是，如果错误的使用Threadlocal，可能会引起不可预期的bug，以及造成内存泄露。
因为线程重用导致的信息错乱的bug
有时我们会在一个接口中缓存某些数据到ThreadLocal中，但是我们要意识到，处理请求的这些线程是由tomcat提供的，而tomcat提供的线程都是配置在一个线程池中的。
也就是说，线程是可能被重用的，如果线程一旦被重用，而ThreadLocal的数据没有及时重置，就会导致数据被混乱使用。
以下方的接口为例，先获取当前线程中保存的数据信息，将参数中的name保存到ThreadLocal中以后，再获取一次。
@GetMapping(value = "/threadLocal")
public ResponseEntity
第一次请求接口，数据看起来很正常：
但是第二次请求接口时，可以看到线程仍然是http-nio-8080-exec-1，但是before却打印出了第一次请求的参数test。
这就是因为没有及时重置ThreadLocal导致的数据错误。
正确使用的姿势
修正的办法就是处理完接口之后要及时清理ThreadLocal。
@GetMapping(value = "/threadLocal")
public ResponseEntity
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的线程池，我们自定义的线程池其实也会有这个问题，大家可以看看自己的业务代码是否踩过这个坑。
