Producer consumer model based on Java (detailed analysis)

Producer consumer mode is the most common mode in multithreading: producer threads (one or more) generate bread and put it into the basket (set or array), while consumer threads (one or more) take out bread from the basket (set or array) and consume it. Although they have different tasks, they process the same resources, which reflects a way of inter thread communication@ H_ 404_ 1@

This paper will first explain the situation of single producer and single consumer, and then explain the situation of multi producer and multi consumer model. The wait () / nofity () / nofityall () mechanism and lock () / unlock () mechanism will be used to implement the two modes respectively@ H_ 404_ 1@

Before introducing the pattern, explain the usage details of the wait (), notify (), and notifyAll () methods and the improved lock () / unlock (), await () / signal () / signalall ()@ H_ 404_ 1@

1. Principle of waiting and wake-up mechanism @ h_ 404_ 1@

Wait (), notify (), and notifyAll () represent the threads that put the thread to sleep, wake up the sleep thread, and wake up all the sleep threads, respectively. But which thread is the object? In addition, all three methods described in the API documentation must be used under the premise of a valid monitor (which can be understood as holding a lock). What do these three methods have to do with locks@ H_ 404_ 1@

Take synchronized code block synchronized (obj) {} or synchronization function as an example. Wait(), notify() and notifyall() can be used in their code structure because they all hold locks@ H_ 404_ 1@

For the following two synchronization code blocks, lock obj1 and lock obj2 are used respectively. Thread 1 and thread 2 execute the synchronization code corresponding to obj1, and thread 3 and thread 4 execute the synchronization code corresponding to obj2@ H_ 404_ 1@

When T1 starts to execute wait (), it will enter the sleep state, but it is not a general sleep, but sleep in a thread pool identified by obj1 (actually the thread pool corresponding to the monitor, but the monitor and lock are bound together at this time). When T2 starts executing, it finds that the lock obj1 is held by other threads, and it will enter the sleep state. This sleep is due to the lock resource waiting rather than the sleep entered by wait (). Because T2 has determined that it wants to apply for the obj1 lock, it will also sleep in the obj1 thread pool instead of ordinary sleep. Similarly, T3 and T4, these two threads will enter the obj2 thread pool to sleep@ H_ 404_ 1@

When a thread executes notify (), the notify () will randomly wake up any thread in the thread pool corresponding to its lock. For example, obj1 Notify () will wake up any sleeping thread in the obj1 thread pool (of course, if there is no sleeping thread, nothing will be done). Similarly, notifyall() wakes up all sleeping threads in the thread pool corresponding to the lock@ H_ 404_ 1@

The "corresponding lock" must be clarified, because the lock must be explicitly specified when calling wait(), notify(), and notifyall(). For example, obj1 wait()。 If the lock is omitted, it means this object, that is, the prefixes of these three methods can be omitted only in non static synchronization functions@ H_ 404_ 1@

In short, when synchronization is used, the lock is used, and the thread has ownership. All its bases are determined by the lock. For example, during thread synchronization, judge whether the lock is idle to determine whether to execute the following code, and whether to sleep in a specific thread pool. When waking up, only the threads in the thread pool corresponding to the lock will be awakened@ H_ 404_ 1@

In the application of these methods, generally in a task, wait() and notify() / notifyall() appear in pairs and execute one of them. In other words, during this round of atomic synchronization, either wait() to sleep or notify() to wake up the sleep threads in the thread pool. To realize alternative execution, you can consider using marking as the judgment basis. Refer to the examples below@ H_ 404_ 1@

2. Lock and Condition@H_404_1 @

The three methods in the wait () series have great limitations because both sleep and wake-up actions are completely coupled with locks. For example, the thread associated with lock obj1 can only wake up the thread in obj1 thread pool, but cannot wake up the thread associated with lock obj2; For another example, in the original synchronized synchronization, the lock is automatically acquired implicitly at the beginning of synchronization, and the lock is automatically released implicitly after the execution of a whole task, that is, the actions of acquiring and releasing the lock are not controlled by the legal person@ H_ 404_ 1@

