不规范使用ThreadLocal导致bug如何解决
这篇文章主要讲解了“不规范使用ThreadLocal导致bug如何解决”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“不规范使用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处理线程数据,未免也太麻烦了。其实,我们可以使用拦截器或者过滤器自动帮我们完成数据的初始化以及清理工作。
感谢各位的阅读,以上就是“不规范使用ThreadLocal导致bug如何解决”的内容了,经过本文的学习后,相信大家对不规范使用ThreadLocal导致bug如何解决这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是编程网,小编将为大家推送更多相关知识点的文章,欢迎关注!
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341