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

In this issue, the editor will bring you about how to understand thread safety in Java Swing development. The article is rich in content and analyzed and described from a professional point of view. I hope you can get something after reading this article.

SwingAPI is designed to be powerful, flexible, and easy to use. In particular, we want to make it easy for programmers to build new Swing components, either from scratch or by extending some of the components we provide. For this purpose, we do not require Swing components to support multithreaded access. Instead, we send the request to the component and execute the request in a single thread.

Threads and Swing components are discussed here. The goal is not only to help you use SwingAPI in a thread-safe manner, but also to explain why we choose the current threading scheme.

Content:

Single-threaded rule: swimming threads can only be accessed by one thread at a time. Generally speaking, this thread is an event dispatch thread. Exception to the rule: some operations are guaranteed to be thread-safe. Event distribution: if you need to access UI from somewhere other than event handling or drawing code, you can use the invokeLater of the SwingUtilities class to require some code to be executed in the event dispatch thread. This method returns immediately and does not wait for the code to finish executing. The invokeAndWait behavior is similar to invokeLater, except that this method waits for the code to finish executing. In general, you can use invokeLater instead of this method. Here are some examples of using these API. In particular, the following classes: CardWindow, ControlPane, Player, and OverallStatusPane.

Using the invokeLater method, you can call the invokeLater method from any thread to request the event dispatch thread to run specific code. You must put the code to run in the run method of a Runnable object and set the Runnable object as a parameter to invokeLater. The invokeLater method returns immediately without waiting for the event dispatching thread to execute the specified code. This is an example of using the invokeLater method:

RunnabledoWorkRunnable=newRunnable

}

SwingUtilities.invokeLater; uses the invokeAndWait method the invokeAndWait method is similar to the invokeLater method, except that the event dispatching thread executes the specified code and then returns after the invokeAndWait method. Where possible, you should try to use invokeLater instead of invokeAndWait. If you really want to use invokeAndWait, make sure that the thread calling invokeAndWait does not hold any locks that other threads may need during the call.

This is an example of using invokeAndWait:

VoidshowHelloThereDialogthrowsException

}

SwingUtilities.invokeAndWait

}

Similarly, suppose a thread needs to access the state of GUI, such as the contents of a text field, and its code might look like this:

VoidprintTextField

ThrowsException

}

SwingUtilities.invokeAndWait

System.out.println;}

If you can avoid using threads, do so. Threads can be difficult to use and make the program's debug more difficult. In general, threads are unnecessary for strictly GUI work, such as updates to component properties. In any case, sometimes threads are necessary. The following are some typical cases of using threads: performing a time-consuming task without having to lock the event dispatching thread. Examples include situations where a large number of calculations are performed, which can result in a large number of classes being loaded, and situations where the network or disk Icano is blocked. Perform an operation repeatedly, usually at a predetermined interval of time between two operations. Wait for a message from the customer. You can use two classes to help you implement threads: SwingWorker: create a background thread to perform time-consuming operations. Timer: create a thread to execute some code or multiple times, with a user-defined delay between executions. The SwingWorker class is implemented in SwingWorker.java using the SwingWorker class, which is not included in any distribution of Java, so you must download it separately. The SwingWorker class does all the dirty work required to implement a background thread. Although many programs do not need background threads, background threads are still useful in performing time-consuming operations, which can improve the performance perception of the program.

SwingWorkersanexampleofusingSwingWorker: to use the SwingWorker class, you first need to implement a subclass of it. In the subclass, you must implement the construct method and include your long-time operations. When you instantiate a subclass of SwingWorker, SwingWorker creates a thread but does not start it. You will call the start method of your SwingWorker object to start the thread, and then the start method will call your construct method. When you need the object returned by the construct method, you can call the get method of the SwingWorker class. This is an example of using the SwingWorker class:

... / in the main method:

FinalSwingWorkerworker=newSwingWorker

}

Worker.start

...

/ / in the action event handling method:

JOptionPane.showMessageDialog)

When the program's main method calls the start method, SwingWorker starts a new thread to instantiate the ExpensiveDialogComponent. The main method also constructs a GUI consisting of a window and a button. When the user clicks the button, the program will block and, if necessary, block until the ExpensiveDialogComponent creation is complete. The program then displays a modal dialog box containing ExpensiveDialogComponent. You can find the whole program at MyApplication.java. Use the Timer class Timer class to perform an operation through an ActionListener or multiple times. When you create a timer, you can specify how often the operation will be performed, and you can specify a listener for the timer's action event. After the timer is started, the action listener's actionPerformed method is called to perform the operation. The actionPerformed method defined by the timer action listener will be called in the event dispatch thread. This means that you don't have to use the invokeLater method in it. This is an example of using the Timer class to implement an animation loop:

PublicclassAnimatorApplicationTimer

ExtendsJFrameimplementsActionListener

PublicvoidstartAnimationelse

}

PublicvoidstopAnimation

PublicvoidactionPerformed

...

}

Executing all user interface code in one thread has the advantage that component developers do not have to have a deep understanding of thread programming: all components in toolkits like ViewPoint and Trestle must fully support multithreaded access, making extension very difficult, especially for developers who are not proficient in thread programming. Some recent toolkits, such as SubArctic and IFC, use a similar design to Swing. Events are dispatched in a predictable order: invokeLater queued runnable objects are dispatched from the same queue of mouse and keyboard events, timer events, and drawing requests. In toolkits where components fully support multithreaded access, component changes are interspersed with event handling by fickle thread schedulers. This makes full testing difficult or even impossible. Lower cost: a toolkit that tries to carefully lock the critical area spends a lot of time and space on lock management. Whenever a method is called in the toolkit that may be implemented in the client code, the toolkit saves its state and releases all locks so that the client code can acquire the lock if necessary. When control is handed back to the toolkit, the toolkit must re-grasp its lock and restore its state. All applications have to bear this price, even if most applications do not require concurrent access to GUI. This is SubArcticJavaToolkit's description of the problem of supporting multithreaded access in the toolkit: our basic tenet is that extreme care must be taken when designing and building multithreaded applications, especially those that include GUI components. The use of threads can be deceptive. In many cases, they perform extremely well in simplifying programming, making it possible to design "simple autonomous entities that focus on a single task." In some cases, they do simplify design and coding. However, in almost all cases, they make debugging, testing, and maintenance much more difficult or even impossible. No matter the practice that most programmers receive, their experience and practice, or the tools we use to help ourselves, can not be used to deal with indeterminism. For example, full testing is almost impossible when bug depends on time. Especially for Java, a program must run on the operating system platforms of many different types of machines, and each program must work properly under preemptive and non-preemptive scheduling. Because of these inherent difficulties, we urge you to think twice about whether it is absolutely necessary to use threads. However, there are situations where threading is necessary, so subArctic provides a thread-safe access mechanism.

The above is the editor for you to share how to understand thread safety in Java Swing development, if you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

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.