Starting with JDK 1.5, Java provides Java util. concurrent. Locks package, which provides lock interface, condition interface and readwritelock interface. The first two interfaces decouple lock from monitor methods (sleep and wake-up operations). The lock interface only provides locks. One or more monitors associated with the lock can be generated through the lock method newcondition(). Each monitor has its own sleep and wake-up methods. That is, lock replaces the synchronized method and synchronized code block, and condition replaces the object monitor method@ H_ 404_ 1@

As shown below: @ h_ 404_ 1@

@H_ 404_ 1@@H_ 404_ 1@

When a thread executes condition1 When await(), the thread will sleep in the thread pool corresponding to the condition1 monitor. When condition1.0 is executed When signal(), any thread in condition1 thread pool will be waked up randomly. When condition1.0 is executed Signalall() wakes up all threads in the condition1 thread pool. Similarly, the same is true for the condition2 monitor@ H_ 404_ 1@

Even if there are multiple monitors, they can operate on each other's threads across monitors as long as they are associated with the same lock object. For example, the thread in condition 1 can execute condition 2 Signal() to wake up a thread in the condition2 thread pool@ H_ 404_ 1@

To use this lock and monitor association method, refer to the following steps: @ h_ 404_ 1@

For specific usage, see the following sample codes on lock and condition@ H_ 404_ 1@

3. Single producer and single consumer mode @ h_ 404_ 1@

A producer thread and a consumer thread. Every time a producer produces a bread and puts it on the plate, the consumer takes out the bread from the plate for consumption. Among them, the producer judges whether to continue production based on the absence of bread on the plate, while the consumer judges whether to consume based on the presence of bread on the plate. In this mode, only one bread is placed on the plate, so the plate can be omitted, and the producers and consumers can hand in the bread directly@ H_ 404_ 1@

First of all, we need to describe these three classes: resources operated by multithreading (bread here), producers and consumers. In the following example, I encapsulated the methods of producing bread and consuming bread into producer and consumer classes respectively. It is easier to understand if they are encapsulated in bread classes@ H_ 404_ 1@

The final result of implementation should be one for production and one for consumption. As follows: @ h_ 404_ 1@

4. Use lock and condition to realize single production and single consumption mode @ h_ 404_ 1@

The code is as follows: @ h_ 404_ 1@

5. Multi production and multi consumption mode (single bread) @ h_ 404_ 1@

Here we first explain the mode of multiple producers and multiple consumers, but there can only be one bread at a time. This mode may not be ideal in practice. However, in order to lead to the real mode of multiple production and multiple consumption, I think it is necessary to explain this mode here and analyze how this mode evolved from the code of single production and single consumption@ H_ 404_ 1@

As shown below: @ h_ 404_ 1@

@H_ 404_ 1@@H_ 404_ 1@

From single production and single consumption to multi production and multi consumption, there are two aspects to consider because of multi thread security and Deadlock: @ h_ 404_ 1@

For one party, how can multithreading achieve the same production or consumption capacity as single thread? That is, how to make multithreading look like a single thread. The biggest difference between multithreading and single thread is multithreading safety. Therefore, as long as the tasks executed by multithreading can be synchronized@ H_ 404_ 1@

The first problem considers the multithreading of one party, and the second problem considers how the two parties can cooperate harmoniously to complete production and consumption. That is, how to ensure that one side of the producer and consumer activities while the other side sleeps. Just wake up the other party when one party completes the synchronization task@ H_ 404_ 1@

In fact, from single thread to multi thread, there are two issues to consider: out of synchronization and deadlock. (1) When multithreading occurs in both the producer and the consumer, the multithreading of the producer can be regarded as a whole, and the multithreading of the consumer can also be regarded as a whole, which solves the problem of thread safety. (2) Then combine the producer and consumer as a whole as multi threads to solve the deadlock problem, and the way to solve the deadlock in Java is to wake up the other party or wake up all@ H_ 404_ 1@

The problem is how to ensure synchronization between multithreads on one side? Take multithreading executing single consumer code as an example@ H_ 404_ 1@

