高并发串数据元凶：ThreadLocal共享状态泄漏排查实录

1. 一场“串数据”引发的诡异故障

做后端服务排查的人，多少都遇到过这种场景：用户明明登录的是自己的账号，却在某个页面看到了别人的订单尾号；日志里链路追踪ID时而对得上，时而对不上；灰度流量标记偶尔漂移，导致一小部分用户被路由到了新功能上。我一度以为是自己业务代码的权限校验写错了，熬夜翻了几遍代码也没找到问题。后来靠一场“口令实验”才揭开了黑盒的一角——真正的元凶是藏在框架深处的共享状态，而这件事的本质，是隔离机制被静悄悄打破了。今天就把这次排查的完整过程、底层原理和解决办法整理出来，给同样被串数据折磨的人一个参考。

先说背景。当时我们维护的是一个用户画像查询服务，请求链路是Nginx到网关，再到业务服务，最后调用底层的画像计算接口。服务本身不复杂，业务逻辑也不多，但偶尔会有客服反馈：同一个查询接口，返回的画像标签里混入了其他用户的特征。听起来很像缓存key拼接错误，或者是接口权限缺陷。

1.1 监控正常，但用户数据“串”了

收到反馈后，我第一反应是查缓存。用户画像类服务，为了性能都会引入Redis或者本地缓存，我怀疑是不是把userId拼进了缓存key，但某个分支漏写了这个参数。于是把查询逻辑从头到尾review了一遍，发现缓存key、数据库查询条件、底层服务入参都带了userId，没有任何一个环节省略。权限校验也查了，接口路径、用户身份、资源归属对得上，没有越权的可能。

更让人头疼的是，错误率曲线是平的，监控告警一条都没触发。这就形成了一个很矛盾的局面：线上确实有串数据现象，但所有系统指标看起来都是正常的。如果问题出在业务代码里，压测模拟几个不同用户并发访问，应该能复现出来。可我用JMeter跑了半天多用户并发，结果全部正常，没有任何串数据。越是这样，越说明问题藏在一个我们看不见的状态里。

这种“表面全对、实际出错”的故障，往往不是逻辑错误，而是某个被复用的状态在作祟。比如请求对象被共享了，某个用户的数据写入到了另一个用户的上下文里；或者业务代码没问题，但框架层某个上下文传递器悄悄把上一个请求的残留值带了出来。业务代码再正确，也抵不住一个隐形的共享变量在背后捣乱。

1.2 为什么常规排查手段会失灵

常规排查手段失灵，是因为问题触发条件太苛刻。偶发串数据通常只在特定并发量、特定接口组合、特定线程复用时才会出现，复现概率可能低于千分之一。压测工具往往模拟的是“同一时间点大量用户同时访问”，但实际线上错乱是“同一个线程先后执行两个请求”时发生的，压测如果线程池参数不一样，就很难暴露。

监控系统的盲区也很致命。常规监控看的是平均值、P90、P99、错误数，偶发的状态串位不会显著拉高这些指标，线上服务也不会因此出现5xx错误。日志倒是会记录traceId，可如果traceId本身就是在共享状态里读出来的，那日志链也会被骗——我们看到的是一个完整但错误的调用链。

这时候需要一条能够穿透整个黑盒的“探针”：不再依赖系统自带的traceId，而是人为构造一个更显眼、更可控的标记，把它塞进请求里，观察它在整个链路中的传播轨迹。在标记出现错位的那一刻，共享路径就会自己暴露出来。这就是我所说的“口令实验”。

1.3 口令实验：给每个请求发一张“身份证”

“口令”这个词在本文里不是密码，而是一个唯一字符串。你可以把它放进HTTP Header，放进消息体字段，也可以让它跟随日志输出。具体做法是：每个请求携带一个独一无二的口令，比如exp_20240101_001，然后用可控的并发量发请求，最后在所有出口处搜索这个口令的落点。

如果A请求的口令出现在了B请求的响应里，或者A请求携带的口令被底层接口打印成了另一个口令，那就说明某个共享状态把两个请求的信息混在了一起。用这个结果，我们可以直接把问题定位到某一层：是入口没传对，是中间件改写了，还是底层服务读错了上下文。这套实验的核心价值在于，它把“模糊的串数据现象”变成了“明确的标记错位证据”，不用再去猜是谁污染了谁，口令自己会说话。

2. 共享状态为什么是“隔离问题”的根源

做分布式和并发开发这么久，我越来越觉得“共享状态”四个字就是很多诡异故障的原点。它看不见摸不着，平时运行得好好的，但只要某个并发边界处理不当，就会突然给你颜色看。先把这个概念拆清楚。

2.1 先定义清楚：到底什么是共享状态

共享状态，指的是可以被多个执行单元同时访问、同时修改的数据。在服务端场景里，常见的有这几种：静态变量和全局Map、进程内的本地缓存、线程池工作线程上的ThreadLocal、连接池里的连接对象、以及框架或SDK内部用于透传上下文的Holder对象。

共享状态本身不是原罪，并发环境里到处都有共享资源。真正的麻烦在于，共享状态被某个请求写入后，没有在请求结束时清理或恢复。比如一个static Map里存了用户ID和用户名的映射，第一个请求写入后就再也不动，第二个请求读的时候拿到的是别人的映射，这就是“状态泄漏”。用专业一点的话说：共享状态的变更本应限定在单个请求的边界内，结果它的生命周期被延长到了多个请求，隔离性随之破裂。

2.2 隔离问题的三个层级

我习惯把隔离分成三层来看，排查时对照着找，效率会高很多。

第一层是数据隔离，也就是每个用户的数据通过用户ID区分，数据库查询、缓存key都带这个ID。这一层是我们最熟悉的，通常业务代码出问题也在这里。第二层是请求隔离，指每个请求拥有独立上下文，请求A的线程本地变量不应该让请求B读到。第三层是线程隔离，指线程执行过程中，不应该读到之前任务遗留的任何残留状态。

大多数诡异故障出在第二层和第三层的错位。比如中间件用ThreadLocal存放当前请求的用户信息，按设计，请求结束就应该清理。可一旦发生线程池复用、异步切换线程、或者异常路径没有进入清理逻辑，ThreadLocal里的旧值就会被下一个请求继承。更隐蔽的是，很多时候开发者以为清理逻辑写了，实际上只清理了主路径，异步分支、定时任务分支、消息消费分支全部漏掉了。

2.3 用一个厨房比喻讲透它

想快速向同事解释这个问题，我喜欢用一个开放的厨房来类比。一口锅是大家共享的，上一个厨师炒完辣菜没刷锅，下一个厨师直接倒油炒青菜，端出来的青菜就带辣味。这不是锅本身的问题，而是“用完不清洗”的问题。如果你规定“谁用谁刷，用前检查，用后归位”，那共享锅也能用得很顺。

ThreadLocal泄漏在比喻里也特别形象。把它想象成贴在厨师工位上的一张便签，上一个厨师在便签上写了“这单是微辣”，下班时忘了撕掉，第二天接班厨师看到便签，以为顾客要微辣，就做错了口味。代码里的“便签”被线程池复用，上一个请求写在ThreadLocal里的用户上下文，被下一个请求原封不动读走。这个画面一旦建立起来，后面看代码时就会下意识去检查每一处ThreadLocal的remove路径。

2.4 共享状态类型速查

为了排查时快速对照，我把常见的共享状态类型、风险等级和典型症状整理成了一张表，贴出来给大家参考。

这张表的价值不在于多新奇，而在于排查时能更快划定嫌疑范围。看到“日志串号”就直接往ThreadLocal方向找，看到“偶发数据串读”先把static缓存翻一遍，很多时候比从头到尾读代码快得多。

3. 黑盒中间件：实验揭开的那个“无底洞”

业务代码排查完了，缓存、数据库、权限逻辑都干干净净，那就只剩下一个最可疑的区域——第三方中间件。尤其负责链路追踪、灰度路由、请求参数解析的组件，为了对业务无侵入，它们会自动往请求上下文里写值，业务代码看不到它们内部怎么管理状态。而这类组件，就是典型的黑盒。

3.1 为什么怀疑中间件

我当时的排查范围已经缩得很小：入口正确、Controller正确、业务逻辑正确，但底层收到的请求数据偶尔串号。这段路径中间夹着一个灰度路由SDK和一个链路追踪SDK，它们各自都对请求做了一次上下文透传。链路追踪SDK把traceId记在ThreadLocal里，每次请求结束时会清理；灰度路由SDK则负责从Header里读灰度标记，再把它塞进某个上下文字段。

