李鼎

> 我尝试了几次修改已经加载的class。 > > 但是`RetransformClasses`的限制又点多，会去掉`TTL`比如都实现相同的接口这类设计。 > 所以我觉得暂时只能使用规范（`TTL`在前）来避开上面的问题。 > > 后续我会使用`bytebuddy`进行尝试，但是和现在的设计区别较大。 > > 望知晓。有点抱歉 收到。辛苦了～ ♥️ @TuitaKing 期待ing～

@wmq930626 你的业务逻辑实现，是不是在 - `com.alibaba.ttl.TransmittableThreadLocal#beforeExecute` - `com.alibaba.ttl.TransmittableThreadLocal#afterExecute` 这2个业务回调（业务逻辑）中，有触发增减`TransmittableThreadLocal`实例的操作（即`holder WeakHashMap`的变更，`put`/`remove`），如`TransmittableThreadLocal#remove`。 @wmq930626 请排查确认一下，并给一下分析说明 与 结果。💕 ----------- 虽然在业务回调（`beforeExecute`/`afterExecute`）有触发增`TransmittableThreadLocal`实例的操作，应该是不合理/可靠的操作； 但即使如此，`TTL`抛异常的方式来反馈，感觉是值得优化的。 @wuwen5 你怎么看？ :")

> 目前猜测是否短时间内新建多个`ttlRunable`的时候，`TTL`框架在做`threadLocal`相关的拷贝时，在`TransmittableThreadLocal`的内部类`com.alibaba.ttl.TransmittableThreadLocal#holder`上发生了并发修改的问题？ @Markkkkks `TransmittableThreadLocal#holder`成员本身是个`ThreadLocal`，多个`ttlRunable`的修改是隔离的，不会有并发修改的问题。 > 在提交到`TtlRunnable`到线程池的时候，在`TtlRunnable`结束前有调用`com.alibaba.ttl.TransmittableThreadLocal#remove`做当前线程`Context`的清除，不知道是否是这个操作不合理 在`TtlRunnable`结束前，调用`TransmittableThreadLocal#remove`， 即是在业务的`Runnable`逻辑中调用`TransmittableThreadLocal#remove`，是吧？@Markkkkks 如果是这个情况，我可以很肯定是安全的。并且这样的用法，在业务中是很常见的。

根据上面提供的信息写了一个可以运行的验证demo（demo代码附下面）： - 并发运行1万个`Runnable` - 并引入运行时长的随机性， 没有出现问题。 @Markkkkks @wmq930626 @wuwen5 当然，这个demo并不能说明 一定没有 并发的`ConcurrentModificationException`问题。 只能概率上说明，上面提到的信息还不够有效复现；即还没有找到实际引发问题的关键。 ---------------- ```java import com.alibaba.ttl.TransmittableThreadLocal; import com.alibaba.ttl.TtlRunnable; import java.util.List; import java.util.concurrent.*; import java.util.stream.Collectors; import java.util.stream.IntStream; public class ConcurrentModificationExceptionDemo...

@Markkkkks @wmq930626 期望能从你这边出这个问题的业务代码中， 分离整理 一个可以（有较大概率）复现问题的极简可运行Demo工程：❤️ - 作为一个`github`工程，这样大家可以用来排查 - 就像这个Issue https://github.com/alibaba/transmittable-thread-local/issues/226#issuecomment-739314037 给的[`liauraljl/ttl-agent-demo`](https://github.com/liauraljl/ttl-agent-demo)这个工程 否则： - 涉及业务代码与流程，不方便有效分析与排查 - 不能方便确定 可能是哪个使用方式 引发了这个问题 无论是`TTL`的问题 还是 业务使用方式问题，都一样值得排查解决掉。 😁

> 1\. 是否能优化堆栈的报错信息 这看起来是个`JVM`的基础加强，一方面不合适`TTL`来做， 另一方面在业界我也没有发现可用方案，可能不可实现 或是 实现很困难。 @Markkkkks > 2\. 除了demo代码外，框架中是否有其他操作or机制会，调用这个`WeakHashMap`的`put`方法，导致在`iterate`这个`Map`的时候出现并发异常？ `holder WeakHashMap`的变更（`put`/`remove`方法，即增减`TransmittableThreadLocal`的操作） 只会在下面的方法中调用： - `TransmittableThreadLocal`的`get / set / remove`方法 - `Transmitter` 的 `replay / restore`方法 @Markkkkks 你可以通过`TransmittableThreadLocal`的源码再确认一遍。

#### @Markkkkks `ConcurrentModificationException`这个问题在你的业务代码可以有一定的复现率（容易运行出来）吗？ -------------- > `TransmittableThreadLocal#holder`成员本身是个`ThreadLocal`，多个`ttlRunable`的修改是隔离的，不会有并发修改的问题。 @Markkkkks 从`TTL`自身实现逻辑的分析来看，应该只可能是下面这2个业务回调引起。 我改个测试版，然后你试一下，看看会不会好了？ > 在 > > * `com.alibaba.ttl.TransmittableThreadLocal#beforeExecute` > * `com.alibaba.ttl.TransmittableThreadLocal#afterExecute` > > 这2个业务回调（业务逻辑）中，有触发增减`TransmittableThreadLocal`的操作，如`TransmittableThreadLocal#remove`。

修改好了，在分支[`expt/hotfix-293`](https://github.com/alibaba/transmittable-thread-local/tree/expt/hotfix-293)。 @Markkkkks 安装到本地，使用`TTL`版本`2.12.2-SNAPSHOT`试一下， 看看`ConcurrentModificationException`这个问题是不是好了？ ```sh git checkout expt/hotfix-293 mvn install -Dmaven.test.skip ```

> `holder WeakHashMap`的变更（`put`/`remove`方法） 只会在下面的方法中调用： > > * `TransmittableThreadLocal`的`get / set / remove`方法 > * `Transmitter` 的 `replay / restore`方法 还有一个可能是`TransmittableThreadLocal`被 GC 了。 （当然出现这个情况，`ThreadLocal`使用方式往往不合理。`ThreadLocal`的使用方式应该是作为`static`字段，是不会被 GC 的。） -------- 还要进一步确认： `WeakHashMap`在遍历过程中，`Key`被 GC 了，会不会导致`ConcurrentModificationException`异常。...

> > 修改好了，在分支[`expt/hotfix-293`](https://github.com/alibaba/transmittable-thread-local/tree/expt/hotfix-293)。 > > @Markkkkks 安装到本地，使用`TTL`版本`2.12.2-SNAPSHOT`试一下？ > > ```shell > > git checkout expt/hotfix-293 > > > > mvn install -Dmaven.test.skip > > ``` > > 好的，我试试 测试了吗，结果如何？ 😄...