必须在EDT中调用AWT类中的所有方法，即非Swing方法吗？

我最近了解到Sun的/ Oracle最新指南说，任何Swing对象（包括构造函数）的Swing方法都不能在EDT之外调用。

相同的严格标准是否也适用于所有“视觉”AWT课程？如果没有，**对他们来说是什么规则？

后来

re Swing和EDT：2009年的讨论。

http://www.velocityreviews.com/forums/t707173-why-does-jdk-1-6-recommend-creating-swing-components-on-the-edt.html

引用：“除了实际的线程安全性以及可见性和同步等相关问题之外，我认为还有软件问题。Swing组件通常具有某种类型的”监听器“，而这些监听器设计为在EDT上执行。

由于这些侦听器是异步的并且响应事件（如属性更改），因此在构建GUI时可能会触发这些侦听器。结果是，当您在主线程中构建时，某些侦听器正在EDT上执行，并且一些侦听器也可能在其他线程上运行（因为侦听器混淆并在错误的线程上触发）。结果是一个巨大的不可预测的混乱。“

也许他们不知道他们在谈论什么……但目前我采取的是“更安全而不是抱歉”的方法。 Potochkin， http： //weblogs.java.net/blog/alexfromsun/archive/2006/02/debugging_swing.html似乎也认为我们熟悉后来更严格的规则

multithreadingJava程序中的正确同步取决于发生在之前的关系，总结在内存一致性属性中 。 AWT组件旨在是线程安全的，在java.awt.Component的私有锁对象上进行同步。从一些历史角度看评论：

 private transient Object objectLock = new Object();

虽然这对于简单程序来说可能已经足够，但是需要更复杂的程序来依赖该实现细节的知识来validation正确的同步。这是可能的，但谁愿意接受一个脆弱的AWT GUI？

一些额外的要点：

你说：

为什么AWT？好问题。我刚刚重写的东西是基于所有Swing调用必须在EDT中完成…如果AWT稍微宽松一点，这可能会用于一些简单的GUI目的……

我的回复：
那是不好的推理。摆动是如此强大和灵活，它就像打破小狗的腿之前购买它，所以你不必走路。使用Swing，遵循几乎不可能比AWT更繁重的线程规则，并享受。线程规则是有道理的，并不难理解。再次，这篇文章是一个很好的参考。