表面上看，两个SDK各管各的，互不干扰。但这类SDK为了性能，经常做对象复用、字节码增强、静态缓存。有些设计得急的组件会误用一个全局线程池来传递状态，导致请求A的标记在某个分支里被写进了请求B的上下文。因为业务代码看不到这些SDK的内部实现，问题就藏在了这层黑盒里——你只知道数据在入口和出口不一样，但不知道它是在哪一段路径上被“调包”的。

3.2 实验设计：三层探针，测三层结构

既然是黑盒，那就得像做探测一样给它布传感器。我们设计了三层探针：入口探针在Nginx层打印口令Header，确认外部请求进入时口令唯一；中间探针在业务Controller入口，从请求上下文里取出当前口令打印；出口探针在底层接口调用前打印口令。三层探针同时记录线程名、时间戳、traceId，形成一个完整的事件观测点。

之所以要设计三层而不是一层，是因为只有对照才能定位。如果入口口令正常、Controller口令正常、底层口令错乱，那问题就锁死在Controller到底层之间的黑盒里。如果入口口令正常、Controller就错了，那可能是网关或反代层有问题；如果三层全错，可能是最外层就没传对。每一条线索都能帮你砍掉一半嫌疑范围。

3.3 实验结果说明了什么

第一次跑实验，结果是这样的：Nginx日志里所有请求的口令都是唯一的，没有重复；Controller入口打印的口令也全都正确；但底层接口日志里出现了错位口令——大约有千分之三的请求，拿到的口令不是自己头上带的那一个。数字不大，但足够说明问题。

进一步看线程名时，规律更清楚：错位口令总是出现在“同一个线程连续执行两个请求”的场景中。第一个请求的口令被记录进了线程的局部状态里，第二个请求进来时又从同一个局部状态里读，于是一个读成了另一个。这个现象强烈指向ThreadLocal或线程私有对象没有被清理，而不是某个全局HashMap被并发改写。因为全局Map错乱通常是无规律的，而ThreadLocal泄漏是有“跟随线程走”的特征的。

3.4 对照实验：光有现象还不够

只有一组实验是不够的，一定要加对照组。我们随后做了三组对照：第一组把并发降到1，长时间跑，结果完全正常；第二组换了一个全新的线程池，同样的代码，结果串号消失；第三组把中间件的透传功能关掉，只保留业务代码，结果也消失。三组对照做完，几乎可以实锤：问题出在中间件的线程局部状态未能及时清理。

建议你在复现类似问题时也照这个思路做。不要只跑“有问题的版本”，还要构造“没有中间件的版本”和“换线程池的版本”，对比差异才能确认责任方。排查黑盒并不怕黑盒，怕的是你只有一组孤证，没有对照，就容易被偶然现象带偏。我把这套实验沉淀成了一个最小复现工程，跑一百万次请求，概率从千分之一稳定提升到千分之三，可复现性一下就出来了。

4. 实操复盘：从“怀疑”到“实锤”的完整流程

前几节讲原理比较多，这一节把整个实验的实操过程完整复盘一遍，包括现场踩的坑和后来简化出的验证代码，你拿去就能复现。

4.1 实验现场实录

第一轮实验我犯了个错误：只往请求Header里加了口令，没有记录线程名。结果跑完只看到底层接口有串号，但完全看不出串号是怎么发生的。日志里只有口令和traceId，没有线程维度，没法判断是ThreadLocal残留还是全局缓存错乱。加上线程名后，规律才显现出来。这是第一个经验：做共享状态排查，线程名是必备观测维度。

第二轮实验加了线程名，串号特征变得非常清晰。错误口令的分布不是随机的，而是固定出现在某个线程池线程被复用后。第三轮我调整了实验参数，把并发度从50降到了8，因为高并发下日志交错太密，反而不好对号；8个并发足够触发线程复用，又容易人工核对。这一轮连续跑了二十分钟，总共发出十二万个请求，捕获到三百多次串号，发生率大约千分之二点五。

4.2 一个可以本地复现的最小示例

为了沉淀这次教训，我写了一个极简的Java示例，完整模拟“共享ThreadLocal不清理导致串数据”的场景，你可以直接跑来看效果。

