代码之家  ›  专栏  ›  技术社区  ›  basszero

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

  •  32
  • basszero  · 技术社区  · 17 年前

    我一直在整合 Substance 在我的应用程序中查找并感受到,它的内部EDT(事件调度线程)检查例程遇到了几个问题。实质绝对拒绝在EDT之外构造UI类。我已经做了很多挥杆/空翻,我知道关于EDT的大部分规则。我使用swingworker、swingutilities.invokelater来修改组件。我一直认为那些部件 构建 在EDT之外,但必须 实现 操纵的 在EDT上。换句话说,您可以在后台构造和设置默认值,但是对pack/setvisible的调用必须是edt,以及任何后续调用以操作组件。

    我之所以问这个问题,是因为我有一个特别“结实”的窗口要构建,它涉及许多小部件、状态和资源(许多图标)。以前,我在SwingWorker的后台方法上构建了窗口,并使窗口在Done方法中可见。从来没有一个问题。在转换成物质后,内部的EDT检查会咬我。

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

    把它包起来…安全吗? 建造 swing/awt小部件不在事件调度线程上?

    2 回复  |  直到 13 年前
        1
  •  39
  •   Rahel Lüthy    13 年前

    Sun在2004年改变了规则——之前,您被允许在EDT之外创建组件,并且只有在组件 实现 .

    新规则如下:

    为了避免僵局的可能性, 你必须非常小心那个秋千 组件和模型是 创建 , 修改,仅从 事件调度线程。

    this 我的博客文章提供了更多的细节,包括到其他相关文章的链接。注意所有的官方太阳 examples 已经被改写了,对此非常严格。

    从历史上看,可能是多核计算机作为台式机的日益可用性推动了规则的重新制定——线程问题在客户端堆栈上变得越来越明显,而且由于对EDT准则非常严格,许多问题从一开始就可以避免。

        2
  •  9
  •   Esko    17 年前

    不。

    简单的原因是,即使EDT在某些罕见的情况下也喜欢死锁,而且通常在使用Swing时也很容易死锁UI。( 有人告诉我 )我建议你阅读基里尔(物质发展)博客的这三篇文章: