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

This article mainly introduces "what are the common problems in writing multithreaded Java applications". In daily operation, I believe many people have doubts about the common problems in writing multithreaded Java applications. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful for you to answer the doubts about "what are the common problems in writing multithreaded Java applications?" Next, please follow the editor to study!

What is a thread?

A program or process can contain multiple threads that can execute instructions according to the code of the program. Multithreads appear to be performing their respective tasks in parallel, as if they were running multiple processors on a single computer. When implementing multithreading on multiprocessor computers, they do work in parallel. Unlike processes, threads share address space. That is, multiple threads can read and write the same variable or data structure.

When writing multithreaded programs, you must pay attention to whether each thread interferes with the work of other threads. Think of the program as an office, and if you don't need to share office resources or communicate with others, all employees will work independently and in parallel. If an employee wants to talk to others, if and only if the employee is "listening" and they both speak the same language. In addition, staff can use the photocopier only if it is idle and available (no half-finished copy work, no paper blockage, etc.). In this article you will see that threads that collaborate with each other in Java programs are like employees working in a well-organized organization.

In multithreaded programs, threads can be obtained from the ready queue and run on the available system CPU. The operating system can move a thread from the processor to the ready queue or blocking queue, in which case the processor can be thought of as "suspending" the thread. Similarly, the Java virtual machine (JVM) can control the movement of threads to move processes from the ready queue to the processor in a collaborative or preemptive model, so that the thread can start executing its program code.

The collaborative threading model allows threads to decide for themselves when to abandon the processor to wait for other threads. Program developers can determine exactly when a thread will be suspended by other threads, allowing them to cooperate effectively with each other. The disadvantage is that some malicious or poorly written threads consume all available CPU time, causing other threads to "starve."

In the preemptive threading model, the operating system can break threads at any time. It is usually interrupted after it has been running for a period of time (the so-called time slice). The natural result is that no thread can unfairly occupy the processor for a long time. However, interrupting threads at any time can cause other problems for program developers. In the same example of using the office, suppose one employee uses the copier before another, but the printing leaves before it is finished, and the other person goes on to use the copier. There may be information left by the previous employee on the photocopier.

The preemptive thread model requires threads to share resources correctly, while the collaborative model requires threads to share execution time. Because the JVM specification does not specify a threading model, Java developers must write programs that run correctly on both models. After understanding some aspects of threads and communication between threads, we can see how to design programs for these two models.

Threading and Java language

To create threads using the Java language, you can generate an object of the Thread class (or its subclasses) and send a start () message to that object. A program can send start () messages to any class object that derives from the Runnable interface. The definition of each thread action is contained in the run () method of the thread object. The run method is equivalent to the main () method in a traditional program; the thread runs until run () returns, when the thread dies.

Lock

Most applications require threads to communicate with each other to synchronize their actions. The easiest way to achieve synchronization in a Java program is to lock it. To prevent simultaneous access to a shared resource, a thread can lock and unlock the resource before and after using it. Imagine locking the photocopier and only one employee has the key at any one time. You can't use a photocopier without a key.

Locking shared variables allows Java threads to communicate and synchronize quickly and easily. If a thread locks an object, it knows that no other thread can access the object. Even in the preemptive model, other threads cannot access this object until the locked thread is awakened, the work is done, and the lock is unlocked. Threads that try to access a locked object usually go to sleep until the locked thread is unlocked. Once the lock is opened, these sleep processes are awakened and moved to the ready queue.

In Java programming, all objects have locks. Threads can use the synchronized keyword to acquire the lock. Methods or synchronized blocks of code can only be executed by one thread for an instance of a given class at any one time. This is because the code requires a lock on the object before execution. To continue our analogy about photocopiers, in order to avoid copy conflicts, we can simply synchronize copy resources.

As in the following code example, only one employee is allowed to use copy resources at any one time. Modify the status of the copier by using the method (in the Copier object). This method is the synchronization method. Only one thread can execute synchronization code in a Copier object, so employees who need to use Copier objects have to wait in line.

