包装任务时，代码把当前上下文Map赋给一个局部变量，认为“已经捕获”。任务稍后执行，读到的却是请求结束前修改过的新值。变量确实保存了，保存的是同一个可变对象引用。
上下文传递不只有线程边界，也有对象所有权和捕获时刻。清理ThreadLocal只能处理一部分生命周期问题，不能把共享可变Map自动变成稳定快照。
本文在JDK12上对照两个Callable，使用现有单线程执行器运行。没有Spring TaskDecorator、ThreadLocal、代理或真实租户请求测试。
final局部变量也可以指向可变对象
把引用声明为final，限制的是变量不能再指向别处，并不禁止其他代码修改它指向的Map。任务延迟执行时，看到的是读取那一刻的对象内容。
即使所有代码都在同一个线程按顺序发生，这种差异也存在，不需要依赖竞争或内存可见性问题。先构造任务、再改原Map、最后执行任务，就能形成明确反例。
本例上下文只有tenant一个String值。第一份任务捕获原Map引用，第二份任务捕获Map.copyOf产生的快照。构造后将原值从synthetic-a改成synthetic-b，再依次提交两份任务。
快照保留的是哪一层内容
Map<String, String> snapshot = Map.copyOf(context);
Callable<String> task = () -> snapshot.get("tenant");
本例键值都是String，因此快照没有共享可变的嵌套载荷。若值是List、用户对象或其他可变结构，复制Map本身并不等于深拷贝；嵌套对象仍需要自己的不可变设计或复制策略。
Map.copyOf也有输入约束，不能不检查已有上下文结构就机械替换。本文只验证这份非空String键值样例，不声称所有上下文都能直接套用。
Spring TaskDecorator可以包装待执行回调，但包装位置不会替应用决定对象快照语义。真正执行的回调还可能是框架包装，不能仅根据装饰器参数名推断全部生命周期。
本地读到两个不同值
第一个Callable从共享引用读取，得到synthetic-b；第二个从快照读取，得到synthetic-a。两个结果通过Future的有时限get取得并断言，执行器最终关闭。
测试刻意在提交前完成原Map修改，因此没有并发读写HashMap，也不依赖sleep或线程调度时机。它只证明对象引用与快照的区别，没有验证并发容器或任务装饰器集成。
这个结果不能解释为租户B一定越权。样例没有任何授权动作，两个字符串只是说明捕获内容变化。真实授权仍应从可信身份与业务规则建立，不能因为捕获了一个tenant字符串就允许访问。
捕获时刻要与任务语义一致
提交时身份、开始执行时权限和当前业务状态，可能需要不同处理。任务可以保存创建者标识与受控命令内容，执行时再按要求复核权限，不把旧快照当成永久许可。
对于需要保持创建时语义的审计字段，快照有助于避免后续修改；对于必须实时生效的撤权，快照又不足以替代执行时检查。先说明字段用途，再选择何时读取。
定时任务和重试任务尤其不能借用某个偶然工作线程上的“当前请求”。它们应有明确任务身份和上下文来源，而不是从最近一次运行残留中猜测。
清理与隔离仍然要做
使用ThreadLocal的真实装饰器，仍需在结束路径恢复或移除上下文，包括正常、失败和取消情况。对象快照解决捕获内容，线程清理解决工作线程复用，两者并不互相替代。
另外，快照不应该携带整个请求、会话或大对象图。只保留任务需要的受控字段，可以减少无意引用保留与敏感内容传播。本文没有测量堆占用或日志泄露，不提供相关收益数字。
用可控顺序验证，而不是等待偶发串值
真实接入可以在任务入队后修改或清理提交线程上下文，再允许工作线程继续，核对执行内容与清理结果。若有嵌套对象，再专门修改嵌套字段，确认浅复制边界。
本文执行的是两份String值Map的顺序对照，没有完成这些Spring集成场景。它已经足以回答一个具体问题：局部变量捕获引用，不保证内容固定。
任务要继承的是一份明确的数据语义，不是一根偶然还连着请求对象的引用。把捕获时刻、对象可变性和执行时授权分别安排好，上下文才不会在排队期间悄悄换了意思。
参考资料（2026-10-20已核验）：
- Spring TaskDecorator：任务回调包装边界。
- Java12 Map：不可修改映射与copyOf；本文没有深拷贝测试。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/dicky_zhang3/article/details/170337376
