排查单例Bean状态共享问题需聚焦非final非static final实例变量，检查基础类型、包装类、集合等是否被并发读写；通过多线程单元测试、日志打印及内存快照验证串号；追溯依赖链与作用域，避免静态变量和上下文误存；修复应优先删除冗余字段、使用ThreadLocal或线程安全类型，并在CI中强制校验。
排查这类问题，核心是识别“本该无状态的单例 Bean”为何在运行时表现出状态共享行为。关键不在于它有没有成员变量，而在于这些变量是否被多线程并发写入、读取，且未做隔离。
快速定位可疑成员变量
从 Controller、Service、Component 类入手，逐个扫描所有非 final、非 static final 的实例变量：
- 重点关注 int/long/boolean 等基础类型（如
private int counter、private String tempId） - 警惕包装类（
Integer、Boolean），它们可被重新赋值，不是不可变对象 - 检查集合类（
ArrayList、HashMap），即使声明为private List<string> items;</string>，若在方法中 add/remove，就构成可变状态 - 特别注意被误用作“临时存储”的字段——例如把 HTTP 请求参数、DTO 或中间计算结果直接赋给成员变量
复现与验证数据串号现象
不依赖日志猜，用可控并发验证行为异常：
- 写一个单元测试，用
Executors.newFixedThreadPool(5)启动多个线程，分别传入不同入参调用目标方法 - 在方法入口和出口打印入参 + 成员变量值（例如：
log.info("in={}, field={}", input, sharedField)） - 观察输出：若某次调用的
input=1001，但打印出的field=2002（明显来自另一次调用），即确认串号 - 配合 JVisualVM 或 Arthas 查看该 Bean 实例的堆内存快照，确认多个线程操作的是同一个对象地址
检查 Spring 作用域与注入链路
确认“你以为的单例”是否真被当作单例使用，或意外引入了状态源头：
- 检查类上是否有
@Scope("prototype")—— 若有，却仍出现串号，说明问题不在本类，而在它所依赖的其他单例 Bean - 向上追溯所有
@Autowired的依赖，逐层检查它们是否含可变成员变量；尤其注意抽象父类中定义的protected字段（常见于 BaseService） - 确认是否混用了静态变量（
private static Map<string object> cache;</string>），静态变量与单例实例无关，但会放大串号影响范围 - 查看是否在 AOP 切面、拦截器或 Filter 中将请求上下文存入了该 Bean 的成员变量（典型反模式）
修复与加固建议
修复不是加锁或换 scope 就完事，要从设计层面切断状态泄露路径：
- 删掉所有非必要的实例变量，把数据作为方法参数传递，或封装进 final 的上下文对象（如
ReportContext） - 若必须在线程内暂存数据，优先用
ThreadLocal<t></t>，并确保在请求结束时remove()，避免内存泄漏 - 对已有状态字段，改用线程安全类型：计数用
AtomicInteger，集合用ConcurrentHashMap，但需评估是否真需要共享——多数业务场景其实不需要 - 在 CI 流程中加入静态检查规则（如 SonarQube），禁止在 @Service/@Controller 类中声明非 final 实例变量
