Java Swing中JFrame为何在for循环执行完成后才打开显示

Swing采用单线程UI模型，所有组件渲染、事件响应逻辑都运行在*事件调度线程（EDT）*上。你直接在EDT中调用包含长循环的renderFrames()方法，会直接阻塞整个EDT的任务队列——setVisible(true)触发的窗口绘制请求会排在耗时循环任务之后，必须等循环执行完毕才能获得线程资源完成渲染，这就是窗口迟迟不显示的核心原因。

你担心的「循环执行结束前不运行后续方法」的要求，完全可以通过SwingWorker的生命周期回调实现，不需要阻塞EDT：SwingWorker会把耗时的循环逻辑放到独立后台线程执行，不会抢占EDT的UI渲染资源，待后台任务全部执行完成后，会自动回到EDT执行后续业务逻辑，天然保证执行顺序。

改造后的代码逻辑如下：

// Swing组件初始化必须放在EDT上执行，这是Swing开发的基础规范
SwingUtilities.invokeLater(() -> {
    FrameRenderer renderer = new FrameRenderer(videoFile, getWidth(), getHeight());
    add(renderer);
    setVisible(true);

    // 泛型参数1：后台任务返回的结果类型；泛型参数2：循环过程中推送的进度/渲染数据类型
    SwingWorker<List<String>, Void> frameRenderWorker = new SwingWorker<>() {
        @Override
        protected List<String> doInBackground() throws Exception {
            // 该方法内逻辑全部运行在后台线程，不会阻塞UI渲染
            // 原有的for循环逻辑全部封装在renderFrames()中即可，直接调用
            return renderer.renderFrames();
        }

        @Override
        protected void done() {
            // 该方法仅在doInBackground执行完成后，自动在EDT上触发，不会提前执行
            try {
                // 获取后台循环生成的帧数据列表
                List<String> frames = get();
                // 移除循环过程中显示的渲染面板，避免组件重叠
                remove(renderer);
                // 执行后续业务逻辑
                DisplayFrames display = new DisplayFrames(frames, getWidth(), getHeight(), YourJFrameClass.this);
                add(display);
                // 刷新布局触发重绘
                revalidate();
                repaint();
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    };

    // 启动后台任务即可，无需阻塞当前EDT
    frameRenderWorker.execute();
});

• 如果需要在for循环执行过程中实时更新FrameRenderer的显示内容，可以在循环内调用SwingWorker的publish()方法推送当前帧的渲染数据，重写process()方法在EDT上更新面板内容，实现边计算边渲染的效果。
• 绝对不要在EDT上执行IO操作、长循环、网络请求等耗时逻辑，否则必然出现UI卡顿、窗口无响应、渲染延迟的问题。
• 不要尝试用Thread.sleep()、CountDownLatch等方式阻塞EDT等待循环结束，这类操作和直接在EDT跑循环没有区别，一样会卡住UI。

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