JAVA 线程状态中可能存在的一些误区

空无

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.");

//output
t0 acquire lock success
t0 state: TIMED_WAITING
t1 state: BLOCKED
done.
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.");

//output
t0 acquire lock success
t0 state: WAITING
done.

区别

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.");

//output
t0 acquire lock success
t0 state: TIMED_WAITING
t1 state: WAITING
done.

同样是加锁,在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: 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)

但其实这里的RUNNABLE只是JAVA层面的线程状态,在操作系统或进程角度来看,该线程还是WAITING的状态;SocketInputStream是一个BIO的实现,当没有收到数据(或者说没有准备好可读的数据)时会发生阻塞,可这个阻塞在JAVA线程状态里是RUNNABLE的状态,不过他并不会占用用户态的CPU时间片,内核在接受到数据后会结束这个阻塞

参考

阅读 847

坚持原创,专注分享 JAVA、网络、IO、JVM、GC 等技术干货

2.9k 声望
4.3k 粉丝
0 条评论

坚持原创,专注分享 JAVA、网络、IO、JVM、GC 等技术干货

2.9k 声望
4.3k 粉丝
文章目录
宣传栏