Class CopyMachine {public synchronized void makeCopies (Document d, int nCopies) {/ / only one thread executes this at a time} public void loadPaper () {/ / multiple threads could access this at once! Synchronized (this) {/ / only one thread accesses this at a time / / feel free to use shared resources, overwrite members, etc.}

Fine-grain lock

Using locks at the object level is usually a rough approach. Why lock the entire object instead of allowing other threads to briefly use other synchronization methods in the object to access shared resources? If an object has multiple resources, you don't need to lock all threads out just to allow a thread to use some of them. Because each object has a lock, you can use a dummy object to lock it as follows:

Class FineGrainLock {MyMemberClass x, y; Object xlock = new Object (), ylock = new Object (); public void foo () {synchronized (xlock) {/ / access x here} / / do something here-but don't use shared resources synchronized (ylock) {/ / access y here}} public void bar () {synchronized (this) {/ / access both x and y here} / / do something here-but don't use shared resources}}

To synchronize at the method level, the entire method cannot be declared as the synchronized keyword. They use member locks instead of object-level locks that can be acquired by the synchronized method.

Semaphore

Typically, there may be multiple threads that need to access a small number of resources. Imagine that there are several threads running on the server that answer client requests. These threads need to connect to the same database, but can only get a certain number of database connections at any one time. How can you effectively allocate these fixed number of database connections to a large number of threads? One way to control access to a set of resources (in addition to simply locking) is to use the well-known semaphore count (counting semaphore).

Semaphore counting encapsulates the management of a set of available resources. Semaphores are implemented on the basis of simple locking, which is equivalent to a counter that makes threads execute safely and initializes to the number of available resources. For example, we can initialize a semaphore to the number of database connections available. Once a thread acquires a semaphore, the number of database connections available is reduced by one. When the thread consumes the resource and releases it, the counter is incremented by one.

When all the resources controlled by the semaphore are occupied, if a thread tries to access the semaphore, it will enter a blocking state until available resources are released.

The most common use of semaphores is to solve the "consumer-producer problem". This problem can occur when one thread is working and another thread accesses the same shared variable. Consumer threads can access data only after the producer thread has completed production. To solve this problem by using semaphores, you need to create a semaphore initialized to zero so that the consumer thread can block access to the semaphore.

Whenever the unit work is completed, the producer thread signals the semaphore (releases resources). Whenever a consumer thread consumes a unit of production and needs a new data unit, it tries to get the semaphore again. Therefore, the value of the semaphore is always equal to the number of data units available for consumption after production. This approach is much more efficient than using consumer threads to constantly check for available data units. Because when the consumer thread wakes up, if it does not find an available data unit, it will go back to sleep, which is very expensive.

Although semaphores are not directly supported by the Java language, they are easy to implement on the basis of locking objects. A simple implementation is as follows:

Class Semaphore {private int count; public Semaphore (int n) {this.count = n;} public synchronized void acquire () {while (count = = 0) {try {wait ();} catch (InterruptedException e) {/ / keep trying}} count--;} public synchronized void release () {count++; notify (); / / alert a thread that's blocking on this semaphore}}

Common locking problems

Unfortunately, using locks can cause other problems. Let's look at some common problems and corresponding solutions:

Deadlock. Deadlocks are a classic multithreaded problem because different threads are waiting for locks that cannot be released at all, resulting in all work being impossible to complete. Suppose there are two threads, each representing two hungry people, who must share knives and forks and take turns eating. They all need to get two locks: a shared knife and a shared fork lock. Suppose thread "A" gets a knife and thread "B" gets a fork. Thread An enters the blocking state waiting for the fork, while thread B blocks to wait for the knife A has. This is just an example of artificial design, but although it is difficult to detect at run time, this often happens. Although it is very difficult to detect or deliberate various situations, deadlock problems can be avoided as long as the system is designed according to the following rules:

Let all threads acquire a set of locks in the same order. This approach eliminates the problem that the owners of X and Y are waiting for each other's resources.

Group multiple locks and put them under the same lock. In the previous deadlock example, you can create a lock for a silverware object. So you must get the lock of the silverware before you get the knife or fork.

Mark out the available resources that will not block with variables. When a thread acquires a lock on a silverware object, it can determine whether the object lock in the entire silverware collection is available by checking variables. If so, it can acquire the relevant lock, otherwise, release the silverware lock and try again later.

Most importantly, carefully design the entire system before writing the code. Multithreading is difficult, and designing the system in detail before you start programming can help you avoid the problem of finding deadlocks.

Volatile variable. The volatile keyword is designed by the Java language to optimize the compiler. Take the following code as an example:

Class VolatileTest {public void foo () {boolean flag = false; if (flag) {/ / this could happen}

An optimized compiler may determine that the statements in the if part will never be executed and will not compile this part of the code at all. If the class is accessed by multiple threads, flag can be reset by other threads after it is set by one of the previous threads and before it is tested by the if statement. By declaring variables with the volatile keyword, you can tell the compiler that you don't need to optimize this part of the code by predicting the value of the variables at compile time.

Unreachable threads can sometimes enter a blocking state even though they have no problem acquiring object locks. IO is an example of this kind of problem in Java programming. When a thread is blocked by an IO call within an object, the object should still be accessible to other threads. This object is usually responsible for canceling the blocked IO operation. The thread that blocks the call often causes the synchronization task to fail. If other methods of the object are also synchronized, the object is frozen when the thread is blocked.

Because other threads cannot acquire a lock on the object, they cannot send messages to the object (for example, cancel the IO operation). You must ensure that those blocking calls are not included in the synchronous code, or confirm that there are asynchronous methods in an object that blocks the code with synchronization. Although this approach requires some attention to ensure that the resulting code runs safely, it allows the object to respond to other threads after the thread that owns it is blocked.

Design for different threading models

Determining whether it is a preemptive or collaborative threading model depends on the implementer of the virtual machine and varies according to various implementations. Therefore, Java developers must write programs that can work on both models.

As mentioned earlier, in a preemptive model, a thread can be interrupted in the middle of any part of the code, unless it is an atomic block of code. Once the code snippet in the atomic operation code block starts execution, it is finished before the thread is swapped out of the processor.

In Java programming, allocating a variable space of less than 32 bits is an atomic operation, while the allocation of two 64-bit data types, such as double and long, is not atomic. Using locks to correctly synchronize access to shared resources is sufficient to ensure that a multithreaded program works correctly in a preemptive model.

In the collaborative model, it is entirely up to the programmer to ensure that the thread can abandon the processor normally and not plunder the execution time of other threads. Calling the yield () method moves the current thread out of the processor to the ready queue. Another method is to call the sleep () method to cause the thread to abandon the processor and sleep within the interval specified in the sleep method.

As you might expect, putting these methods somewhere in the code does not guarantee that it will work properly. If a thread is owning a lock (because it is in a synchronous method or code block), it cannot release the lock when it calls yield ().

This means that even if the thread has been suspended, other threads waiting for the lock to be released cannot continue to run. To alleviate this problem, * does not call the yield method in synchronous methods. Package the code that needs to be synchronized in a synchronous block that does not contain asynchronous methods, and yield is called outside of these synchronous blocks.

Another workaround is to call the wait () method, which causes the processor to relinquish the lock on the object it currently owns. This method works well if the object is synchronized at the method level. Because it uses only one lock. If it uses fine-grained locks, wait () will not be able to discard those locks. In addition, a thread blocked by a call to the wait () method is awakened only when other threads call notifyAll ().

Threads and AWT/Swing

In Java programs that use Swing and / or AWT packages to create GUI (user graphical interface), the AWT event handle runs in its own thread. Developers must be careful not to tie these GUI threads to time-consuming computing work because they must be responsible for processing user time and redrawing the user graphical interface. In other words, once the GUI thread is busy, the entire program looks unresponsive.

The Swing thread notifies those Swing callback (such as Mouse Listener and Action Listener) by calling the appropriate methods. This approach means that no matter how much listener has to do, it should use the listener callback method to generate other threads to do the work. The goal is to make listener callback return faster, allowing Swing threads to respond to other events.

If a Swing thread cannot run synchronously, respond to events, and redraw the output, how can other threads safely modify the state of the Swing? As mentioned above, Swing callback runs in a Swing thread. So they can modify the Swing data and draw it on the screen.

But what if it wasn't for the changes made by Swing callback? It is not safe to use a non-Swing thread to modify Swing data. Swing provides two ways to solve this problem: invokeLater () and invokeAndWait (). To modify the Swing state, simply call one of the methods and let the Runnable object do the work.

Because Runnable objects are usually their own threads, you might think that these objects will execute as threads. But it's not safe to do that either. In fact, Swing puts these objects in a queue and executes its run method at some point in the future. Only in this way can you safely modify the Swing state.

At this point, the study on "what are the common problems in writing multithreaded Java applications" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.