提供反例式的回答

如果直接用map，在capture 时清理map中的数据，同时在restore 清理map中的数据，会有什么影响？

你说的是 map 是指 holder吗？如果是，说明如下：

『在capture 时清理map中的数据』 的问题

ExecutorService executorService = ...

Runnable bizTask = ...
// <doCaptrue>  
// 在capture 时清理Holder中的数据
Runnable ttlRunnable = TtlRunnable.get();

executorService.submit(ttlRunnable);

// 后续运行，因为 Holder 没有KV了，即 后续的传递的内容是空。
// 都不会再正确传递，恢复成空。
// !!Bug!!

Runnable 后续的bizTask = ...
Runnable 后续的ttlRunnable = TtlRunnable.get();

executorService.submit(ttlRunnable);

『在restore 清理map中的数据』 的问题

提交到线程池的任务 可能 在本线程直接执行（参见 『CallerRunsPolicy』。

问题说明如下：

Runnable bizTask = ...
Runnable ttlRunnable = TtlRunnable.get();

// <doRestore>  
// 在restore 清理map中的数据
// 且是 本线程直接执行时，
executorService.submit(ttlRunnable);

// 后续运行，因为 Holder 没有KV了，即 后续的传递的内容是空。
// 都不会再正确传递，恢复成空。
// !!Bug!!

在run 的 finally 中restore 的原因也没想明白，

1. 如果线程结束了，那么 把之前的 TransmittableThreadLocal restore回来有什么意义？
2. 线程复用的话，应该是在下次线程执行时复用 启动线程的 TransmittableThreadLocal，而不是restore 的TransmittableThreadLocal。

还是 因为 『提交到线程池的任务 可能 在本线程直接执行』『Restore』确保没有上面的 Bug。

按原则的回答

原则：通过 整体流程/设计/代码实现 来 分析/证明 正确性。 @soca2013

CRR(Capture/Replay/Restore)是一个面向上下文传递设计的流程，通过这个流程的分析可以保证/证明 正确性。

这个正确性的分析/证明 ，不依赖于 局部与反例。

总结一下：尽量首先去确定分析自己程序的正确性，而不是找反例。不分析而去依赖反例，又因为经验受限找不到反例认为没问题而上线，这其实就是我们程序出bug的原因。

@soca2013 有说得不明白的地方，欢迎交流。 ❤️

PS

如果你有兴趣『整体流程与分析』推荐：

• 文档：所有TTL值的抓取、回放和恢复方法（即CRR操作）
• 可以看看『小伙伴同学们写的 设计实现解析文章（写得都很好！ ）❤️ #123』
  • 推荐 梳理一下TransmittableThreadLocal的系统流程、查看代码实现。