Multithreading summary Two: state transitions of threads

Transferred from: http://zy19982004.iteye.com/blog/1626916

I. State diagram of a thread

Two. Initial state

1. Implement runnable interface and inherit thread can get a thread class, new one instance comes out, the thread enters the initial state

Three. Operational status

1. The operational state only says you are qualified to run, and the scheduler does not pick you up and you will always be operational.
2. Invokes the thread's start () method, which enters the operational state.
3. At the end of the current thread sleep () method, the other thread joins () ends, waits for the user to enter, a thread gets the object lock, and the threads enter the operational state.
4. The current thread has run out of time slices, invoking the yield () method of the current thread, and the current thread enters the operational state.
5. The thread in the lock pool gets to the object lock and enters the operational state.

Four. Operational status

1. The state that the thread scheduler is in when it selects a thread from a running pool as the current thread. This is also the only way that a thread goes into a running state.

Five. Death status

1. When the thread's run () method is complete, or the main thread of the main () method finishes, we think it dies. This thread object may be alive, but it is not a separate thread. Once a thread dies, it cannot be resurrected.
2. Calling the start () method on a dead thread throws a Java.lang.IllegalThreadStateException exception.

Six. Blocking status

1. The current thread T calls the Thread.Sleep () method, and the current thread goes into a blocking state.
2. Other threads running on the current line thread T2 call the Join () method, and the current thread goes into a blocking state.
3. The current thread enters a blocking state while waiting for the user to enter it.

Seven. Wait queue (This is the method in object, but the thread is affected)

1. Before calling the Wait (), notify () method of obj, you must obtain the obj lock, which must be written within the synchronized (obj) code snippet.
2. Steps and diagrams related to the wait queue

• Thread 1 Gets the lock of object A and is using object A.
• Thread 1 calls the Wait () method of object A.
• Thread 1 Releases the lock on object A and immediately enters the waiting queue.
• Objects inside the lock pool scramble for the lock of object A.
• Thread 5 obtains the lock of object A, enters the synchronized block, and uses object A.
• Thread 5 calls the Notifyall () method of object A, wakes all threads, and all threads enter the lock pool. | | | | | Thread 5 calls the Notify () method of object A, wakes up a thread, does not know who will wake up, and the thread that is awakened enters the lock pool.
• The Notifyall () method ends with the synchronized, and thread 5 releases the lock for object A.
• The threads inside the lock pool scramble for object locks, but when thread 1 is able to grab it, it doesn't know. | | | | | The locked pool + 6th step is awakened by a thread that competes for the object lock.

Eight. Lock Pool Status

1. When the current thread wants to invoke the synchronization method of object A, it discovers that the lock of object A is occupied by another thread, at which point the current thread enters the lock pool state. In short, the lock pool is filled with threads that want to compete for object locks.
2. When a thread 1 is awakened by another thread 2, the 1 thread enters the lock pool state to scramble for the object lock.
3. A lock pool is a concept that is in a synchronized environment, with one object corresponding to a lock pool.

Nine. Comparison of several methods

1. Thread.Sleep (Long Millis), it must be that the current thread calls this method, the current thread enters the block, but does not release the object lock, Millis after the thread automatically wakes into the operational state. Role: The best way to execute opportunities for other threads.
2. Thread.yield (), must be the current thread calls this method, the current thread discards the acquired CPU time slice, the running state becomes operational state, let the OS select the thread again. Role: Threads with the same priority are rotated, but not guaranteed to be executed in turn. There is no guarantee that yield () will achieve a concession, because a given thread may also be checked again by the thread scheduler. Thread.yield () does not cause blocking.
3. T.join ()/t.join (long Millis), the current thread calls the join method of another thread 1, the current thread is blocked, but the object lock is not freed until thread 1 is executed or millis time is up, and the current thread enters the operational state.
4. Obj.wait (), the current thread calls the object's Wait () method, the current thread frees the object lock, and enters the wait queue. relies on notify ()/notifyall () wake-up or wait (long timeout) timeout time to auto-wake.
5. Obj.notify () wakes up a single thread waiting on this object monitor, and the selection is arbitrary. Notifyall () wakes up all the threads waiting on this object monitor.

10. Two questions

1. When an object lock is released by a thread, which of the threads inside the lock pool can get the lock? Random? Queue FIFO? or sth else?
2. Waiting for many threads in the queue to wait () on an object, at which point the Notify () method of the object is called, and which thread is awakened? Random? Queue FIFO? or sth else? The Java document simply writes: The choice is arbitrary.

Multithreading summary Two: state transitions of threads