乐趣区

关于java:JAVA-线程状态中可能存在的一些误区

jiezi

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 工夫片，内核在承受到数据后会完结这个阻塞

参考

  • https://blog.fastthread.io/2018/09/02/threads-stuck-in-java-net-socketinputstream-socketread0/
退出移动版