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

[shaobocui]

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

Map<TransmissibleThreadLocal<?>, Object> capturedMap = (Map)captured;
Map<TransmissibleThreadLocal<?>, Object> backup = new HashMap();
Iterator<? extends Map.Entry<TransmissibleThreadLocal<?>, ?>> 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();
    }
}

[shaobocui]

ttl是lazy（只有被设置值的时候才会加到holder中）模式添加到holder当中的。当前某个线程在获取 holder ttlMap快照的时候 很可能有其他的 ttl 还没有设置过值，假如正好在 上下文拷贝的时候 holder 的map 中新增了 ttl 。 这个时候 在 replay 过程中 会把 holder 中的ttl 错误的删除掉。不理解

if (!capturedMap.containsKey(threadLocal)) { // 如果快照中没有某个 ttl，居然要从holder中删除这不是很危险么。
    i$.remove();
    threadLocal.superRemove();
}

不太能理解这三行代码的作用。没有貌似也没有问题。只是缺少一种清理 holder 的手段？ holder本身是weakHashMap.