Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

What are the misunderstandings in the process of coding Swing multithreading

2025-02-25 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

Shulou(Shulou.com)06/02 Report--

This article mainly explains "what misunderstandings are there in the process of coding Swing multithreading". The explanation in the article is simple and clear, and it is easy to learn and understand. below, please follow the editor's train of thought to slowly deepen, to study and learn "what misunderstandings are there in the process of coding Swing multithreading"!

1. Don't think that Swing is multithreaded. In fact, Swing's UI is single-threaded.

2. Don't think that SwingUtilities. The two invoke are multithreaded, but it is actually single-threaded

3. Don't think that invokeLater means that the current thread has finished executing before executing the target thread; think that invokeAndWait means waiting for the target thread to finish executing before executing the current thread, but in fact this is not the case at all

Problem code 1: to the effect that a remote service is invoked when a button is pressed

1.JButtonbutton=newJButton ()

2.button.addActionListener (newActionListener () {

3.@Override

4.publicvoidactionPerformed (ActionEvente) {

5.invokeRemoteService (); / / you may need to wait

6.}

7.})

In a swing system, there is a top-level java.awt.Container (which may be an instance of JFrame or JDialog) that starts an EventDispatch thread, a single thread, that handles UI events.

First, the interface Swing control submits an event to the EventQueue of EventDispatchThread, and EventDispatchThread is responsible for scheduling the execution of each event. For example, when you press a JButton, JButton executes postEvent to EventQueue, and when an ActionEvent.EventDispatchThread thread executes to that event according to the scheduling algorithm, it calls processActionEvent,JButton on JButton and then calls actionPerformed, which does not execute any newThread (). The start () code, that is, the code in JButton's ActionListener.actionPerformed () is executed entirely within the EventDispatch thread.

So, if we write time-consuming logic in any ActionListener, MouseListener and other objects, then the entire Swing system will be slow to respond, what's more, if you execute thread wait () in these Listener to wait for another thread to lock resources or calculation results, then in fact, the EventDispatchThread thread is blocked, the entire system interface will be in an unresponsive state, no response at all.

The above is caused by misunderstanding 1, and if you understand this process, it is easy to see what is wrong with the above code. The solution is also relatively simple, directly newThread (). Start (); ensures that EventDispatchThread returns quickly when it executes to the current method, so that it can respond to other events from the user interface.

What are the misunderstandings in the process of Swing multithreaded coding

Problem code 2: to the effect that a remote service is invoked when a button is pressed and other things are handled at the same time

1.JButtonbutton=newJButton ()

2.button.addActionListener (newActionListener () {

3.@Override

4.publicvoidactionPerformed (ActionEvente) {

5.Plus / position A

6.SwingUtilities.invokeLater (newRunnable () {

7.publicvoidrun () {

8.Compact / position B

9.invokeRemoteService (); / / you may need to wait

10.}

11.})

12.doOtherThing ()

13.}

14.})

The only difference between this code and the first code is that doOtherThing () can be executed before invokeRemoteService () is completed, thus creating the illusion that invokeRemoteService () / doOtherThing () seems to be executed in two threads. In fact, invokeLater packages the object code as an Event and submits it to EventQueue. After the thread of EventDispatch thread executes the doOtherThing () of the current code segment, it executes the Event in the EventQueue, which will execute the invokeRemoteService () method. However, in fact, both methods are executed in EventDispatchThread, and there is no other Thread to execute. Therefore, the problem of problem 1 is still unsolved. Actually directly newThread (). The start () method is fine, and the use of SwingUtilities is entirely an abuse caused by misunderstanding.

To test the method, add the following line of code to both location An and location B:

System.out.println (Thread.currentThread (). GetId () + Thread.currentThread (). GetName ()

The results returned are all the same:

21AWT-EventQueue-0

21AWT-EventQueue-0

In general (except for the Daemon threads created in the background when the system starts), all threads of the system that execute functional logic and business logic should be triggered by interface operations. We should know what needs or should be implemented in EventDispatchThread, which needs or should create a new thread to execute, and we need to be aware of what logic we are currently writing.

I think the code should be divided into three layers, the first layer, the UI layer, including the Listener logic on the UI control, which should be executed by EventDispatchThread, and must be short, efficient and fast return; this layer of endless things through newThread (). Start () is left to the next layer, which I call the control layer; then the control layer invokes the specific business code, the third layer, the business layer. All logic triggered by the UI control should be divided in this way.

Another problem is that Swing does not recommend modifying the interface outside of EventDispatchThread, so if we need to repaint a control at the business layer, or what should we do with updateUI, we can use SwingUtilities to deal with it? this is the scenario for the correct use of SwingUtilities and the purpose of designing this tool.

Thank you for your reading, the above is "coding Swing multithreading process what misunderstanding" content, after the study of this article, I believe you on the coding Swing multithreading process what misunderstanding of this problem has a deeper understanding, the specific use of the need for practice to verify. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report