Java线程系列（2）——线程有限等待状态分析

Java线程系列（2）——线程有限等待状态分析

上一篇文章 Java线程系列（1）——thread dump格式、锁与线程的状态
讨论了 Jstack 的用法、thread dump 文件的基本格式, 介绍了线程的六种状态并且分析了 BLOCKED 和 WAITING 状态的成因以及 dump 文件的特征。

本文是Java线程系列文章的第二篇, 继续讨论较为复杂的 TIMED_WAITING 状态。

一、有限等待状态

TIMED_WAITING意味着线程调用了限时版本的API，正在等待时间流逝；当等待时间过去后，线程一样可以恢复运行。如果线程进入了WAITING状态，一定要特定的事件发生才能恢复运行；而处在TIMED_WAITING的线程，如果特定的事件发生或者是时间流逝完毕，都会恢复运行。

限时版的API, 最容易想到的可能就是 Thread.sleep 方法, 看一个例子:

1. Thread.sleep

测试代码:

package liyin.code;

public class App {
    public static void main(String[] args) {

        Runnable task = new Runnable() {
            public void run() {
                synchronized (App.class) {
                    try {
                        Thread.sleep(20000);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
            }
        };

        new Thread(task, "haha").start();
        new Thread(task, "hehe").start();
    }
}

一般情况下, haha线程会先拿到 App.class 对象的锁, 然后调用 Thread.sleep 方法睡眠20秒, 在此期间一直持有锁, hehe线程在haha线程睡眠期间会一直阻塞, 直到haha线程睡眠结束释放锁, hehe线程重复haha线程的行为。前20秒的 thread dump 如下:

Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.79-b02 mixed mode):

"hehe" prio=5 tid=0x00007fef75040800 nid=0x5703 waiting for monitor entry [0x0000700001658000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at liyin.code.App$1.run(App.java:10)
    - waiting to lock <0x00000007aab244b8> (a java.lang.Class for liyin.code.App)
    at java.lang.Thread.run(Thread.java:745)

"haha" prio=5 tid=0x00007fef74026000 nid=0x5503 waiting on condition [0x0000700001555000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
    at java.lang.Thread.sleep(Native Method)
    at liyin.code.App$1.run(App.java:10)
    - locked <0x00000007aab244b8> (a java.lang.Class for liyin.code.App)
    at java.lang.Thread.run(Thread.java:745)

分析:

• haha线程的状态是TIMED_WAITING (sleeping), 可以看出线程处于有限等待状态的睡眠状态, 等睡眠结束, 线程会自动唤醒。线程的行为是waiting on condition, 产生这种行为的场景很多, 下一篇文章分析现成的行为时详细讨论。
• hehe线程的在 Entry Set 队列中等待 App.class 的锁, 行为是 waiting for monitor entry, 从调用修饰 waiting to lock <0x00000007aab244b8>看出这个对象正好是hehe线程锁住的对象locked <0x00000007aab244b8>。

2. JUC限时API

package liyin.code;

import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

public class App {

    // Java显示锁
    private static Lock lock = new ReentrantLock();
    // 锁关联的条件队列
    private static Condition condition = lock.newCondition();

    public static void main(String[] args) {

        Runnable task = new Runnable() {
            public void run() {
                try {
                    // 加锁, 进入临界区
                    lock.lock();
                    condition.await(20000, TimeUnit.MILLISECONDS);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                } finally {
                    // 解锁, 退出临界区
                    lock.unlock();
                }
            }
        };

        new Thread(task, "haha").start();
        new Thread(task, "hehe").start();
    }
}

一般情况下, haha线程会先执行Lock.lock方法加锁进入临界区, 然后调用Condition.await方法进入锁(lock)关联的条件队列(condition)中等待并释放持有的锁。hehe线程在haha线程释放锁之后, 重复haha线程的行为。

haha线程和hehe线程进入等待队列中限时等待, 直到有其它线程调用Condition.signal 、Condition.signalAll 才会唤醒, 或者无其它线程唤醒等待20秒之后自动唤醒。thread dump 如下:

Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.79-b02 mixed mode):

"hehe" prio=5 tid=0x00007ffe3401e800 nid=0x5703 waiting on condition [0x0000700001658000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000007aab250f8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2176)
    at liyin.code.App$1.run(App.java:22)
    at java.lang.Thread.run(Thread.java:745)

"haha" prio=5 tid=0x00007ffe3385e000 nid=0x5503 waiting on condition [0x0000700001555000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000007aab250f8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2176)
    at liyin.code.App$1.run(App.java:22)
    at java.lang.Thread.run(Thread.java:745)

分析:

• haha线程和hehe线程状态同时为TIMED_WAITING (parking), 可以看出线程处于有限等待状态的挂起状态。挂起线程的方法是操作系统的本地方法, Unsafe类一般用于和系统打交道, 可以直接分配/释放内存、挂起与恢复线程等, 一般Java应用无法直接使用。
• Lock是Java的显示锁, 从线程栈中并没有看到locked和waiting to lock调用修饰信息, 是因为Java显示锁是代码实现的, 并不是JVM本身的机制, 虽然有依然有临界区的概念, 但是调用栈中并没有关于锁的修饰信息。显示锁的更深入的内容, 后面的文章讨论。

二、小结

有限等待状态的线程在等待一个特定的操作, 如果这个特定的操作没有发生, 等待时间到了, 线程也会自行唤醒继续执行。处于这种状态的线程不会被分配CPU执行时间。

如果系统中有大量TIMED_WAITING的线程, 需要分析引起线程有时限等待的原因, 原因可以从线程dump信息的第二行中查看。如果原因是 sleeping, 可以根据线程栈信息找到代码中调用 Thread.sleep 的地方, 分析为什么sleep以及sleep的合理性。如果原因是 parking, 可能是由于多个线程之间有协作调用了 Condition.await 方法进入了条件队里中等待, 同样需要根据具体的业务场景分析这些线程是否能够在等待时间内被唤醒, 以及其合理性。