suspend () and resume () methods: Two methods are used, suspend () causes the thread to enter a blocking state, and does not automatically recover, it must be called by its corresponding resume () to enable the thread to re-enter the executable state. Typically, suspend () and resume () are used when waiting for the result of another thread: After the test finds that the result has not yet been generated, the thread is blocked and the other thread produces the result, calling resume () to restore it. However, the suspend () method can easily cause deadlock problems and is deprecated. Wait () and Notify () methods: Two methods are used, wait () causes the thread to enter a blocking state, it has two forms, one allows to specify a period of time in milliseconds as a parameter, and the other has no parameters, the former when the corresponding notify () is called or exceeds the specified time When the thread re-enters the executable state, the latter must be called by the corresponding notify ().
At first glance they have nothing to do with the suspend () and the Resume () methods, but in fact they are quite different. The core of the difference is that all of the methods described earlier, blocking will not release the lock (if occupied), and this pair of methods is the opposite.
The core differences above lead to a series of differences in detail.
First, all the methods described earlier are subordinate to the Thread class, but the pair is directly subordinate to the object class, which means that all objects have this pair of methods. At first glance this is very magical, but in fact it is very natural, because this pair of methods when blocking to release the lock occupied, and the lock is any object has, call any object's wait () method causes the thread to block, and the lock on the object is freed. The Notify () method that invokes an arbitrary object causes a randomly selected unblocking in the thread that is blocked by calling the wait () method of the object (but is not really executable until the lock is acquired).
Second, all the methods described earlier can be called anywhere, but this pair of methods must be called in the Synchronized method or block, the reason is simple, only in the Synchronized method or block the current line friend occupy the lock, only the lock can be released. Similarly, locks on objects that call this pair of methods must be owned by the current thread, so that locks can be freed. Therefore, this pair of method calls must be placed in such a synchronized method or block where the locked object of the method or block is the object that invokes the pair of methods. If this condition is not met, the program can still compile, but the illegalmonitorstateexception exception will occur at run time.
The above characteristics of the wait () and notify () methods determine that they are often used in conjunction with synchronized methods or blocks to make them and the inter-process communication mechanism of the operating system A comparison will reveal their similarity: the Synchronized method or block provides functionality similar to the operating system primitives, whose execution is not disturbed by the multithreading mechanism, which is equivalent to the block and wakeup primitives (which are declared as Synchronized). Their combination allows us to implement an array of sophisticated inter-process communication algorithms (such as semaphore algorithms) on the operating system, and to solve a variety of complex inter-threading communication problems.
The Wait () and notify () methods are finally explained in two points:
First: Calling the Notify () method causes the unblocked thread to be randomly selected from the thread that was blocked by calling the wait () method of the object, and we cannot predict which thread will be selected, so be careful when programming, and avoid problems with this uncertainty.
Second: In addition to notify (), there is also a method Notifyall () can also play a similar role, the only difference is that the call to the Notifyall () method will be called by the Wait () method of the object is blocked all at once unblocked all the threads. Of course, only the thread that gets the lock can go into the executable state.
When it comes to blocking, it is impossible to talk about deadlocks, and a brief analysis reveals that the suspend () method and the call to the Wait () method, which does not specify a time-out period, can generate a deadlock. Unfortunately,
Java does not support deadlock avoidance at the language level, and we must be careful in programming to avoid deadlocks.
We have analyzed the various methods of threading blocking in
Java , and we have focused on the wait () and notify () methods, because they are the most powerful and flexible to use, but it also makes them less efficient and prone to error. In practice we should use various methods flexibly in order to achieve our goal better.
Java multithreading suspend (), resume () and wait (), notify () differences (reprint)
