ConcurrentModificationException问题及其系统设计讨论

[wmq930626]

使用过程中，多线程开启任务时报错

[Markkkkks]

java版本：java version "1.8.0_301"
ttl版本：2.12.1
操作步骤：

1. 线程池声明：

private static final ExecutorService EXECUTOR = new ThreadPoolExecutor(8, 16, 60, TimeUnit.SECONDS, new LinkedBlockingQueue<>(), new ThreadPoolExecutor.CallerRunsPolicy());

2. 提交任务

List<Future> futures = new ArrayList<>();
for (List<RuleDTO> ruleList : ruleContainer) {
     ruleList.forEach(futures.add(EXECUTOR.submit(Objects.requireNonNull(TtlRunnable.get(() -> ...)));
}

3.主线程获取任务结果

    futures.foreach(f->{
        try {
             future.get();
        } catch (Exception e) {
             log.error("多线程异常",e);
        }
    })

异常堆栈：

[wuwen5]

与#220 重复，建议提供可复现的demo，运行时环境，是否引入其他agent

[oldratlee]

@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 你怎么看？ :")

[Markkkkks]

@oldratlee
我代为回答一下，业务逻辑中并没有做回调一下两个方法。堆栈中的错误是在future.get();这个代码中抛出的异常。

• com.alibaba.ttl.TransmittableThreadLocal#beforeExecute
• com.alibaba.ttl.TransmittableThreadLocal#afterExecute

目前猜测是否短时间内新建多个ttlRunable的时候，TTL框架在做threadLocal相关的拷贝时，在TransmittableThreadLocal的内部类com.alibaba.ttl.TransmittableThreadLocal#holder上发生了并发修改的问题？

[Markkkkks]

在提交到TtlRunnable到线程池的时候，在TtlRunnable结束前有调用com.alibaba.ttl.TransmittableThreadLocal#remove做当前线程Context的清除，不知道是否是这个操作不合理

[wuwen5]

有个疑点，你的截图中的栈信息里面，restoreTtlValues方法与doExecuteCallback 方法之间有一段置入代码，我看目前版本中不存在的，是否有使用agent修改过呢？

[wuwen5]

@oldratlee 你看下呢？这个正常么， 我翻代码看应该不存在.access$400这次调用，怀疑是不是被其他agent修改过？

[wuwen5]

@Markkkkks 你确认有引入其他agent么？

[Markkkkks]

@Markkkkks 你确认有引入其他agent么？

启动参数里面仅有这个agent
-javaagent \IDEA-U\ch-0\212.5080.55\plugins\java\lib\rt\debugger-agent.jar

[wuwen5]

忽略我的疑问，栈信息没问题，那个是内部类调用产生的

[oldratlee]

目前猜测是否短时间内新建多个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

如果是这个情况，我可以很肯定是安全的。并且这样的用法，在业务中是很常见的。

[oldratlee]

根据上面提供的信息写了一个可以运行的验证demo（demo代码附下面）：

• 并发运行1万个Runnable
• 并引入运行时长的随机性，

没有出现问题。 @Markkkkks @wmq930626 @wuwen5

当然，这个demo并不能说明 一定没有 并发的ConcurrentModificationException问题。
只能概率上说明，上面提到的信息还不够有效复现；即还没有找到实际引发问题的关键。

---

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 {
    private static final ExecutorService EXECUTOR = new ThreadPoolExecutor(
            16, 16, 60, TimeUnit.SECONDS,
            new LinkedBlockingQueue<>(), Thread::new, new ThreadPoolExecutor.CallerRunsPolicy());

    private static final TransmittableThreadLocal<String> context = new TransmittableThreadLocal<>();

    public static void main(String[] args) {
        context.set("set-in-main");

        List<Future<?>> futures = IntStream.range(0, 10_000).mapToObj(num -> {
            TtlRunnable task = TtlRunnable.get(() -> {
                long ms = ThreadLocalRandom.current().nextLong(0, 7);
                sleep(ms);
                System.out.println("run in thread[" + Thread.currentThread().getName()
                        + "] with context[" + context.get() + "], num " + num + " sleep " + ms);

                // remove in summited runnable
                context.remove();
            });
            return EXECUTOR.submit(task);
        }).collect(Collectors.toList());

        futures.forEach(f -> {
            try {
                f.get();
            } catch (Exception e) {
                e.printStackTrace();
            }
        });
        EXECUTOR.shutdown();
    }

    private static void sleep(long ms) {
        try {
            Thread.sleep(ms);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
    }
}

PS：源码文件

[oldratlee]

@Markkkkks @wmq930626
期望能从你这边出这个问题的业务代码中，
分离整理 一个可以（有较大概率）复现问题的极简可运行Demo工程：❤️

• 作为一个github工程，这样大家可以用来排查
• 就像这个Issue TTL agent 与 其他agent的兼容性问题 #226 (comment) 给的liauraljl/ttl-agent-demo这个工程

否则：

• 涉及业务代码与流程，不方便有效分析与排查
• 不能方便确定 可能是哪个使用方式 引发了这个问题
  无论是TTL的问题 还是 业务使用方式问题，都一样值得排查解决掉。 😁

[Markkkkks]

期望能从你这边出这个问题的业务代码中，
分离整理 一个可以（有较大概率）复现问题的极简Demo工程

@oldratlee 是这种做法，谢谢回复与test code，了解这种处理方式是比较合适的。
我尝试在业务代码中寻找不安全的并发操作 and 用剥离业务代码的test code复现这个问题。

另外根据堆栈的信息，是在holder的WeakHashMap的fast fail机制下触发的并发修改异常，也无法从堆栈中快速发现可疑的并发操作。

请问下

1. 是否能优化堆栈的报错信息
2. 除了demo代码外，框架中是否有其他操作or机制会，调用这个WeakHashMap的put方法，导致在iterate这个Map的时候出现并发异常？