Turn: Several state transitions for threads

Threads under certain conditions, the state will change. There are several states for a thread:

1. New state: A new Thread object was created.

2. Ready state (Runnable): After the thread object is created, other threads call the object's start () method. The thread in this state is in the " Running thread pool " and becomes operational, waiting only for the CPU to be used. that is, the process in the ready state except outside the CPU, all the resources required to run the operation are fully available.

3, running State (Running): The ready state of the thread gets the CPU, executes the program code.

4, blocking state (Blocked): blocking state is the thread for some reason to abandon the use of the CPU, temporarily stop running. Until the thread is in a ready state, the opportunity to go to the running state is reached.

There are three types of blocking:

(1), waiting for blocking : The running thread executes the wait () method, which frees all resources that are consumed, and the JVM puts the thread into the " waiting pool." After entering this state, it is not automatically awakened and must rely on other threads to invoke the Notify () or Notifyall () method to be awakened.

(2), synchronous blocking : When a running thread acquires a synchronization lock on an object, if the synchronization lock is occupied by another thread, the JVM puts the thread into the lock pool .

(3), Other blocking : The running thread executes the sleep () or join () method, or when an I/O request is made, the JVM will place the thread in a blocked state. When the sleep () state times out, join () waits for the thread to terminate or time out, or the I/O process finishes, the thread is re-entered in a ready state.

5. Dead State (Dead): The thread finishes executing or exits the run () method because of an exception, and the thread ends the life cycle.

The state transition diagram for thread changes is as follows:

Note: Get the lock tag of the object, that is, to get the object (critical SectionPermission to use. That is, the thread gets the resources it needs to run, enters the ready state, and can run with just the CPU. Becausewhen Wait () is called, the thread releases the "lock flag" that it occupies, so that the thread is only able to get the resources to enter the ready state.
Here's a little explanation:
1, the implementation of the thread has two ways, one is to inherit the thread class, the second is to implement the Runnable interface, but anyway, when we new this object, the thread entered the initial state;
2. When the object calls the start () method, it enters the ready state;
3, when it is ready, when the object is selected by the operating system, to obtain the CPU time slice will enter the running state;
4. After entering the operating state, the situation is more complicated.
4.1, the Run () method or the main () method ends, the thread will enter the terminating state;
4.2. When the thread calls its own sleep () method or another thread's join () method, the process yields the CPU and then goes into a blocking state (This state stops the current thread, but does not release the resources it occupiesthat is, after the sleep () function is called, the thread does not release its "lock Flag". ）。 When sleep () ends or join () ends, the thread enters the operational state and continues to wait for the OS to allocate CPU time slices.Typically,sleep () is used to wait for a resource to be ready:After the test discovery condition is not met, let the thread block for a period of time and re-test until the condition is satisfied.
4.3, the thread calls theyield ()method, which means to discard the current CPU time slice, return to the ready state, and other processes in the same competitive state, the OS may then let the process into the running State; the effect of invoking yield () is equivalent to the scheduler thinking that the thread has executed enough time slices to go to another thread. Yield () simply returns the current thread back to the executable state, so the thread executing yield () is likely to be executed immediately after entering the executable state.
4.4, when the thread has just entered the operational state (note, not yet running), found that the resource to be called is Synchroniza (synchronous), get no lock tag, will immediately enterLock Pool Status, wait for the lock token to be acquired (at this point the lock pool may already have other threads waiting to acquire the lock flag, when they are in the queue state, first-come-first- served), once the thread obtains the lock tag, it goes into a ready state, waiting for the OS to allocate CPU time slices;

4.5. suspend () and Resume () methods : Two methods are used, suspend () causes the thread to go into a blocking state and does not automatically recover, it must be called by its corresponding resume (). To allow 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.
4.6 , Wait (), and Notify () methods : When a thread calls the wait () method , it enters the waiting queue (which in this state frees up all the resources it occupies, unlike the blocking state ), and when it enters this state, is not automatically awakened, you must rely on other threads to invoke the Notify () or Notifyall () method to be awakened (because notify () just wakes up a thread, but we are not sure which thread is specifically awakened, perhaps the thread we need to wake up to cannot be awakened, Therefore, in the actual use, usually use the Notifyall () method, wake up some threads), the thread will be awakened into the lock pool, waiting for the lock token.

Wait () causes the thread to enter a blocking state, which has two forms:

One allows you to specify a period of time in milliseconds as a parameter, and the other without parameters. The former when the corresponding notify () is called or exceeds the specified time, the thread re-enters the executable state is ready state , the latter must be the corresponding notify () is called. when Wait () is called, the thread releases the "lock flag" that it occupies, making other synchronized data in the object that the thread resides in can be used by other threads . Waite () and notify () because they operate on the object's lock flags, they must be called in the synchronized function or Synchronizedblock. If the call is made in the non-synchronized function or Non-synchronizedblock, the illegalmonitorstateexception exception will occur at run time, although it can be compiled.

Note the difference: at first glance, the Wait () and notify () methods 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 the suspend () and all other methods described above do not release the locks that are occupied (if they are occupied), while the two methods of Wait () and notify () are 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 Wait () and notify () methods are directly subordinate to the object class , that is , 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 at any location, but the Wait () and notify () methods must be called in the Synchronized method or block, and the reason is simple. A lock can be released only if the current line friend occupies a lock in the Synchronized method or block. 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 with synchronized methods or blocks. A comparison between them and the operating system's interprocess communication mechanism reveals their similarity: the Synchronized method or block provides functionality similar to the operating system primitives, and their execution is not interfered by the multithreading mechanism, which is equivalent to block and wake up Primitives (this pair of methods 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.

Turn: Several state transitions for threads