[thread] thread state of java

Posted by Rairay on Sun, 19 Dec 2021 07:27:19 +0100

public enum State {
        /**
         * Thread state for a thread which has not yet started.
         */
        NEW,

        /**
         * Thread state for a runnable thread.  A thread in the runnable
         * state is executing in the Java virtual machine but it may
         * be waiting for other resources from the operating system
         * such as processor.
         */
        RUNNABLE,

        /**
         * Thread state for a thread blocked waiting for a monitor lock.
         * A thread in the blocked state is waiting for a monitor lock
         * to enter a synchronized block/method or
         * reenter a synchronized block/method after calling
         * {@link Object#wait() Object.wait}.
         */
        BLOCKED,

        /**
         * Thread state for a waiting thread.
         * A thread is in the waiting state due to calling one of the
         * following methods:
         * <ul>
         *   <li>{@link Object#wait() Object.wait} with no timeout</li>
         *   <li>{@link #join() Thread.join} with no timeout</li>
         *   <li>{@link LockSupport#park() LockSupport.park}</li>
         * </ul>
         *
         * <p>A thread in the waiting state is waiting for another thread to
         * perform a particular action.
         *
         * For example, a thread that has called <tt>Object.wait()</tt>
         * on an object is waiting for another thread to call
         * <tt>Object.notify()</tt> or <tt>Object.notifyAll()</tt> on
         * that object. A thread that has called <tt>Thread.join()</tt>
         * is waiting for a specified thread to terminate.
         */
        WAITING,

        /**
         * Thread state for a waiting thread with a specified waiting time.
         * A thread is in the timed waiting state due to calling one of
         * the following methods with a specified positive waiting time:
         * <ul>
         *   <li>{@link #sleep Thread.sleep}</li>
         *   <li>{@link Object#wait(long) Object.wait} with timeout</li>
         *   <li>{@link #join(long) Thread.join} with timeout</li>
         *   <li>{@link LockSupport#parkNanos LockSupport.parkNanos}</li>
         *   <li>{@link LockSupport#parkUntil LockSupport.parkUntil}</li>
         * </ul>
         */
        TIMED_WAITING,

        /**
         * Thread state for a terminated thread.
         * The thread has completed execution.
         */
        TERMINATED;
    }

Thread status?

This is the state in the source code of Thread class, or the state of Thread in java

NEW: thread instance has been constructed, but it has not start ed yet

RUNNABLE: running or waiting to be executed by cpu

BLOCKED: the thread calls the synchronized keyword and waits to acquire the monitor lock

WAITING: the thread called wait, join and park methods without timeout

TIMED_WAITING 

TERMINATED (English Interpretation: stop, end, terminate)

This is equivalent to the thread state of the operating system. There are six java thread states: new, running, blocking, infinite waiting, deadline waiting and end.

Among them, the running status is generally called runnable because it only counts as running when the CPU time slice is allocated

Because many materials on the Internet say that threads are like this: in fact, the state division of processes is like this: five states

What is a thread's park?

When using JAVA for multi-channel programming, in addition to blocking / waking up threads through wait/notify, we can also use LockSupport tool class to block and wake up threads.

Results:

thread start!
 from main thread
thread weakup!

Equivalent to blocking and waking up threads

park/unpark does not have the upper layer judgment logic based on object lock. It is more directly used to operate threads through system calls. Of course, some small packages are made on system calls. Compared with wait/notify:

  1. park does not need to acquire the lock of an object
  2. Because park will not throw InterruptedException exception during interrupt, you need to judge the interrupt state after Park and then do additional processing. Just like sleep, after notify wakes up, the jvm will help us check whether there is an interrupt signal. Put the logic of checking the interrupt signal after the logic of blocking the thread. Once it is awakened, first execute the logic of checking the interrupt signal. After checking, exit the sleep/wait method, and the program continues to execute downward. park / unpark does not provide a similar mechanism. If necessary, we should add logic to check the interrupt signal after the park method.
  3. Think of a rule in the happy before principle that the unlock operation of the same lock is happy before the lock operation of this lock. park/unpark does not involve lock operation, but we do have the requirement to ensure that in a pair of operations, park occurs before unpark, otherwise it may cause program deadlock. In this regard, park/unpark meets our requirements by attaching status bits to the thread: when unpark is called, if the current thread has not entered the park, the permission is set to true; When park is called, judge whether the permission is true. If true, park will not block the thread and the program will continue to execute; If false, the thread is blocked. Therefore, as long as our park/unpark appear in pairs, no matter the execution order, it will not cause deadlock

Transferred from: https://www.cnblogs.com/niuyourou/p/12715775.html

Well written

Join and Yield

Join is a member method of Thread class. This method is used to wait for the current Thread to finish before continuing to execute subsequent code.

Yield is a static method of Thread class. This method is used to make the current Thread abandon the cpu and wait for the cpu to reschedule (the current Thread may get the cpu again). The popular point is to give other threads a chance to return to the same running line. As for who is selected by the cpu, it depends on personal luck.

Reference article:

https://www.jianshu.com/p/6aff628d05fb

 https://www.cnblogs.com/niuyourou/p/12715775.html

Topics: Multithreading