不在事件调度线程上构建 Swing/AWT 小部件是否安全？答案

【问题标题】：Is it safe to construct Swing/AWT widgets NOT on the Event Dispatch Thread?不在事件调度线程上构建 Swing/AWT 小部件是否安全？
【发布时间】：2010-10-04 05:29:15
【问题描述】：

我一直在将Substance 外观和感觉集成到我的应用程序中，但遇到了一些关于其内部 EDT（事件调度线程）检查例程的问题。 Substance 绝对拒绝在 EDT 之外构建 UI 类。我已经做了很多 Swing/AWT 并且我知道大部分关于 EDT 的规则。我使用 SwingWorker、SwingUtilties.invokeLater 来修改组件。我一直认为组件可以在 EDT 之外构造，但必须实现和在 EDT 上被操纵。换句话说，您可以在后台构建和设置默认值，但对 pack/setVisible 的调用必须是 EDT 以及任何后续调用来操作组件。

我问的原因是我有一个特别“健壮”的窗口要构建，涉及许多小部件、状态和资源（大量图标）。以前，我在 SwingWorker 的背景方法上构建了窗口，并在 done 方法中使窗口可见。从来没有一个问题。切换到 Substance 后，内部 EDT 检查让我很头疼。

我已经能够重构代码来解决这个问题。我可以在 EDT 上进行构建，这不是一个好的解决方案，因为整个应用程序都会阻塞。我还可以进行更多重构，并尽我所能加载 EDT 之外的所有额外资源。

结束... 构造 Swing/AWT 小部件不在事件调度线程上是否安全？

【问题讨论】：

标签： java multithreading user-interface swing awt

【解决方案1】：

Sun 在 2004 年更改了规则 -- 之前，您可以在 EDT 之外创建组件，并且只有在组件实现后才能进入 EDT。

现在的新规则如下：

为了避免死锁的可能性，你必须格外小心 Swing 组件和模型被创建，修改，并且仅从事件调度线程。

this 我的博客文章提供了更多详细信息，包括指向其他相关文章的链接。请注意，所有官方 Sun examples 都已重写，并且对此非常严格。

从历史上看，多核计算机作为台式机的日益普及可能推动了规则的重新制定——线程问题在客户端堆栈上变得越来越明显，并且对 EDT 指南非常严格，很多都是可以从一开始就预防的。

【讨论】：

鬼鬼祟祟的...感谢我渴望的具体证据。是时候重构了！
竞争条件多于导致问题的死锁。
@tom：我同意竞态条件——从未声称这是死锁，我是不是（只是提到了“线程问题”）？
@tom：抱歉，我错过了明确提到死锁的引文——但如前所述，我同意你的观点，这更多是竞争条件......

【解决方案2】：

没有。

原因很简单，即使是 EDT 在极少数情况下也喜欢死锁，而且通常在使用 Swing 时很容易死锁 UI（我被告知）。我建议您阅读 Kirill（Substance 开发者）博客中的这三篇文章：

【讨论】：