Shulou(Shulou.com)06/03 Report--

This article mainly talks about "what's the difference between BLOCKED and WAITING". Interested friends might as well take a look. The method introduced in this paper is simple, fast and practical. Now let the editor take you to learn "what's the difference between BLOCKED and WAITING?"

The difference between BLOCKED and WAITING

As a result, both BLOCKED and WAITING states are thread pauses and will not consume CPU resources, but there are still some differences.

BLOCKED

The thread state of the blocking thread waiting for the Monitor lock, the thread in the blocking state is waiting for the Monitor lock to enter the synchronized Block or Method, or to re-enter the synchronous block / method after calling Object.wait. Simply put, it is the state of a thread waiting for a lock in the form of an synchronized

In the following code, T1 is waiting for the lock release of T0 (the execution of the synchronized block is complete), so the state of T1 is BLOCKED

Object lock = new Object (); Thread t0 = new Thread (new Runnable () {@ Override public void run () {synchronized (lock) {System.out.println ("t0 acquire lock success"); try {Thread.sleep (10000);} catch (InterruptedException e) {e.printStackTrace () }); t0.start (); Thread.sleep; Thread T1 = new Thread (new Runnable () {@ Override public void run () {synchronized (lock) {System.out.println ("T1 acquire lock success");}); t1.start (); Thread.sleep System.out.println ("t0 state:" + t0.getState ()); System.out.println ("T1 state:" + t1.getState ()); System.out.println ("done."); / / output t0 acquire lock success t0 state: TIMED_WAITING T1 state: BLOCKED done. T1 acquire lock success

WAITING

The state of the thread while waiting, the calls to the following methods cause the thread to enter the WAITING state:

Object.wait ()

Thread.join ()

LockSupport.park ()

A thread in the WAITING state is waiting for another thread to perform something, such as a thread calling Object.wait () on an object waiting for another thread to call Object.notify () or Object.notifyAll () on that object. The thread for Thread.join () is waiting for the specified thread to stop.

In the following code, t0 performs a wait operation after acquiring the lock of the lock object through synchronized, causing t0 to enter the WAITING state:

Object lock = new Object (); Thread t0 = new Thread (new Runnable () {@ Override public void run () {synchronized (lock) {System.out.println ("t0 acquire lock success"); try {lock.wait ();} catch (InterruptedException e) {e.printStackTrace () ); t0.start (); Thread.sleep (100); System.out.println ("t0 state:" + t0.getState ()); System.out.println ("done."); / / output t0 acquire lock success t0 state: WAITING done.

Difference

In addition to the lock of synchronized Block/Method, JAVA also provides the lock implementation under JUC, and the lock function under juc.lock is more powerful. For example, interrupt, reentrant / non-reentrant, fair / unfair, etc., but the lock under juc is not the same as the implementation of synchronized.

For example, the following code is also waiting for a lock, but it is not the same as the state of waiting for a lock in synchronized:

ReentrantLock reentrantLock = new ReentrantLock (); Thread t0 = new Thread (new Runnable () {@ Override public void run () {reentrantLock.lock (); System.out.println ("t0 acquire lock success"); try {Thread.sleep (10000);} catch (InterruptedException e) {e.printStackTrace ();}); t0.start () Thread.sleep; Thread T1 = new Thread (new Runnable () {@ Override public void run () {reentrantLock.lock (); System.out.println ("T1 acquire lock success");}}); t1.start (); Thread.sleep (100); System.out.println ("t0 state:" + t0.getState ()); System.out.println ("T1 state:" + t1.getState ()); System.out.println ("done.") / / output t0 acquire lock success t0 state: TIMED_WAITING t1 state: WAITING done.

The thread state is different under the lock implementation of JUC, so when observing the thread state, not only the state of BLOCKED is the waiting lock, but the state of WAITING/TIMEWAITING may still be the state of waiting lock.

However, for the lock implementation under JUC, the core method of pausing / waiting for threads is still LockSupport.park. Jstack will mark the WAITING in the form of PARKING, so it can still be seen at a glance when threads stack:

/ / the waiting type "Thread-0" # 11 prio=5 os_prio=31 tid=0x00007f9308110000 nid=0x5c03 waiting on condition [0x0000700007fc3000] java.lang.Thread.State: WAITING (parking) / / although it is WAITING, it is marked with at sun.misc.Unsafe.park (Native Method) of type parking.

On the other hand, the output of synchronized locks under jstack will be different:

/ / the wait type is monitor "Thread-1" # 12 prio=5 os_prio=31 tid=0x00007f833d919800 nid=0x5a03 waiting for monitor entry [0x00007000035af000] java.lang.Thread.State: BLOCKED (on object monitor) / / this is the BLOCKED status, and the ownership of the monitor is also shown.

Therefore, when observing the thread state, you need to pay attention to the difference between the WAITING caused by Object.wait () and the WAITING caused by juc locking.

Is RUNNABLE really RUNNABLE?

Here is an example of a jstack output that is now executing the socketRead0 method (Native) and is in a RUNNABLE state

RMI TCP Connection (2)-192.xxx.xx.xx "daemon prio=6 tid=0x000000000a3e8800 nid=0x158e50 runnable [0x000000000adbe000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0 (Native Method) at java.net.SocketInputStream.read (Unknown Source) at java.net.SocketInputStream.read (Unknown Source) at java.io.BufferedInputStream.fill (Unknown Source) at java.io.BufferedInputStream.read (Unknown Source)-locked (0x00000007ad784010) (a java.io.BufferedInputStream) at java.io.FilterInputStream.read (Unknown Source) At sun.rmi.transport.tcp.TCPTransport.handleMessages (Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0 (Unknown Source) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run (Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker (Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run (Unknown Source) at java.lang.Thread.run (Unknown Source) author: empty link: https://juejin.cn/post/6951187747189194782 source: Nuggets copyright belongs to the author. Commercial reprint please contact the author for authorization, non-commercial reprint please indicate the source.

But in fact, the RUNNABLE here is only the thread state at the JAVA level, and from the operating system or process point of view, the thread is still the state of WAITING. SocketInputStream is an implementation of BIO, which blocks when no data is received (or is not ready for readable data). But this blocking is the state of RUNNABLE in the JAVA thread state, but it does not occupy the CPU time slice of the user mode. The kernel will end the blocking after receiving the data.

At this point, I believe you have a deeper understanding of "what's the difference between BLOCKED and WAITING". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.