JDA开发Discord机器人多线程更新ArrayList报交互已确认异常

DevOps 小满

2026-8-28

异常诱发原因

这个报错是JDA（Java Discord API）的交互机制限制+线程/定时任务逻辑错误共同导致的：

核心规则触发点：JDA对所有交互（斜杠命令、按钮点击、模态框提交等）有强制限制：每个交互实例只能执行一次确认（ack）操作，包括reply()、deferReply()、editMessage()等响应方法，对同一个交互实例重复调用上述方法就会抛出你看到的IllegalStateException。
代码里存在几个直接触发问题的逻辑错误：
1. 线程创建完全无效：Thread updateTeams = new Thread(App.updateAll());这行代码里，updateAll()方法返回值固定为null，相当于给Thread传入了空任务，这个线程启动后不会执行任何逻辑。真正跑更新逻辑的是方法内部创建的Timer，这个Timer没有和JDA的初始化生命周期绑定，bot还没完成登录初始化就会启动定时调度。
2. 重复创建App实例：main方法里裸写的new App();没有任何赋值和启动逻辑，属于无效代码，还可能造成JDA实例重复初始化的资源冲突。
3. 静态变量持有交互对象：大概率在getOCETeams()方法或者其他逻辑里，把收到的交互事件（比如SlashCommandInteractionEvent）赋值给了静态变量长期持有，定时任务触发时会重复调用这个已被ack过的事件的响应方法，直接触发报错。
4. 共享集合线程不安全：OCETeams作为public static的ArrayList，多线程读写没有做同步处理，定时任务更新集合时如果JDA的事件处理线程正在遍历集合响应用户请求，不仅会触发并发修改异常，还可能导致上下文串用，误操作已完成响应的交互实例。
5. Timer本身的设计缺陷：Timer是单线程调度，一旦任务抛出未捕获异常就会直接终止，且无法和JDA的生命周期绑定，bot关闭后Timer仍可能运行，访问已销毁的JDA资源。

修复方案

按以下步骤调整代码即可解决问题：

修正main方法的初始化逻辑，只创建一次App实例，等JDA完全初始化完成后再启动定时任务，不要在main里直接启动未就绪的调度：

public static void main(String[] args) throws InterruptedException {
    // 全局只初始化一次Bot实例
    App bot = new App();
    // 启动Bot主线程
    new Thread(bot).start();
}

重写更新调度逻辑，抛弃返回null的写法，用JDK自带的ScheduledExecutorService替代Timer，同时绑定JDA生命周期，对共享集合做线程安全处理：

// 调度器作为实例变量持有，不要静态
private ScheduledExecutorService updateScheduler;

// 在App类的initialize()方法里，等JDA调用awaitReady()完全登录成功后，再调用这个方法启动定时任务
public void startScheduledUpdate() {
    updateScheduler = Executors.newSingleThreadScheduledExecutor();
    // 首次立即执行，之后每20分钟执行一次更新
    updateScheduler.scheduleAtFixedRate(() -> {
        try {
            System.out.println("Start updating OCE teams");
            List<Team> newTeamList = getOCETeams();
            // 替换为不可变集合，避免多线程遍历/修改冲突
            OCETeams = Collections.unmodifiableList(newTeamList);
            System.out.println("OCE teams update finished, current size: " + OCETeams.size());
        } catch (ParseException e) {
            e.printStackTrace();
        }
    }, 0, 20, TimeUnit.MINUTES);
}

// 记得在JDA的shutdown钩子中调用updateScheduler.shutdown()，避免资源泄漏

排查所有交互处理逻辑，绝对不要把Event/Interaction类型的对象赋值给静态变量长期持有：
- 每个交互事件收到后，必须在当前事件的处理上下文里完成一次ack操作，处理完成后就不要再引用这个事件对象
- 如果需要定时更新某条消息，不要持有交互事件，应该在第一次响应时拿到返回的Message实例，记录对应的频道ID和消息ID，后续更新时通过textChannel.editMessageById(messageId, content).queue()接口操作，这个接口是直接编辑消息，不需要ack交互，不会触发重复确认错误。

内容的提问来源于stack exchange，提问作者Hamish Burke