BLOCKED和WAITING的区别
BLOCKED和WAITING两种状态从后果上来看,都是线程暂停,不会占用CPU资源,不过还是有一些区别的
BLOCKED
期待Monitor锁的阻塞线程的线程状态,处于阻塞状态的线程正在期待Monitor锁进入synchronized Block或者Method,或者在调用Object.wait后从新进入同步块/办法。简略的说,就是线程期待synchronized模式的锁时的状态
上面这段代码中,t1在期待t0的锁开释(synchronized代码块执行实现),那么此时t1的状态就是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(100);Thread t1 = new Thread(new Runnable() { @Override public void run() { synchronized (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.");//outputt0 acquire lock successt0 state: TIMED_WAITINGt1 state: BLOCKEDdone.t1 acquire lock success
WAITING
期待中的线程状态,上面几个办法的调用会导致线程进入WAITING状态:
- Object.wait()
- Thread.join()
- LockSupport.park()
WAITING状态中的线程在期待其余线程执行某些操作,比方在某个对象上调用Object.wait()的线程正在期待另一个线程在该对象上调用Object.notify()或Object.notifyAll()。为Thread.join()的线程正在期待指定的线程进行。
上面这段代码中,t0在通过synchronized获取了lock对象的锁之后,进行了wait操作,导致t0进入WAITING状态:
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.");//outputt0 acquire lock successt0 state: WAITINGdone.
区别
JAVA中除了synchronized Block/Method的锁,还提供了JUC下的锁实现,juc.lock下的锁性能更弱小。比方反对中断,反对重入/非重入,偏心/非偏心等;然而juc下的锁和synchronized的实现可是不太一样的
比方上面这段代码,同样是期待锁,可是和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(100);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.");//outputt0 acquire lock successt0 state: TIMED_WAITINGt1 state: WAITINGdone.
同样是加锁,在JUC的锁实现下线程状态不太一样,所以在察看线程状态时,不止是BLOCKED的状态才是期待锁,WAITING/TIMEWAITING的状态依然可能是期待锁的状态
不过JUC下的锁实现,让线程暂停/期待的外围办法还是LockSupport.park,jstack
对于PARKING模式的WAITING会有标注,所以在线程stack时还是能一眼看进去的:
//这里显示了期待类型"Thread-0" #11 prio=5 os_prio=31 tid=0x00007f9308110000 nid=0x5c03 waiting on condition [0x0000700007fc3000] java.lang.Thread.State: WAITING (parking)//这里尽管是WAITING,但还是标注了是parking类型的 at sun.misc.Unsafe.park(Native Method)
而synchronized模式的锁在jstack
下的输入会有所区别:
//这里显示了期待类型为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)//这里是BLOCKED状态,同时显示了monitor的归属
所以在察看线程状态时,须要留神Object.wait()这种WAITING和juc下锁导致的WAITING的区别
RUNNABLE真的是RUNNABLE吗?
上面是一段jstack
输入的例子,该线程当初正在执行socketRead0办法(Native),并且是RUNNABLE状态
"RMI TCP Connection(2)-192.xxx.xx.xx" daemon prio=6 tid=0x000000000a3e8800 nid=0x158e50 runnable [0x000000000adbe000]java.lang.Thread.State: RUNNABLEat 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)
但其实这里的RUNNABLE只是JAVA层面的线程状态,在操作系统或过程角度来看,该线程还是WAITING的状态;SocketInputStream是一个BIO的实现,当没有收到数据(或者说没有筹备好可读的数据)时会产生阻塞,可这个阻塞在JAVA线程状态里是RUNNABLE的状态,不过他并不会占用用户态的CPU工夫片,内核在承受到数据后会完结这个阻塞
参考
- https://blog.fastthread.io/2018/09/02/threads-stuck-in-java-net-socketinputstream-socketread0/