构建Swing/AWT小部件不是在Event Dispatch Thread上安全吗？

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

我问的原因是我有一个特别"强大"的窗口来构建,涉及许多小部件,状态和资源(许多图标).以前,我在SwingWorker的背景方法上构建了窗口,并在done方法中使窗口可见.从来没有一个问题.切换到Substance后,内部EDT检查会让我感到困惑.

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

把它包装起来...... 构建 Swing/AWT小部件不是在Event Dispatch Thread上安全吗？

Sun在2004年改变了规则 - 之前,您被允许在EDT之外创建组件,并且只有在组件实现后才必须进入EDT .

新规则现在为:

为了避免死锁的可能性,您必须特别注意仅从事件派发线程创建,修改和查询Swing组件和模型.

我的这篇博文提供了更多细节,包括其他相关文章的链接.请注意,所有正式的Sun 示例都已被重写,并且对此非常严格.

从历史上看,可能是多核计算机作为桌面计算机的日益普及促使重新制定规则 - 线程问题在客户端堆栈上变得越来越明显,并且对EDT指南非常严格,很多从一开始就可以防止它们.

没有.

简单的原因是,即使EDT在某些罕见的情况下也喜欢死锁,一般来说,使用Swing时很容易使用户界面死锁(或者我已经被告知).我建议你阅读Kirill's(Substance dev)博客上的这三篇文章:

关于Swing EDT违规的新文章

与Swing的EDT合作的不成文规则

严格检查物质中的EDT违规