什么是事件分发线程

什么是事件分发线程？如何让一个任务从事件分发线程运行

串行

推测

应是监听模式，应是所有组件添加的监听器都注册到了事件分发线程中，并在事件分发线程运行，但是消息队列是串行的导致耗时任务会拖慢SWING界面

默认情况下，所有的AWT或者基于Swing的应用程序，都是开始于两个线程的。其中一个就是主线程，它处理main方法里面的代码。另外一个线程，被称作“事件分发线程”(Event-dispatching thread)，它负责处理事件、绘图、和布局。在AWT或者基于Swing的程序中，所有的事件都是由监听器来处理的，而监听器正是在这个“事件分发线程”(Event-dispatching thread)里面收到事件的。举例来说，你在actionPerformed()方法里面写的代码是自动在“事件分发线程”(Event-dispatching thread)里面被执行的(你不必为此作什么事情)。而且，这对所有其他的事件处理方法都是成立的。正是由于这个原因，“事件分发线程”(Event-dispatching thread)在Swing和AWT里面具有极其重要的作用，这个线程在维护组件状态和显示方面扮演着一个基础性的角色。
和这个“事件分发线程”(Event-dispatching thread)相关的就是一个被叫做“系统事件队列”system event queque一个FIFO队列。这个队列象别的队列一样，用先进先出的方式被填充。每个请求(就是事件)都用这个队列的顺序来执行事件处理代码，而不管这个请求是否会更新组件的properties, layout, or painting。所有的事件都是一个个的被串行处理的，之所以这么作就是为了避免这中情况----组件在被重绘的过程中，其状态被修改。所以说嘛，知道了这点，如果你想要在“事件分发线程”(Event-dispatching thread)外再dispatch events时就要小心了。举例来说，在一个单独的线程(无论时在main线程里面，还是在你自己创建的线程)里面，调用fireXX()方法都是不安全的。
既然，“事件分发线程”(Event-dispatching thread)要执行所有的监听器里面的方法，painting, layou等，那么event-handling, painting,以及layout等方法必须要快速执行，就变的相当的重要了。否则的话，这个“系统事件队列”system event queue就会为了等待一个事件处理，比方说repaint、layout，的完成而被堵塞，这样你的应用程序看起来就僵住不动了。

注意：如果你对，你自己写的event-handling代码就是运行在这个“事件分发线程”(Event-dispatching thread)里面还有什么不服的话，下面的这个静态方法可以让你闭嘴。
SwingUtilities.isEventDispatchThread().这个方法会返回true或者false来表明是否你的方法时在“事件分发线程”(Event-dispatching thread)里面被调用的。

为了说明这一点，我们假设，你现在有个swing程序，这个程序有个button和一个存有数据的table。这个button被放上了ActionListener监听器，在这个ActionListener的actionPerformed()方法里面是数据库访问。在数据得到以后，数据被递交给table的model，然后table也相应的更新它的显示。那么这样的问题就是：如果当我们按下button时，连接数据库很慢，或者根本就连接不上数据库，或者从数据库里面得出了很多的数据以至于得花费一段时间来从数据库传来这些数据，这是问题就出现了，我们的GUI就会变的相当的迟钝，除非数据传送完毕了，或者异常发生了，GUI的相应才恢复快速。所以，如果想解决这个问题，保证actionPerformed()方法可以执行的快点，你就需要自己创建一个线程，用你自己的线程来作这件极其耗费事件的事。