用栈上局部变量替代ThreadLocal是最轻量安全的重构路径，因其天然线程私有、不共享、不逃逸、无需清理，可根除内存泄漏与上下文污染风险。
直接用栈上局部变量替代 ThreadLocal，是重构臃肿并发代码最轻量、最安全的路径——因为局部变量天然线程私有，不共享、不逃逸、无需清理，从根源上消除了内存泄漏和上下文污染风险。
识别可替换的 ThreadLocal 使用场景
不是所有 ThreadLocal 都该被替换，重点盯住那些“只在单次方法调用链中流转、不跨异步边界、不需跨线程传递”的轻量状态：
- 请求处理中临时计数器（如“当前已重试次数”）
- 解析过程中的偏移量或游标位置（如 JSON 解析深度、日志行号）
- 格式化/转换过程中的中间状态（如 StringBuilder、临时缓冲数组）
- 事务内一次性生成的 ID 或序号（如子操作编号）
只要这些值不需在 线程池复用后保留、也不需在 CompletableFuture 或虚拟线程切换后延续，就完全可以用局部变量承接。
用局部变量替代 ThreadLocal 的三步改写法
以一个典型 Web 处理逻辑为例，原 ThreadLocal 写法：
private static final ThreadLocalvoid handle(Request r) { int cnt = retryCount.get() + 1; retryCount.set(cnt); process(r); }
重构为局部变量后：
-
抽离状态参数：把 retryCount 变成方法入参，例如
process(r, 0) -
递归/链式传递：在内部调用时显式累加并传入下一层，如
process(r, cnt + 1) - 避免提升作用域：绝不将局部变量引用赋给成员变量、静态变量或放入线程池任务对象的字段中
关键点在于：状态生命周期严格绑定在单次调用栈内，随方法返回自动销毁。
配合作用域变量（ScopedValue）处理必须跨层但不跨线程的场景
当调用链很深、又不想层层传参（比如审计日志、指标打点需要穿透 5~6 层方法），但又不需要异步传递时，Java 21+ 的 ScopedValue 是比 ThreadLocal 更干净的选择：
- 它绑定的是“执行作用域”，不是线程本身，天然防逃逸
- 值仅在
ScopedValue.where(...).run()块内可见，退出即失效 - 无需手动 remove，无内存泄漏隐患
示例：ScopedValue.where(RETRY_CNT, 0).run(() → process(r))，后续任意深度的方法中调用 RETRY_CNT.get() 即可获取，且不会污染其他请求或线程。
警惕 ThreadLocal 滥用的典型信号
遇到以下写法，基本可判定为过度依赖 ThreadLocal，应优先考虑局部化或 ScopedValue：
- 多个 ThreadLocal 实例集中定义在工具类中，用途模糊（如 “contextHolder”、“threadState”）
- 大量使用
try-finally { remove() }包裹，说明开发者已意识到风险但靠人工兜底 - ThreadLocal 存储 Map、DTO、甚至整个 Request 对象副本
- 同一业务模块中，既有 ThreadLocal 又有显式参数传递，逻辑割裂
这类代码往往掩盖了职责不清和数据流混乱的问题，局部变量重构过程本身，就是一次清晰的接口契约梳理。
