Swing中至少运行两个线程…………关于事件分发线程Event-dispatching thred

Question

这个文章可以解释一部分，只是一部分    上个帖子“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()方法可以执行的快点，你就需要自己创建一个线程，用你自己的线程来作这件极其耗费事件的事。

Answer 1

这个帖子不错，为什么不直接发表？
或者自己建一个blog，在CSDN blog发表的文章也可以选择发表在中心上。有时间参观一下我的blog － http://blog.csdn.net/Unagain
欢迎提点意见建议

Answer 2

看你的blog了，原来你是专门作java GUI的啊，呵呵，拜过，拜过俺这个也是翻译的 Java Swing里面的东西，只是没有注明翻译。呵呵

Answer 3

呵呵，我也不是专门作GUI的，只是这方面兴趣比较浓一些。
作个blog挺有意思的，你不想试试？

Answer 4

呵呵  暂时不弄blog了，重点是很少发东西
呵呵