在事件调度线程上构造 Swing/AWT 小部件是否安全? [英] Is it safe to construct Swing/AWT widgets NOT on the Event Dispatch Thread?

问题描述

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

I've been integrating the Substance look and feel into my application and ran into several problems regarding it's internal EDT (Event Dispatch Thread) checking routines. Substance absolutely refuses to construct UI classes outside of the EDT. I've done plenty of Swing/AWT and I know most of the rules regarding the EDT. I use SwingWorker, SwingUtilties.invokeLater to modify components. I always though that components could be CONSTRUCTED outside of the EDT, but must be realized and manipulated on the EDT. In other words, you can construct and setup defaults in the background but the call to pack/setVisible must be EDT as well as any subsequent calls to manipulate the component.

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

The reason I ask is that I have a particularly "beefy" window to construct, involving many widgets, state, and resources (lots of icons). Previously, I constructed the window on the background method of a SwingWorker and made the window visible in the done method. Never had a single problem. Upon switching to Substance, the internal EDT checking bites me.

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

I've been able to refactor code to get around this. I can construct on the EDT which isn't a good solution since the entire application will block. I can also refactor even more and try my best to load all of the extra resources outside of the EDT.

总结起来......在事件调度线程上构建 Swing/AWT 小部件是否安全?

Wrapping it up ... Is it safe to construct Swing/AWT widgets NOT on the Event Dispatch Thread?

推荐答案

Sun 在 2004 年更改了规则——之前，您被允许在 EDT 之外创建组件，并且只有在组件创建完成后才必须移动到 EDT已经实现.

Sun has changed the rules in 2004 -- before, you were allowed to create the components outside the EDT and only had to move into the EDT once the component had been realized.

现在的新规则是:

为了避免死锁的可能性，你必须特别注意 Swing组件和模型被创建，已修改，并且仅从事件调度线程.

To avoid the possibility of deadlock, you must take extreme care that Swing components and models are created, modified, and queried only from the event-dispatching thread.

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

this blog post of mine gives more details, including links to other related articles. note that all official Sun examples have been rewritten and are very strict about this.

从历史上看，可能是多核计算机作为台式机的可用性不断提高，促使重新制定规则——线程问题在客户端堆栈上变得越来越明显，并且对 EDT 准则非常严格，很多都是可以从一开始就阻止的.

historically, it probably was the increasing availability of multi-core computers as desktop machines that motivated the re-formulation of the rule -- threading issues became more and more apparent on the client stack, and by being very strict on EDT guidelines, a lot of them can be prevented from the start.

这篇关于在事件调度线程上构造 Swing/AWT 小部件是否安全?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！