为何JProgressBar indeterminate模式必须使用线程才能正常工作？

这本质是由Swing的单线程UI模型决定的，核心原因可以拆解为两点：

1. Swing UI操作必须在事件调度线程（EDT）中执行 #

Swing的所有组件都是线程不安全的，所有UI状态更新、重绘请求都必须交给EDT处理。EDT是一个单线程的任务队列，负责依次处理用户输入、UI渲染、组件状态更新等所有和界面相关的工作。

2. EDT绝对不能被长时间阻塞 #

如果不使用线程，直接在EDT里执行耗时的runSlowRequest()，整个流程会变成这样：

• 调用systemProcess.setIndeterminate(true)，把进度条标记为不确定模式，但这个状态更新只是把任务放进EDT队列
• 紧接着执行runSlowRequest()，直接霸占EDT，让它没法处理后续的重绘请求
• 等耗时操作结束，又立刻调用setIndeterminate(false)，把进度条切回普通模式

在这个过程中，EDT被耗时操作完全卡住，根本没时间去处理进度条的重绘任务。等它终于有空处理的时候，进度条已经被切回非不确定模式了，自然看不到任何动画，甚至组件都不会更新。

用线程解决的核心逻辑 #

不管是用SwingWorker还是SwingUtilities.invokeLater，本质都是把耗时操作和UI操作拆到不同线程：

• 耗时的runSlowRequest()放到后台线程执行，不占用EDT，保证EDT能正常处理UI渲染和用户输入
• 进度条的状态更新（setIndeterminate(true/false)）仍然在EDT中执行，符合Swing的线程安全规则

举个正确的实现示例：

JProgressBar systemProcess = new JProgressBar();
systemProcess.setString(processName);

// 用SwingWorker拆分后台任务和UI操作
new SwingWorker<Void, Void>() {
    @Override
    protected Void doInBackground() throws Exception {
        // 耗时操作在后台线程执行，不阻塞EDT
        runSlowRequest();
        return null;
    }

    @Override
    protected void beforeExecute() {
        // 启动前在EDT开启进度条动画
        systemProcess.setIndeterminate(true);
    }

    @Override
    protected void done() {
        // 任务结束后在EDT关闭动画
        systemProcess.setIndeterminate(false);
    }
}.execute();

简单说：不确定模式的进度条需要EDT持续处理重绘来展示动画，而耗时操作会把EDT卡死，必须用线程把两者分开，才能让进度条正常工作。

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