如果您在 Swing 中打开一个对话框，例如 JFileChooser，它有点类似于以下伪代码：
swing event thread {
create dialog
add listener to dialog close event {
returnValue = somethingFromDialog
}
show dialog
(wait until it is closed)
return returnValue
}
我的问题是：这怎么可能行得通？正如您所看到的，线程等待返回，直到对话框关闭。这意味着 Swing 事件线程被阻塞。然而，人们可以与对话框进行交互，据我所知，这需要该线程来运行。
那么它是如何运作的呢？
现有的事件调度线程被阻塞，因此 swing 创建另一个线程来泵送事件。这是对话期间的事件调度线程。
Swing 创建一个单独的本机线程来泵送本机操作系统窗口消息。这与 AWT 事件线程是分开的。
在 Windows 上，您会看到这些线程
"AWT-Windows" - the native UI thread
"AWT-EventQueue-0" - the current AWT event dispatch thread
编辑：否决票是正确的。这不是真的，至少不是在所有情况下都是如此。
模态对话框通常负责泵送 AWT 事件本身。如果你运行代码
SwingUtilities.invokeAndWait(new Runnable()
{
public void run()
{
JOptionPane.showInputDialog("hello");
}
});
然后break，查看线程，你会看到只有一个EventQueue线程。 JOptionPane 的 show() 方法泵事件本身。
像这样的框架Spin http://spin.sourceforge.net/和 Foxtrot 采用相同的方法 - 它们允许您在 EDT 上创建长时间运行的阻塞方法，但通过泵送事件本身来保持事件流动。 swing 可能有多个调度线程（我确信旧版本的 swing 就是这种情况），但现在多核很常见，并发问题，特别是确保一个线程上的更改正确发布到其他线程，意味着使用多个 EDT 会在当前实现中产生错误。看多个 Swing 事件分派线程 https://stackoverflow.com/questions/859274/multiple-swing-event-dispatch-threads
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
