在事件调度线程上构造SWING / AWT小部件是否安全？

Question

我一直在将Substance外观整合到我的应用程序中，并遇到有关内部EDT（事件调度线程）检查例程的一些问题。物质绝对拒绝在EDT之外构造UI类。我已经做了很多Swing / AWT，并且我了解有关EDT的大多数规则。我使用SwingWorker，SwingUtilties.invokeLater修改组件。我总是尽管可以在EDT之外构造这些组件，但是必须在EDT上实现和操纵这些组件。换句话说，您可以在后台构造和设置默认值，但是对pack / setVisible的调用必须是EDT，以及随后的任何操作该组件的调用。

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

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

包装起来... 在事件调度线程上构造 Swing / AWT小部件是否安全？

Answer 1

Sun在2004年更改了规则-在此之前，您被允许在EDT之外创建组件，并且仅在实现该组件后才可以进入EDT 。现在，新规则为：为了避免发生死锁，您必须格外小心，仅从事件分发线程创建，修改和查询Swing组件和模型。我的这篇博客文章提供了更多详细信息，包括指向其他相关文章的链接。请注意，所有正式的Sun 示例都已重写，并且对此非常严格。从历史上看，可能是多核计算机作为台式机的可用性不断提高，从而重新制定了规则-线程问题在客户端堆栈上变得越来越明显，并且由于对EDT准则的要求非常严格，因此很多他们可以从一开始就被阻止。

Answer 2

没有。原因很简单，即使在少数情况下，甚至EDT也喜欢死锁，并且通常在使用Swing时很容易死锁UI（或者有人告诉我）。