局部变量天然线程安全，应通过参数传递、ScopedValue和虚拟线程将共享状态转为线程独占的局部数据流，读操作无锁，写操作归集异步处理。
局部变量天然线程安全，因为每个线程执行时拥有独立的栈帧，变量存于其中，不与其他线程共享。重构臃肿并发模型的关键，不是加锁或调优锁粒度，而是把原本被多个线程争抢的“共享状态”，转为每个线程内部独占的局部数据流——这比任何锁优化都更彻底、更轻量。
用局部变量替代全局/静态上下文
很多臃肿模型源于滥用静态字段或单例管理请求上下文（如用户ID、租户标识、追踪ID）。这类设计迫使所有线程竞争同一份内存，还常搭配synchronized或ReentrantLock补救。直接改用方法参数+局部变量传递：
- 将请求解析后的关键信息（如
tenantId、requestId）作为入参传入业务链路首层，后续每层只接收所需字段，不依赖隐式上下文 - 避免使用
RequestContextHolder类或自定义static ThreadLocal<Context>；若必须跨多层，优先用ScopedValue（Java 20+），它绑定到虚拟线程生命周期，自动清理，比ThreadLocal更安全 - 例如：Web层解析出
userId后，直接传给服务层方法orderService.create(userId, orderDto)，而非在中间层反复调用Context.get().getUserId()
把状态机逻辑收进单一线程栈内
订单、支付、审批等流程类场景，本质是单个实体的状态演进。传统做法把状态存在数据库或缓存中，各服务并发读写，再靠分布式锁保一致——这是典型“共享+争抢”模式。应改为：一个请求对应一个执行单元（虚拟线程 / 协程），整个状态流转在该单元的栈内串行完成。
- 每个订单创建即启动一个虚拟线程：
Thread.ofVirtual().start(() -> processOrder(orderId)) - 状态变更全部基于局部
Order实例操作（可用record保证不可变），不修改任何共享堆对象 - 外部资源访问（如库存扣减、消息发送）延后到最终确认阶段，且通过原子指令（如Redis Lua脚本、DB唯一约束插入）实现无锁提交
用作用域值（ScopedValue）安全传递隐式上下文
当参数传递确实导致签名爆炸（如10层调用只为透传一个traceId），ScopedValue是比ThreadLocal更现代的选择。它不可变、绑定到虚拟线程、退出作用域自动失效，杜绝泄漏与误读。
- 声明：
private static final ScopedValue<String> TRACE_ID = ScopedValue.newInstance(); - 绑定并执行：
ScopedValue.where(TRACE_ID, "t-abc123").run(() -> handleRequest()); - 任意深度的方法中均可安全调用
TRACE_ID.get()，但其他线程即使持有该变量引用也无法访问其值 - 不推荐用
final字段模拟隔离——final只锁引用，不锁内容；也不要用finally手动清理，时机不可控
共享写操作统一归集，读完全无锁
重构后，读操作彻底摆脱锁：所有状态都在局部变量或作用域值中，直接读取即可。写操作则不再分散在各处，而是集中到一个轻量通道中异步批量处理。
- 虚拟线程内只生成变更指令（如
new InventoryDeductCmd(productId, qty)），不执行实际扣减 - 所有指令发往无锁队列（
ConcurrentLinkedQueue），由单个调度线程消费并落库 - 查询类接口可直连只读副本或本地缓存，完全不参与写路径，零锁开销
