Detailed Java program concurrency wait-notify mechanism _java

Wait-notify scene
Typical wait-notify scenarios are generally related to the following two elements:
1. Status variable (state Variable)
when a thread needs to wait, it is always due to some condition that is not satisfied. For example, to populate the queue with data, and when the queue element is full, the thread needs wait to stop running. When the queue element is vacant, continue with its execution.
2. Conditional assertion (Condition predicate)
When a thread determines whether to enter a wait or whether it is going to go down when it wakes from notify, most of the test status conditions are satisfied. For example, adding elements to the queue, the queue is full, blocking the current thread, and when other threads take the element out of the queue, they are notified that the waiting thread "queue has space left to add elements to." At this point, the process of waiting for the element to be added wakes up, then determines whether the current queue really has the remaining space, adds the element if there is any space left, and if not, continues to block for the next wake-up call.
3. Conditional queues (Condition queue)
Each object has a built-in conditional queue, and when a thread calls the wait function on the lock of the object, it joins the thread into the object's conditional queue.

Attention
wait and notify are important components of the Java synchronization mechanism. Combined with the use of the Synchronized keyword, many excellent synchronization models, such as producer-consumer models, can be built. However, when using the Wait (), notify (), Notifyall () function, special attention should be paid to the following points:

The Wait (), notify (), Notifyall () method is not part of the thread class, but belongs to the object base class, which means that each object has the function of Wait (), notify (), Notifyall (). Because each object has a lock, the lock is the basis of each object, so the method of manipulating the lock is also the most basic.
You must obtain the obj lock, which must be written in the synchronized (obj) {...} code snippet, before you call obj's Wait (), notify () method.
After the call to Obj.wait (), thread a releases the lock on obj, otherwise thread B cannot get the obj lock and cannot wake thread A in the synchronized (obj) {...} code snippet.
When the Obj.wait () method returns, thread a needs to acquire the OBJ lock again in order to continue execution.
If the thread a1,a2,a3 is obj.wait (), then thread B calls Obj.notify () to wake only one of the threads a1,a2,a3 (which is determined by the JVM).
If thread B calls Obj.notifyall (), it wakes up all the waiting threads a1,a2,a3, but the waiting thread continues to execute the next statement of Obj.wait () and must obtain an obj lock. As a result, thread a1,a2,a3 has only one chance to get the lock to continue execution, such as A1, and the rest will need to wait for A1 to release the obj lock before proceeding.
When thread B calls obj.notify () or Obj.notifyall (), thread B is holding the obj lock, so thread a1,a2,a3 is awakened, but the obj lock is still not available. Until thread B exits the synchronized code block, after releasing the obj lock, one of the thread a1,a2,a3 has the opportunity to acquire the object lock and continue execution.

Sample Code
The typical code structure for a thread's wait operation is as follows:

  public void Test () throws Interruptedexception { 
    synchronized (obj) {while 
      (! contidition) { 
        obj.wait (); 
      } 
    } 
  } 

Why does the obj.wait () operation have to be in a loop? There are several main reasons for this:
1. An object lock may be used to protect multiple state variables, and when they all require a wait-notify operation, there is a problem if you do not place wait in the while loop. For example, an object lock obj protects two state variables A and B, a wait operation occurs when a's condition assertion is not established, and a wait operation occurs when the condition assertion of B is not immediately, and two threads are added to the corresponding conditional queue of obj. Now if you change the action of a state variable a, when obj is raised with the notifyall operation, all threads in the conditional queue for obj are awakened, before one or several threads of a are waiting to determine if a's conditional assertion may be set up, but B's assertion of the condition is certainly not tenable, The thread waiting for B is also awakened, so it is necessary to loop through the condition assertion that B is satisfied, and if not, continue with wait.
2. The condition assertion of the same state of multiple threads wait. For example, to add an element to a queue, the current queue is full, and multiple threads want to add elements to it, so they wait. At this point, another thread takes an element out of the queue, invokes the Notifyall operation, wakes all threads, but only one thread can add an element to the queue, and others still need to wait.
3. False awakening. The thread automatically wakes up without being notified, interrupted, or timed out. Although this situation rarely happens in practice, it can be prevented by circular waiting.