Differences between Java multithreading suspend (), resume (), wait (), and consumer y ()

Suspend () and resume () Methods: these two methods are used together. Suspend () causes the thread to enter the blocking state and will not be automatically restored. The corresponding resume () must be called, in order to re-enter the executable state of the thread. Typically, suspend () and resume () are used to wait for the results produced by another thread: after the test finds that the results have not yet been produced, the thread is blocked. After the results are produced by another thread, call resume () to restore it. However, the suspend () method can easily cause deadlocks and is no longer recommended. Wait () and notify () Methods: two methods are used together. Wait () causes the thread to enter the blocking state. It has two forms, one allows you to specify a period of time in milliseconds as the parameter, and the other does not have a parameter. The former is used as the corresponding notify () when it is called or exceeds the specified time, the thread re-enters the executable state, and the latter must be called with the corresponding notify. It seems that they have no difference with the suspend () and resume () methods, but they are actually completely different. The core difference is that all the methods described above will not release the occupied lock (if occupied) when blocking, and this method is the opposite.

The above core differences lead to a series of detailed differences.

First, all the methods described above belong to the Thread class, but this pair is directly affiliated to the object class, that is, all objects have this pair of methods. It seems incredible at the beginning, but it is actually quite natural, because this pair of methods will release the occupied lock when blocking, and the lock is owned by any object, the wait () method of any object is called to cause thread blocking and the lock on the object is released. However, calling the notify () method of any object causes the wait () method of the object to be called () method ).

Secondly, all the methods described above can be called anywhere, but this pair of methods must be called in the synchronized method or block for a very simple reason, the lock can be released only when the current thread occupies the lock in the synchronized method or block. In the same way, the lock on the object that calls this method must be owned by the current thread so that the lock can be released. Therefore, this pair of method calls must be placed in such a synchronized method or block. The lock object of this method or block is the object that calls this pair of methods. If this condition is not met Program Even though it can still be compiled, the illegalmonitorstateexception will occur during runtime.

The preceding features of the wait () and notify () methods determine that they are often used together with the synchronized method or block, by comparing them with the inter-process communication machine of the operating system, we will find their similarity: the synchronized method or block provides functions similar to the operating system primitive, their execution will not be affected by the multi-thread mechanism, and this pair of methods is equivalent to the block and wakeup primitives (both of which are declared as synchronized ). Their combination enables us to implement a series of exquisite inter-process communication on the Operating System Algorithm (Such as semaphore algorithm), and used to solve various complex inter-thread communication problems.

The wait () and notify () methods are described as follows:

First, the thread that calls the notify () method to remove blocking is randomly selected from the thread that is blocked by calling the wait () method of the object, we cannot predict which thread will be selected, so we should be very careful when programming to avoid problems caused by such uncertainty.

Second: In addition to notify (), there is also a method notifyall () that can also play a similar role. The only difference is that calling the notifyall () method will call the wait () and all the blocked threads are all blocked at one time. Of course, only the thread that gets the lock can enter the executable state.

When talking about blocking, we can't help but talk about deadlocks. A brief analysis shows that calls of the suspend () method and the wait () method without specifying the timeout period may lead to deadlocks. Unfortunately, Java We do not support deadlock avoidance at the language level. We must be careful to avoid deadlocks during programming.

WeJavaThe methods used to implement thread blocking are analyzed. We focus on the wait () and notify () methods, because they are the most powerful and flexible to use, however, this also results in low efficiency and error-prone errors. In actual use, we should use various methods flexibly to better achieve our goal.