62,634
社区成员
发帖
与我相关
我的任务
分享关于Java GUI 和事件处理线程的问题
下面是sun网站上JLayeredPaneDemo的代码片段
我的问题是，为什么要在事件处理线程上调用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();
}
});
}
...全文
请发表友善的回复…
发表回复
zhuyouyong 2010-06-29
- 打赏
- 举报
顶[Quote=引用 1 楼 healer_kx 的回复:]
都一样，main里面直接new也OK。
[/Quote]
都一样，main里面直接new也OK。
[/Quote]
xierangh 2010-06-29
- 打赏
- 举报
我翻译的不好的地方大家多多担待。请多多指教。
Why did we implement Swing in this way?
为什么我们要这样实现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()方法。
Why did we implement Swing in this way?
为什么我们要这样实现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()方法。
qusic 2010-06-29
- 打赏
- 举报
我引用的那篇文章有没有人能给翻译一下啊，总是觉得那篇文章很有用的说....
xierangh 2010-06-29
- 打赏
- 举报
是让程序更好的支持跨平台。
把初始化程序放在事件处理线程上就已经在Java虚拟机上决定了界面程序的初始化顺序。不会造成执行顺序不确定的情况。
[Quote=引用楼主 qusic 的回复:]
下面是sun网站上JLayeredPaneDemo的代码片段
我的问题是，为什么要在事件处理线程上调用createAndShowGUI()？
为什么要在事件处理线程上初始化程序？
Java code
private static void createAndShowGUI() {
//Create and set up the window.
……
[/Quote]
把初始化程序放在事件处理线程上就已经在Java虚拟机上决定了界面程序的初始化顺序。不会造成执行顺序不确定的情况。
[Quote=引用楼主 qusic 的回复:]
下面是sun网站上JLayeredPaneDemo的代码片段
我的问题是，为什么要在事件处理线程上调用createAndShowGUI()？
为什么要在事件处理线程上初始化程序？
Java code
private static void createAndShowGUI() {
//Create and set up the window.
……
[/Quote]
qusic 2010-06-24
- 打赏
- 举报
呀？咋没人来了呀
ronniegxq 2010-06-24
- 打赏
- 举报
不会。。。。。。。。。。
dracularking 2010-06-24
- 打赏
- 举报
invoke系是将事件在event-dispatching thread执行，看EventQueue.class
正好学习一下
正好学习一下
/**
* 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));
}
}
huntor 2010-06-24
- 打赏
- 举报
invokeLater 和 invokeAndWait 区别大了。
invokeLater 调用后直接返回
invokeAndWait 直到run方法被调用后才返回。
invokeLater 调用后直接返回
invokeAndWait 直到run方法被调用后才返回。
scelong 2010-06-24
- 打赏
- 举报
invokeLater()与invokeAndWait()方法在功能上市一样的。从API上是看不出：为什么要把创建界面的代码放在此处，那么可以从源码上可以跟踪可知，最终是生成一个InvocationEvent事件，并调用其dispatch()方法，并把new Runnable(){....createAndShowGUI()}这个对象传进去，因此，如此写法就是在主线程外，重新创建一个线程来运行new Runnable(){....createAndShowGUI()}。。。！就算在此线程内抛出了错误，都不会对主线程产生影响！呵呵，希望能帮到楼主！
public class Tests {
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");
}
}
dracularking 2010-06-24
- 打赏
- 举报
Swing的事件处理代码是运行在事件分发线程（event-dispatching thread）之上的
为什么要这样，因为大部分Swing对象方法是非线程安全的，如果以多线程方式去调用的话就会造成线程间的干涉与内存不一致错误
在事件分发线程中执行就像一个排队机，在上面执行的代码就像一系列排队的任务（大部分任务都是调用事件处理方法，比如ActionListener.actionPerformed，其它任务就可以通过invokeLater或invokeAndWait来安排），任务如果不很快结束的话，就会造成未处理的事件拥堵累积且用户界面也会变得没有响应（paint方法也可以算是一个事件响应方法吧！？不管是不是，事件分发线程也是负责处理GUI drawing的）
为什么要这样，因为大部分Swing对象方法是非线程安全的，如果以多线程方式去调用的话就会造成线程间的干涉与内存不一致错误
在事件分发线程中执行就像一个排队机，在上面执行的代码就像一系列排队的任务（大部分任务都是调用事件处理方法，比如ActionListener.actionPerformed，其它任务就可以通过invokeLater或invokeAndWait来安排），任务如果不很快结束的话，就会造成未处理的事件拥堵累积且用户界面也会变得没有响应（paint方法也可以算是一个事件响应方法吧！？不管是不是，事件分发线程也是负责处理GUI drawing的）
xiangchang224 2010-06-24
- 打赏
- 举报
UI线程是不可以阻塞的
dracularking 2010-06-24
- 打赏
- 举报
swing单线程，非线程安全，基于这些考虑
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了的组件的状态的代码
这里还是有很多值得研究啊
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了的组件的状态的代码
这里还是有很多值得研究啊
qusic 2010-06-24
- 打赏
- 举报
慢慢的顶，才不容易沉
MSDBCSD 2010-06-24
- 打赏
- 举报
有没有英文好的给解释一下咯~
qusic 2010-06-24
- 打赏
- 举报
刚才在sun的网站上看了几篇关于这方面的文章，可惜咱英文不咋的，看不太明白。
下面就是说一定要在EDT上初始化GUI，可惜没给出深层次的说明。
[Quote]
Application Launch, Initialization, and Startup
You must create and initialize your GUI on the Swing event dispatch thread (EDT). Many application developers forget this important step.
[/Quote]
下面的或许有用，但是俺看不懂000
[Quote]
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.
* 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.
* 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:
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.
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.
The thread-safe mechanism they're referring to is very similar to the invokeLater() and invokeAndWait() methods provided by the SwingUtilities class.
[/Quote]
下面就是说一定要在EDT上初始化GUI，可惜没给出深层次的说明。
[Quote]
Application Launch, Initialization, and Startup
You must create and initialize your GUI on the Swing event dispatch thread (EDT). Many application developers forget this important step.
[/Quote]
下面的或许有用，但是俺看不懂000
[Quote]
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.
* 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.
* 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:
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.
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.
The thread-safe mechanism they're referring to is very similar to the invokeLater() and invokeAndWait() methods provided by the SwingUtilities class.
[/Quote]
MSDBCSD 2010-06-24
- 打赏
- 举报
同一个用户最多只能3次连续回帖~
qusic 2010-06-23
- 打赏
- 举报
这是我在百度文库中看到的Thinking in java里关于线程部分的：
为什么说所有的用户界面动作都应该发生在事件调度线程中？
为什么说所有的用户界面动作都应该发生在事件调度线程中？
qusic 2010-06-23
- 打赏
- 举报
[Quote=引用 3 楼 closewbq 的回复:]
两种虽然都可以，但是建议将任务交给另外一个线程去做。
因为Swing有专门的线程处理它的UI事件以及更新，如果我们通过主线程对其操作。可能会造成死锁和冲突。
我记得THINK IN JAVA线程那一章，说过这个问题。
[/Quote]
哦？哪为有关于这方面死锁的例子，发出来研究研究。
另：如果这两种写法只是个人习惯而已，那我也不必纠结了，呵呵~
两种虽然都可以，但是建议将任务交给另外一个线程去做。
因为Swing有专门的线程处理它的UI事件以及更新，如果我们通过主线程对其操作。可能会造成死锁和冲突。
我记得THINK IN JAVA线程那一章，说过这个问题。
[/Quote]
哦？哪为有关于这方面死锁的例子，发出来研究研究。
另：如果这两种写法只是个人习惯而已，那我也不必纠结了，呵呵~
closewbq 2010-06-23
- 打赏
- 举报
两种虽然都可以，但是建议将任务交给另外一个线程去做。
因为Swing有专门的线程处理它的UI事件以及更新，如果我们通过主线程对其操作。可能会造成死锁和冲突。
我记得THINK IN JAVA线程那一章，说过这个问题。
因为Swing有专门的线程处理它的UI事件以及更新，如果我们通过主线程对其操作。可能会造成死锁和冲突。
我记得THINK IN JAVA线程那一章，说过这个问题。
qusic 2010-06-23
- 打赏
- 举报
[Quote=引用 1 楼 healer_kx 的回复:]
都一样，main里面直接new也OK。
[/Quote]
那为啥sun的示例代码里都是这么写的？
他直接new不也行嘛？难道这只是那些写示例代码的程序员的个人习惯？
都一样，main里面直接new也OK。
[/Quote]
那为啥sun的示例代码里都是这么写的？
他直接new不也行嘛？难道这只是那些写示例代码的程序员的个人习惯？
加载更多回复（1）
