下面是sun网站上JLayeredPaneDemo的代码片段
我的问题是，为什么要在事件处理线程上调用createAndShowGUI()？
为什么要在事件处理线程上初始化程序？ private static void createAndShowGUI() {
//Create and set up the window.
JFrame frame = new JFrame("LayeredPaneDemo");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); //Create and set up the content pane.
JComponent newContentPane = new LayeredPaneDemo();
newContentPane.setOpaque(true); //content panes must be opaque
frame.setContentPane(newContentPane); //Display the window.
frame.pack();
frame.setVisible(true);
} public static void main(String[] args) {
//Schedule a job for the event-dispatching thread:
//creating and showing this application's GUI.
javax.swing.SwingUtilities.invokeLater(new Runnable() {
public void run() {
createAndShowGUI();
}
});
}
我的问题是，为什么要在事件处理线程上调用createAndShowGUI()？
为什么要在事件处理线程上初始化程序？ private static void createAndShowGUI() {
//Create and set up the window.
JFrame frame = new JFrame("LayeredPaneDemo");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); //Create and set up the content pane.
JComponent newContentPane = new LayeredPaneDemo();
newContentPane.setOpaque(true); //content panes must be opaque
frame.setContentPane(newContentPane); //Display the window.
frame.pack();
frame.setVisible(true);
} public static void main(String[] args) {
//Schedule a job for the event-dispatching thread:
//creating and showing this application's GUI.
javax.swing.SwingUtilities.invokeLater(new Runnable() {
public void run() {
createAndShowGUI();
}
});
}
他直接new不也行嘛？难道这只是那些写示例代码的程序员的个人习惯？
因为Swing有专门的线程处理它的UI事件以及更新，如果我们通过主线程对其操作。可能会造成死锁和冲突。
我记得THINK IN JAVA线程那一章，说过这个问题。
下面就是说一定要在EDT上初始化GUI，可惜没给出深层次的说明。
下面的或许有用，但是俺看不懂000
1.多线程复杂，难掌握
2.单线程的话事件可以以可预测的顺序分发
3.更少花费//Thread-safe example
public class MyApplication {
public static void main(String[] args) {
JFrame f = new JFrame(...);
...//Add components to the frame here...
f.pack();
f.setVisible(true);
//Don't do any more GUI work here.
} ...
//All manipulation of the GUI -- setText, getText, etc. --
//is performed in event handlers such as actionPerformed().
...
}像这种也算线程安全的，因为它没有在主线程中涉及到影响或依赖已经realized了的组件的状态的代码
这里还是有很多值得研究啊
为什么要这样，因为大部分Swing对象方法是非线程安全的，如果以多线程方式去调用的话就会造成线程间的干涉与内存不一致错误在事件分发线程中执行就像一个排队机，在上面执行的代码就像一系列排队的任务（大部分任务都是调用事件处理方法，比如ActionListener.actionPerformed，其它任务就可以通过invokeLater或invokeAndWait来安排），任务如果不很快结束的话，就会造成未处理的事件拥堵累积且用户界面也会变得没有响应（paint方法也可以算是一个事件响应方法吧！？不管是不是，事件分发线程也是负责处理GUI drawing的）
public static void main(String[] args) throws Exception{
Runnable doHelloWorld = new Runnable() {
public void run() {
System.out.println("Hello World on " + Thread.currentThread());
try {
throwException();
} catch (Exception e) {
e.printStackTrace();
}
}
};
SwingUtilities.invokeLater(doHelloWorld);
System.out.println("This might well be displayed before the other message.");
JOptionPane.showMessageDialog(null, "DFDFDF");
} protected static void throwException() throws Exception{
throw new Exception("Hello Exception");
}
}
invokeLater 调用后直接返回
invokeAndWait 直到run方法被调用后才返回。
正好学习一下/**
* Posts a 1.1-style event to the <code>EventQueue</code>.
* If there is an existing event on the queue with the same ID
* and event source, the source <code>Component</code>'s
* <code>coalesceEvents</code> method will be called.
*
* @param theEvent an instance of <code>java.awt.AWTEvent</code>,
* or a subclass of it
*/
final void postEventPrivate(AWTEvent theEvent) {
theEvent.isPosted = true;
synchronized(this) {
if (dispatchThread == null && nextQueue == null) {
if (theEvent.getSource() == AWTAutoShutdown.getInstance()) {
return;
} else {
initDispatchThread();
}
}
if (nextQueue != null) {
// Forward event to top of EventQueue stack.
nextQueue.postEventPrivate(theEvent);
return;
}
postEvent(theEvent, getPriority(theEvent));
}
}
为什么我们要这样实现Swing呢？There are several advantages in executing all of the user interface code in a single thread:
因为在一个线程里执行用户界面代码有以下优点：
* Component developers do not have to have an in-depth understanding of threads programming: Toolkits like ViewPoint and Trestle, in which all components must fully support multithreaded access, can be difficult to extend, particularly for developers who are not expert at threads programming. Many of the toolkits developed more recently, such as SubArctic and IFC, have designs similar to Swing's.
*组件开发人员不需要深入理解线程编程：像ViewPoint和Trestle这样的工具包，它们之中的所有组件必须完全支持多线程访问，所以很难运用它们来编程，特别是不精通线程编程的开发人员。许多像SubArctic和IFC这样最近开发的工具包都和Swing有相似的设计。
* Events are dispatched in a predictable order: The runnable objects enqueued by invokeLater() are dispatched from the same event queue as mouse and keyboard events, timer events, and paint requests. In toolkits where components support multithreaded access, component changes are interleaved with event processing at the whim of the thread scheduler. This makes comprehensive testing difficult or impossible.
*用一个可以预见的方式来分发事件：invokeLater()通过分发同一事件队列中的运行对象像鼠标和键盘事件、计时器事件和画图请求来进行排队。一个在支持多线程访问的工具包中的组件改变是错综复杂的因为事件是按各自线程调度(就是具有不可预见性)来进行的。这就使得全面的测试困难或者不可能实现。
* Less overhead: Toolkits that attempt to carefully lock critical sections can spend a substantial amount of time and space managing locks. Whenever the toolkit calls a method that might be implemented in client code (for example, any public or protected method in a public class), the toolkit must save its state and release all locks so that the client code can grab locks if necessary. When control returns from the method, the toolkit must regrab its locks and restore its state. All applications bear the cost of this, even though most applications do not require concurrent access to the GUI.
*减少开销：工具包要花费特别巨大的时间和空间去管理那些工具包小心翼翼给危险局域加的锁。当这个工具包调用一个客户端编写的方法时，工具包必须保存自己的状态和释放所有需要释放的锁，以便客户端获取锁。当调用客户端代码完毕时，工具包必须重新获得刚才释放的锁和加载刚才的状态。(这是非常耗时间和空间的事情，而且对于不精通线程编程的人来说是一个灾难。而且在维护的时候也是非常困难的。)这些消耗在所有应用程序中都是占非常大的，甚至使得很多应用程序不能够顺利的进行图形界面操作。 Here's a description, written by the authors of the SubArctic Java Toolkit, of the problem of supporting multithreaded access in a toolkit:
这是SubArctic JavaToolkit作者写一个支持多线程访问的工具包中问题的说明：
It is our basic belief that extreme caution is warranted when designing and building multi-threaded applications, particularly those which have a GUI component. Use of threads can be very deceptive. In many cases they appear to greatly simplify programming by allowing design in terms of simple autonomous entities focused on a single task. In fact in some cases they do simplify design and coding. However, in almost all cases they also make debugging, testing, and maintenance vastly more difficult and sometimes impossible. Neither the training, experience, or actual practices of most programmers, nor the tools we have to help us, are designed to cope with the non-determinism.
极度谨慎是我们的基本信念当设计和编写多线程应用程序时，特别是那些有图形界面组件的应用程序。线程使用具有非常的欺骗性。在很多项目它们显得非常容易编写通过允许设计简单独立的针对一个单独任务的实体对象。(就是说设计一个线程处理一个任务，这个任务中只有一个实体对象)实际上在有些项目线程让设计和编码更加简单。然而几乎所有的项目线程都使调试、测试和维护变得更加困难得多或者不可实现。大多数程序员的培训、经验或者实战练习和专门为不是决定性判断的工具都不能帮助我们(大多数程序的努力(天才除外比如像他们这些编写人员，不过对脑细胞具有非常的杀伤力)和专门的工具都不能帮助我们解决前述多线程引起的问题)。
For example, thorough testing (which is always difficult) becomes nearly impossible when bugs are timing dependent. This is particularly true in Java where one program can run on many different types of machines and OS platforms, and where each program must work under both preemptive or non-preemptive scheduling.
例如，当bugs和时间相关联时，测试几乎无法进行。这一点在Java上尤其突出因为Java做出来的程序是跨平台的，它可以在不同类型的机器和不同操作系统上运行，程序也必须在抢占式和非抢占式调用下运行。(如果bug因为时间关系才能出现，那么测试这个代码几乎是不可能的事情。这一点在Java上表现出来就特别明显。因为Java是跨平台的，所以就需要面临不用的机器和操作系统，随之而来的是不同的调度方式（抢占式和非抢占式）。所以呢，如果事件是同时被触发而且没有一个队列来保证它们的先后顺序，那么结果就可想而知了。不同操作系统的调度方式不一样造成事件处理的先后顺序不一样，那么结果也不一样。)
As a result of these inherent difficulties, we urge you to think twice about using threads in cases where they are not absolutely necessary. However, in some cases threads are necessary (or are imposed by other software packages) and so subArctic provides a thread-safe access mechanism. This section describes this mechanism and how to use it to safely manipulate the interactor tree from an independent thread.
由于这些固有的问题(实现的时候的困难)，我们建议你在项目中使用多线程前多想想如果不是必须使用多线程的时候。然而，在一些项目中多线程是必须的，所以subArctic提供了以个线程安全的访问机制。这部分详细说明了这个机制和怎么去安全的使用它们。
The thread-safe mechanism they're referring to is very similar to the invokeLater() and invokeAndWait() methods provided by the SwingUtilities class.
这个线程安全机制就是被大家经常提到的SwingUtilities提供的invokeLater()和invokeAndWait()方法。
把初始化程序放在事件处理线程上就已经在Java虚拟机上决定了界面程序的初始化顺序。不会造成执行顺序不确定的情况。