import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; public class SharedStateDemo { private static final ThreadLocal<String> contextHolder = new ThreadLocal<>(); public String handle(String requestId) { // 模拟中间件从ThreadLocal中读取上下文 String context = contextHolder.get(); if (context == null) { context = "ctx-" + requestId; contextHolder.set(context); } // 模拟业务处理耗时 try { Thread.sleep(10); } catch (InterruptedException ignored) { } // 注意：这里缺少contextHolder.remove()，就是问题的根源 return "request=" + requestId + ", context=" + context + ", thread=" + Thread.currentThread().getName(); } public static void main(String[] args) throws InterruptedException { ExecutorService pool = Executors.newFixedThreadPool(2); for (int i = 0; i < 5; i++) { final int id = i; pool.submit(() -> { System.out.println(new SharedStateDemo().handle("req-" + id)); }); } pool.shutdown(); } }

跑出来的输出可能是这样：

request=req-0, context=ctx-req-0, thread=pool-1-thread-1 request=req-1, context=ctx-req-1, thread=pool-1-thread-2 request=req-2, context=ctx-req-0, thread=pool-1-thread-1 request=req-3, context=ctx-req-1, thread=pool-1-thread-2 request=req-4, context=ctx-req-0, thread=pool-1-thread-1

看到没有，req-2明明是新请求，拿到的却是ctx-req-0的旧上下文。因为thread-1在服务完req-0后，ThreadLocal里的值没有被清理，下次复用直接读到旧值。这个例子虽然简单，但已经把共享状态导致隔离被打破的完整链条演示出来了。

4.3 实验参数怎么选

实验不是乱跑，参数选不好，结论容易失真。我建议口令格式用exp_{时间戳}_{序号}，比如exp_1700000000_0001，保证唯一又可读。时间戳方便排序，序号方便人工对照。用UUID也可以，但日志里都是长串，肉眼比对很累，所以可读性很重要。

并发线程数建议从2到8之间选择。线程池太小，线程复用频率高，问题暴露快，但可能跟真实场景偏离；线程池太大，日志交错过多，不好对号。循环次数建议至少十万次以上，因为偶发问题的发生率本身很低，次数不够很难抓到足够样本。每次实验之间最好停几秒，让线程池状态稳定下来，也方便日志分批保存。

4.4 注意事项：别把实验做成事故

排查问题的心情可以理解，但实验要讲分寸。

注意：不要在线上直接压异常流量。优先使用影子环境或预发环境。如果必须在线上做小流量验证，务必用无副作用的Header字段，例如x-exp-trace，不要改动任何业务字段，也不要用实验过程触发真实的外部调用，否则可能把脏数据写进生产缓存。

还有一条：实验期间必须保留全量日志，不能只抓错误日志。因为你需要用“总请求数”和“串号次数”来估算发生率，只留错误日志的话，连分母都没有，连问题变严重了还是变轻了都无法判断。我在第一轮实验时就吃过这个亏，后来重新跑了第二轮才拿到比例。

5. 高并发串数据问题排查手册

排查过程踩了不少坑，趁着记忆还热乎，我把这类“串数据”问题的经验整理成一份可以直接套用的手册。以后真遇到，至少能少走半天弯路。

5.1 现象与原因速查表

这张表覆盖了我遇到的大部分场景。排查顺序上，我建议先查“线程名+traceId”，再看“功能开关对照”，最后才去啃那些底层源码。因为前两个手段快，第三个手段慢，有时候一个对照实验就能把第三方SDK罪魁祸首给钉死。

5.2 三个十分钟就能用上的排查手段

第一个手段，给日志加线程名。不要小看这个改动，在日志格式里把线程名加进去，排查难度会直接下降一半。遇到串数据，先确认是不是同一个线程在连续处理不同请求；如果是，ThreadLocal的嫌疑直线上升。

第二个手段，用诊断工具实时观察对象引用。以Java为例，Arthas的watch和tt命令可以观察可疑方法的入参、返回值和this对象地址。如果两个请求拿到的this对象地址相同，大概率是同一个对象被复用了；地址不同但里面的字段串了，那就要看字段是否来自静态变量。

第三个手段，给可疑共享类加临时写日志。在静态Map或ThreadLocal的set操作处记录写入时间和调用栈，异常发生后输出最近N次写入记录。这个方法特别适合追查那种“平时一致、偶尔串一下”的静态Map污染问题，效果比干瞪眼强得多。

5.3 一个被严重低估的坑：异步线程与ThreadLocal

同步线程场景都快排查烂了，但有一个坑被严重低估：异步线程。很多线上服务会用线程池异步执行耗时操作，比如发通知、写审计日志、做异步画像计算。如果用ThreadLocal承载请求上下文，这些异步线程根本拿不到父线程的值。于是开发者会在异步入口处手动从父线程set一份值过去，可往往只做了set，没做remove。

结果就是：异步线程池里线程被复用，任务B读到了任务A留下的上下文。这种问题比同步场景更隐蔽，因为异步日志往往没有被放进完整的日志链路里，串号现象更随机。用口令实验同样能抓它：把所有异步任务入口也加上口令打印，跑一轮并发就能看出是否有异步分支在复用上一个任务的状态。

6. 隔离问题解决后，我们怎么重构

定位到根因之后，剩下的问题就是如何改造。黑盒揭开了，但“怎么修”又是另一个需要谨慎决策的事。我们当时评估了三种方案，都在生产环境验证过，各有取舍。

6.1 方案一：显式传递上下文对象

第一个方案是最彻底的：放弃ThreadLocal，直接在方法参数里传递一个显式的RequestContext对象。所有需要读取上下文状态的地方，都从这个对象里取。业务逻辑不再依赖任何隐式的线程局部状态，也就没有泄漏的可能。

这个方案的优点是逻辑完全透明，代码里一眼能看到状态的来源和去向；缺点是改动量大，业务代码和中间件内部都要大改，而且老代码里的隐式依赖很难一次性清理干净。它更适合新项目，或者像我们这种小规模的内部中间件改造——范围可控，值得花成本做彻底。

6.2 方案二：线程池装饰器与清理机制

第二个方案保留ThreadLocal的便利性，但在线程池边界上做文章。核心思路是：用装饰器包装Runnable和Callable，在线程执行前把父线程的上下文复制给子线程，在任务执行结束后统一清理ThreadLocal。这类方案业界已有成熟实践，本质就是参考TransmittableThreadLocal的那套思想。

它被大规模采用是有原因的：业务代码几乎不用改，只需要改造线程池的提交路径。但关键是覆盖要全面，除了execute方法，submit、schedule、定时任务线程池等所有入口都要包，否则只要有漏网的异步路径，问题就会春风吹又生。我们改造后专门用口令实验重新验证了一整轮，确认没有遗漏才敢下线旧的中间件开关。

6.3 方案三：黑盒中间件先“绕行”

第三方中间件如果不及时修复，我们也不能干等。绕行方案是先把容易产生共享状态的特性开关关掉，比如灰度透传、流量染色这类功能，暂时用我们自己的显式传递逻辑替代。功能上会损失一部分，但稳定性优先，等SDK厂商修复后再逐步收回。

这种方案短期看有效，但长期看属于权宜之计。毕竟绕行会增加一层自维护逻辑，而且如果中间件升级后修复了，自维护的那套代码就要及时下线，不然两套逻辑叠加，反而引入新的混乱。我建议给这类绕行方案设一个有效期，到期后强制回归官方组件。

6.4 三种方案如何选择

三种方案的取舍，整理成一张表更直观：

我的建议是：能用线程池装饰器解决的就先上装饰器，成本适中、收益稳定；新建模块直接采用显式上下文，从源头杜绝隐患；第三方SDK的问题，绕行只是过渡，最终还是要推动它上游修复，或者换掉它。没有万能的方案，只有适不适合当前团队投入和线上容错能力的取舍。

这次踩坑之后，我把“口令实验”沉淀成了一套可复用的测试模板：凡是引入新的中间件、升级依赖版本、或者重构线程池，都会先跑一遍三层探针实验。用一句话总结我最大的体会：黑盒本身并不可怕，可怕的是没有任何手段能让它开口说话。给每个请求发一张随机口令的身份证，让它在链路里走一圈，就能撬开很多平时看不到的隐蔽角落。下次再遇到类似串数据问题，你也可以试试这个方法。