ThreadLocal 导致的线上问题

最新推荐文章于 2025-04-25 20:34:10 发布
原创 最新推荐文章于 2025-04-25 20:34:10 发布 · 371 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#mvc #spring #spring boot

博客讲述了在使用拦截器解析token并存储用户信息到ThreadLocal中时，遇到的一个问题：即使没有token，用户信息仍然被打印出来。作者推测这可能是由于Tomcat线程池的线程复用导致的。为了解决这个问题，作者在每次访问结束后清除了ThreadLocal中的用户信息，从而避免了后续的类似问题。

通过拦截器，当访问接口带上token时，就会进行解析token，然后把用户的信息保存到

ThreadLocal 中。就出现一个问题，即访问的时候没带token,但是用户的userId也被打印出来了。

然后就想到ThreadLocal是每个线程独享的啊，不应该介样啊。然后想到tomcat是线程池，可能就是线程复用的问题导致的。然后每次访问完就把ThreadLocal中的值删除掉，后面就没介种问题了。

 

接口访问完拦截器应该删除用户信息，应该不需要做任何逻辑，就只需要 

 

 

表妹和我纠结，线上系统因为一个ThreadLocal直接内存飙升
m0_71777195的博客
06-15 253
前言大家对于ThreadLocal这一个都应该听说过的吧，不知道大家对于这个掌握的怎么样了已这不，我那爱学习的表妹不知道又从哪里听来了这个技术点，回家就得意洋洋地给我说，表哥，我今天又学会了一个技术点ThreadLocal哦，不错啊你这态度，好像不太信的样子啊，表妹咬牙切齿地说着没没没，我信。我表妹那么聪明伶俐，肯定会不行，你这态度太敷衍了，不信我给你讲一遍得，你也先别给我讲了，你把你的Mac拿过来，我给你写个东西接过她的Mac，我三下五除二给她写了一个小例子 你先看看这段代码，给我说说你的理解表妹眉头
多线程环境下 SimpleDateFormat 引起的OOM线上问题
ab342173024的博客
02-17 734
问题现象 突然有业务反馈，某个服务接口响应很忙，赶紧放下手写的代码，看服务所在服务器的系统指标，发现cpu 内存 磁盘IO 都正常， 赶紧排查服务， 发现日志中有 java.lang.OutOfMemoryError 的异常，OOM了，内存不够用了，为了不影响线上服务使用，dump堆栈内存，重启服务，线下分析堆栈内容。 问题定位 是不是调用量增加了，jvm堆内存设置的不合理，通过监控发现，调用量并没有增加，排除jvm堆内存设置不合理的因素。 线上jvm堆内存配置2g，堆栈内存文件大概7g，压缩下30
ThreadLocal引起的一次线上事故
nidongla的博客
05-15 160
> 线上用户存储数据后查看提示无权限 前言网上购物 https://www.cqfenfa.com/ 不知道什么时候年轻的我曾一度认为Java没啥难度，没有我实现不了的需求，没有我解不了的bug 直到我遇到至今难忘的一个bug 。 线上用户存储数据后查看提示无权限 初次定位 明明自己添加的数据，为什么提示自己没有权限呢？我一开始自信的认为是我们的客户操作有问题、或者是我们权限配置有问题 但是带我自己亲自验证了一下之后发现这个问题时现时不现，属于一个偶发的问题。这个在开发阶段还真的不容易发现。.
Java后端知识体系，恐怖！ThreadLocal引起的一次线上事故
m0_60635084的博客
09-01 302
这样也是避免我们不断加入重复的用户信息。因为同一个线程对应的只可能是一个用户。 思考 public static UserInfo getUser() { return userThreadLocal.get(); } 上面是我们工具类的get方法。这就是将ThreadLocal对象存储的内容返回出去。这一步应该不会出现问题。 在getUser中很明显没有问题，我们利用排除法只剩下了setUser了。虽然排除了别人的嫌疑但是setUser我还是看不出有什么问题。经过一阵debug断点跟
记一次ThreadLocal引发的线上故障
分享Java技术知识，共同成长进步！
09-16 387
事情起因 耗子逗猫 —— 没事找事 前几天，在工作不太忙的时候，为了展示我在工作中积极主动，技术能力较强，并给领导留个好印象，我就去翻翻项目代码有没有可优化的空间。 没想到，我真让我找着啦。 祸端就此埋下了！ 有用户反馈查询订单列表接口有点慢，我就去打印每一步的耗时信息。发现查询订单之前，需要先根据用户ID查询用户信息，而查询用户信息接口需要调用用户团队提供的服务，有时候网络较慢的时候，耗时达到200毫秒。 而查询订单接口层层调用的时候，调用了好几次查询用户信息接口。当然可以改成再最上层查询一次
恐怖！ThreadLocal引起的一次线上事故
程序员干货站
05-11 402
前言 不知道什么时候年轻的我曾一度认为Java没啥难度，没有我实现不了的需求，没有我解不了的bug直到我遇到至今难忘的一个bug 。 线上用户存储数据后查看提示无权限 初次定位 明明自己添加的数据，为什么提示自己没有权限呢？我一开始自信地认为是我们的客户操作有问题、或者是我们权限配置有问题 但是带我自己亲自验证了一下之后发现这个问题时现时不现，属于一个偶发的问题。这个在开发阶段还真的不容易发现。 问题升级 经过自己的测试后让我更加怀疑人生了，你要么就有问题要么就没问题。一会有一会没有到底又是几个意思呢？偶
ThreadLocal导致的线上问题
java_liuyuan的博客
07-08 490
ThreadLocal
ThreadLocal&MDC内存泄漏问题
xiexiaojing的博客
12-25 4343
在《大话高可用》里，之前的老大有过总结，高可用就是：别人死我们不死，自己不作死，不被别人搞死。这段时间，网上都在传Log4j2的lookup远程执行代码漏洞。这个漏洞要想造成危害，基本都是...
线上故障之-内存问题
m0_46690280的博客
03-07 3685
线上故障之-内存问题内存概述内存泄漏（Memory Leak）JAVA中的内存泄露：常见的容易导致内存泄露的点内存溢出(Out Of Memory)模拟内存溢出工具 内存概述 内存泄漏（Memory Leak） 是指程序中已动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。 一般内存泄露的方式： 常发性内存泄漏：发生内存泄漏的代码会被多次执行到，每次被执行时都会导致一块内存泄漏。 偶发性内存泄漏：发生内存泄漏的代码只有在某些特定环境或操作过程
深入解析 Java 中的 ThreadLocal：原理、最佳实践与应用场景
Anarkh_Lee的博客
02-07 1578
本文全面剖析了 Java 中 ThreadLocal 的工作原理，探讨了其在多线程环境下的重要作用，并详细讲解了使用过程中常见的问题及解决方案。通过丰富的代码示例，展示了如何避免内存泄漏、处理线程池中的复用问题，以及跨线程传递值的方法。同时，结合实际应用场景，如事务管理、日志记录、数据库连接和用户信息保存，进一步阐述了 ThreadLocal 的强大功能和灵活性。
Java创建拦截器+通过ThreadLocal获取拦截器中产生的数据
MR_T3的博客
03-07 460
拦截器的使用
ThreadLocal使用，配合拦截器HandlerInterceptor使用
Bunny的博客
03-10 994
它提供了一种简单的方式来管理线程本地变量，使得每个线程都可以独立地访问和修改自己的变量副本，而不会影响其他线程的副本。需要注意的是，当前只是传入一个也可以传入多个。使用了线程封闭的设计思想，因此在使用时应当谨慎考虑其适用性，并避免滥用。我是将token放在header中的，当然也可以放在cookies中。判断当前token是否为空，如果为空返回false，不往下执行。方法来清除当前线程的变量副本，以避免内存泄漏问题。在发送请求时，携带id，最后在service层获取。在knif4j中测试，成功输出。
拦截器以及添加拦截器以及拦截安全问题-----ThreadLocal
weixin_52263247的博客
10-27 834
大家好！！！！！ 我是小杨，今天再给大家分享个拦截器以及并发时的安全问题. 首先大家都知道在写一个项目登录拦截时，肯定首先想到的就是写个拦截器，再将拦截器添加到WebMvcHandler中去，好，废话不多说，上代码. 1.1 首先我们先写一个拦截器用来拦截的我们的请求 实现该接口 HandlerInterceptor public class LoginInterceptor implements HandlerInterceptor { @Override public boolea
springboot登陆拦截器+Jwt+ThreadLocal 组合使用
小哇
09-21 2429
登陆接口。
Threadlocal+拦截器+JWT实现登录
ngczx的博客
08-28 1564
很多数据库表都会有创建时间和修改时间，这个可以用mp的自动填充来实现。也有修改人和更新人的字段，用户登录进来后，修改数据如何拿到修改人呢？每次操作不能把操作人的信息都携带者，那么如何拿到修改人的数据，主要是需要拿到id。
Springboot中的拦截器以及ThreadLocal使用
qq453660983的博客
06-14 2106
用户信息这种关键信息不适合传参的方式，前端将其封装到header里，后台通过拦截器获取，将用户信息存储在ThreadLocal里，方便拿去，也可以通过全局变量的方式。
ThreadLocal优缺点，封装及使用（在拦截中拦截请求放到threadlocal）
2201_75600005的博客
06-12 628
1、对于Thread，如果希望在Interceptor中存入User并在Service层通过ThreadLocal把User取出来，必须保证Interceptor和Service此时用的是同一个ThreadLocal。一个对象如何同时出现在Interceptor和Service呢？各自new一个ThreadLocal可不行，因为此时是两个对象了。但是简单版本存在一个问题就是只能存单个对象，如果存多个对象会覆盖掉前面的对象。这里定义了一个threadlocal的工具类,这是。
ThreadLocal详解与实战指南
最新发布
Tryingwa的博客
04-25 1558
这篇文章会让你彻底搞清楚ThreadLocal有什么用？企业开发中怎么一步步引入实践？ 本文不会附带源码讲解，举例了很多实践场景，目的就是为了让你快速上手！！！
ThreadLocal 配合 spring 拦截器 实现 数据 线程隔
tanwu1的博客
11-17 545
是 Java 中的一个类，它提供了线程局部变量，使得每个线程都可以独立地维护自己的变量副本。这对于需要在多线程环境中保持状态的情况非常有用。在 Spring 框架中，，你可以在拦截器和控制器之间传递数据，确保在同一个线程中共享信息。但请注意，要小心在适当的时候清理。可以与拦截器（Interceptor）结合使用，以实现在同一个线程中传递数据的目的。下面是一个简单的示例，演示了如何在 Spring 拦截器中使用。然后，你可以在控制器（Controller）中获取。方法中，我们将需要传递的数据设置到。
线上内存泄漏排查思路
03-23
### Java线上环境内存泄漏问题的排查方法和解决方案 #### 一、内存泄漏概述 内存泄漏是指程序运行过程中，某些不再使用的对象无法被垃圾收集器回收，导致可用内存逐渐减少。这会引发性能下降甚至 `OutOfMemoryError` 错误[^1]。 --- #### 二、内存泄漏的常见表现 1. **频繁 Full GC**：如果 JVM 的老年代区域经常触发 Full GC 并且未能有效释放内存，则可能存在内存泄漏。 2. **STW 时间过长**：长时间的 Stop-The-World (STW) 停顿可能表明存在大量不可达对象或内存分配压力过大。 3. **堆内存持续增长**：即使经过多次 Full GC，堆内存仍保持较高水平而未显著降低。 4. **特定错误提示**：如 `java.lang.OutOfMemoryError: GC overhead limit exceeded` 表明 GC 占用了过多 CPU 资源但仍无法清理足够的空间[^3]。 --- #### 三、内存泄漏的排查步骤 以下是针对线上环境中内存泄漏问题的具体排查流程： 1. **生成堆转储文件** 使用 `-XX:+HeapDumpOnOutOfMemoryError` 参数配置 JVM，在发生 OOM 时自动生成堆转储文件；或者手动执行命令： ```bash jmap -dump:live,format=b,file=heap_dump.hprof <pid> ``` 这一步骤有助于捕获当前内存状态以便后续分析[^2]。 2. **使用工具分析堆转储文件** 将生成的 `.hprof` 文件加载到专业的分析工具中（如 Eclipse MAT 或 VisualVM），定位占用内存较大的对象及其引用链路。例如，在案例中发现 ParseConfig 和 IdentityHashMap 对象占据较大比例[^4]。 3. **确认泄漏根源** 结合代码逻辑审查，验证是否存在以下潜在问题： - 静态集合类变量持有无用对象； - 缓存机制缺乏淘汰策略； - 线程局部存储 (`ThreadLocal`) 中残留数据； - 数据库连接池或其他外部资源未及时关闭。 4. **修复并验证改进效果** 修改可能导致泄漏的代码片段后重新部署服务，并观察指标变化情况（如 GC 日志统计）。必要时再次采集 dump 文件对比前后差异。 --- #### 四、解决方案建议 根据实际场景采取针对性措施来缓解或彻底消除内存泄漏隐患： | 方案类别 | 描述 | |----------------|------------------------------------------------------------------------------------------| | **代码层面** | 定期开展静态扫描与动态测试相结合的方式查找可疑点位；遵循最佳实践编写高效稳健的应用层代码 | | **框架调优** | 替换易出现问题的基础组件版本号；调整序列化/反序列化工厂默认行为以规避不必要的缓存累积 | | **资源配置** | 动态扩展物理硬件容量上限的同时优化虚拟机参数设置(-Xmx,-Xms等)，平衡吞吐量同延迟之间的关系 | 特别注意的是对于 fastjson 序列化解析引擎所暴露出来的缺陷可以通过升级至最新稳定发行版加以改善同时考虑引入其他替代品比如 Jackson 来增强系统的健壮性和兼容性。 --- ### 示例代码展示如何正确管理 ThreadLocal 变量防止泄露风险 ```java public class SafeThreadLocalExample { private static final ThreadLocal<StringBuilder> threadSafeStringBuilder = new ThreadLocal<>() { @Override protected StringBuilder initialValue() { return new StringBuilder(); } public void removeResource(){ this.remove(); // 明确移除关联实例避免长期驻留于内存之中 } }; } ``` 上述例子展示了通过重写 `remove()` 方法显式清除每个线程对应的私有副本从而杜绝因遗忘销毁操作而导致额外开销积累的可能性。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值