关于快照与实时获取的ttlMap存在差异的删除逻辑 可能存在风险。

public static Object replay(Object captured) 这里replay的时候，

```java
Map, Object> capturedMap = (Map)captured;
Map, Object> backup = new HashMap();
Iterator, ?>> i$ = ((Map)TransmissibleThreadLocal.holder.get()).entrySet().iterator(); // 这是子线程获取的最新的 ttlMap

Map.Entry entry;
TransmissibleThreadLocal threadLocal;
while(i$.hasNext()) {
entry = (Map.Entry)i$.next();
threadLocal = (TransmissibleThreadLocal)entry.getKey();
backup.put(threadLocal, threadLocal.get());
if (!capturedMap.containsKey(threadLocal)) { // 如果快照中没有某个 ttl，居然要从holder中删除这不是很危险么。
// 假如当前执行这个代码的线程A，它获取到的ttl快照的时候。有10个ttl变量。从holder中再次读取的时候，是11个ttl变量。
// 这个Iterator要把当前最新holder中多出来的ttl删除 这是什么逻辑？
i$.remove();
threadLocal.superRemove();
}
}
```

Start in public static Object replay(Object captured) and inspect TransmissibleThreadLocal.holder, capturedMap, and superRemove together. Reproduce the described case where the live holder has more entries than the snapshot, then determine the intended deletion behavior and add a regression test showing that existing live values are not removed unexpectedly.

Written by the indexing model from the issue text.