Suppose consumer thread 1 wakes up consumer thread 2 after consuming a bread and continues the cycle. Judge if (! Flag), it will wait, and the lock is released. Assuming that the CPU just selects consumption thread 2, consumption thread 2 will also enter the wait. After the producer produces a bread, suppose it wakes up the consumption thread 1, which will continue to consume the newly produced bread from the wait statement. Suppose it wakes up the consumption thread 2 again. When the consumption thread 2 is selected by the CPU, the consumption thread 2 will also consume the bread from the wait statement. The problem arises again, Continuously awakened consumption threads 1 and 2 consume the same bread, that is, the bread is consumed repeatedly. This is a multi-threaded asynchronous problem again@ H_ 404_ 1@

After talking about a large section, in fact, the analysis is very simple after zooming in. As long as two or more threads on one side wait because they judge b.flag, the two or more threads may be continuously awakened and continue to produce or consume downward. This results in asynchronous multithreading@ H_ 404_ 1@

The unsafe problem is that multiple threads on the same side continue to produce or consume downward after continuous wake-up. This is caused by the if statement. If the wait thread can go back to judge whether the b.flag is true after waking up, it can decide whether to continue to wait or produce or consume downward@ H_ 404_ 1@

You can replace the if statement with the while statement to meet the requirements. In this way, whether multiple threads on one side are continuously awakened or not, they will go back to judge b.flag@ H_ 404_ 1@

The first multithreading safety problem is solved, but there will be deadlock. This is easy to analyze. The producer and the consumer are regarded as a whole. When the producer's threads are all waiting (when the producer's threads are continuously awakened, all the threads of the producer will be waiting), and the consumer will also be waiting, the deadlock will appear. In fact, when you zoom in, the producer and consumer are regarded as one thread respectively. These two threads form multiple threads. When one party fails to wake up the other after waiting, the other party will certainly wait, so it will deadlock@ H_ 404_ 1@

The deadlock of both parties can be solved as long as it can wake up the other party instead of our party continuously. Use notifyall() or signalall(), or wake up the other thread through signal(). See the second code below@ H_ 404_ 1@

According to the above analysis, by improving the code of single production and single consumption mode, it can be changed into multi production and multi consumption single bread mode@ H_ 404_ 1@

The following is the code reconstructed with lock and condition, using the method of signal () to wake up the other thread@ H_ 404_ 1@

Make a summary on the problem of more production and more consumption: @ h_ 404_ 1@

(1). The solution to the asynchronous multithreading of one party is to use while (flag) to judge whether to wait@ H_ 404_ 1@

(2). The solution to the deadlock problem is to wake up the other party. You can use notifyall(), signalall() or the signal() method of the other party's monitor@ H_ 404_ 1@

6. Multi production and multi consumption mode @ h_ 404_ 1@

There are multiple producer threads and multiple consumer threads. The producer puts the produced bread into the basket (set or array), and the consumer takes out the bread from the basket. Producers judge whether the basket is full and consumers judge whether the basket is empty. In addition, when the consumer takes out the bread, the corresponding position is empty again, and the producer can go back and continue production from the starting position of the basket, which can be realized by resetting the pointer of the basket@ H_ 404_ 1@

In this model, in addition to describing producers, consumers and bread, we also need to describe the container of basket. Suppose an array is used as a container, the production pointer shifts backward for each producer, and the consumption pointer shifts backward for each consumer@ H_ 404_ 1@

The code is as follows: refer to the sample code @ h given in API -- > condition class_ 404_ 1@

This involves consumers, producers, bread and baskets. Bread and baskets are resources operated by multiple threads. The producer thread produces bread and puts it into the basket, and the consumer thread takes out bread from the basket. The ideal code is to encapsulate the production task and consumption task in the resource class. Because bread is an element of the basket container, it is not suitable to be encapsulated in the bread class, and encapsulated in the basket, which can operate the container more conveniently@ H_ 404_ 1@

Note that all the code involving resource operation must be put into the lock, otherwise multi-threaded synchronization will occur. For example, in the producer class, the method produce () for producing bread is defined, and then it is used as the method basket The parameter of in(), i.e. basket In (producer ()), which is the wrong behavior, because produce () is passed to the in () method after it is executed outside the lock@ H_ 404_ 1@

The above article based on Java producer consumer model (detailed analysis) is all the content shared by Xiaobian. I hope it can give you a reference and support more programming tips@ H_ 404_ 1@