JVM调试常用命令——jstack命令与线程状态（3）

最新推荐文章于 2025-01-03 20:38:39 发布

说好不能打脸

最新推荐文章于 2025-01-03 20:38:39 发布

阅读量4k

点赞数 1

CC 4.0 BY-SA版权

分类专栏： javaer java线程 java线程基础文章标签： AQS jstack WATING 线程状态

本文链接：https://blog.csdn.net/yinwenjie/article/details/84728631

javaer 同时被 3 个专栏收录

65 篇文章

订阅专栏

java线程

27 篇文章

订阅专栏

java线程基础

26 篇文章

订阅专栏

本文深入探讨Java中线程阻塞的各种场景，包括join方法、可重入锁、LockSupport的使用，以及它们如何影响线程状态。通过示例代码和jstack命令输出，详细解析线程进入WAITING状态的过程。

（接上文《JVM调试常用命令——jstack命令与Java线程栈（2）》）

2.1.3.2、当前线程调用目前线程的join方法，等待后者执行完成

join方法可以让一个线程持续等待到另一个线程完成运行后，再继续进行运行。下面我们就来看一下使用join方法让一个线程进入WATING状态时，在jstack命令结果中的打印效果。

// ......之前的代码片段省略
public static void main(String[] args) {
  Thread thread1 = new Thread(new MyThread1(), "thread1");
  Thread thread2 = new Thread(new MyThread2(thread1), "thread2");
  thread1.start();
  thread2.start();
}
private static class MyThread2 implements Runnable {
  private Thread joinThread;
  public MyThread2(Thread joinThread) {
    this.joinThread = joinThread;
  }
  @Override
  public void run() {
    Thread currentThread = Thread.currentThread();
    System.out.println("当前线程[" + currentThread.getName() + "]使用join进入等待");
    try {
      this.joinThread.join();
    } catch (InterruptedException e) {
      e.printStackTrace(System.out);
    }
    System.out.println("当前线程[" + currentThread.getName() + "]已经完成等待");
  }
}
private static class MyThread1 implements Runnable {
  @Override
  public void run() {
    Thread currentThread = Thread.currentThread();
    System.out.println("当前线程[" + currentThread.getName() + "]正在运行");
  }
}
// ......之后的代码片段省略

以上代码，我们创建了两个线程Thread1和Thread2，其中Thread2会使用join方法，等待Thread1运行完成后在运行。我们使用debug方式，将以上代码的运行效果停滞于如下图所示的状态：

在这里插入图片描述

如上图所示的效果，我们将MyThread2类的实例运行到第21行，也就是调用join方法的位置，这时MyThread2的线程就会进入WATING状态；而MyThread1类的实例运行到第33行，也就是刚完成System.out方法，但是整个方法还没有运行结束的位置，这时MyThread1类的实例处于RUNNABLE状态。接着我们运行jstack命令验证线程状态，如下：

>jstack 289476
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.144-b01 mixed mode):
.........
"thread2" #15 prio=5 os_prio=0 tid=0x000000001ec53000 nid=0x46064 in Object.wait() [0x000000001fc5f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x000000076c5c4910> (a java.lang.Thread)
        at java.lang.Thread.join(Thread.java:1252)
        - locked <0x000000076c5c4910> (a java.lang.Thread)
        at java.lang.Thread.join(Thread.java:1326)
        at testThread.TestJoin$MyThread2.run(TestJoin.java:25)
        at java.lang.Thread.run(Thread.java:748)
"thread1" #14 prio=5 os_prio=0 tid=0x000000001ec52000 nid=0x46054 at breakpoint[0x000000001fb5f000]
   java.lang.Thread.State: RUNNABLE
        at testThread.TestJoin$MyThread1.run(TestJoin.java:36)
        at java.lang.Thread.run(Thread.java:748)
.........

从命令结果可以看到，名为thread2的线程在“TestJoin$MyThread2”类定义的25行调用了join方法，并在join方法中获得了对象（0x000000076c5c4910）的操作权，继续执行join方法中的内容，到达了第1252行。在这一行调用了wait方法释放掉对象（0x000000076c5c4910）的操作权，并进入WATING状态。所以我们可以看当名为thread2的线程进入WAITING状态后，其状态说明信息中被标注为“(on object monitor)”，这是因为这种WAITING状态的本质和2.1.3.1中介绍的调用wait方法进入WAITING状态的本质是一样的。另外，从join方法的主要代码块中，我们也可以读到相佐证的源代码：

在这里插入图片描述

2.1.3.3、可重入锁（包括读写分离锁）调用lock方法，并触发阻塞效果

ReentrantLock和ReentrantReadWriteLock都是AQS同步框架的一个具体实现（关于AQS框架，我们将会在本专题后续的文章中进行详细讲解），那么基于ReentrantLock或者ReentrantReadWriteLock产生的“阻塞”效果又是怎样呢？首先上代码：

// ......之前的代码片段省略
public static void main(String[] args) {
  ReentrantLock myLock = new ReentrantLock();
  // 产生两个线程，使用debug方式，观察特定效果
  Thread thread1 = new Thread(new MyThread(myLock), "thread1");
  Thread thread2 = new Thread(new MyThread(myLock), "thread2");
  thread1.start();
  thread2.start();
}
private static class MyThread implements Runnable {
  private ReentrantLock myLock;
  MyThread(ReentrantLock myLock) {
    this.myLock = myLock;
  }
  @Override
  public void run() {
    String threadName = Thread.currentThread().getName();
    try {
      myLock.lock();
      System.out.println("thread[" + threadName + "]正在工作......");
    } finally {
      myLock.unlock();
    }
  }
}
// ......之后的代码片段省略

之上的代码片段很简单了，不需要再进行过多的解释，如果读者对ReentrantLock和ReentrantReadWriteLock不清楚，那么建议先阅读网络资料。通过debug模式，我们将以上代码停止在以下状态：

线程名为thread1的线程调用lock方法后，执行到“System.out.println”这句代码；由于这时thread1还没有调用unlock方法，所以当线程thread2调用lock方法时，将会进入阻塞状态。如下图所示：

在这里插入图片描述

细心的读者可以发现，在以上使用ReentrantLock或者ReentrantReadWriteLock的调试信息中，调试窗口示意的两个线程好像并没有提示开发人员“某个线程持有了某个对象的锁”，既是没有那把“黄色的锁”，通过jstack命令我们也可以观察到这一现象：

# jstack 336144

Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.144-b01 mixed mode):
"thread2" #15 prio=5 os_prio=0 tid=0x000000001ea40000 nid=0x462b4 waiting on condition [0x000000001fa4e000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x000000076c5c60b8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
        at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
        at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
        at testThread.TestReentrantLock$MyThread.run(TestReentrantLock.java:27)
        at java.lang.Thread.run(Thread.java:748)
		
"thread1" #14 prio=5 os_prio=0 tid=0x000000001ea3f000 nid=0x47cf0 runnable [0x000000001f94e000]
   java.lang.Thread.State: RUNNABLE
        at testThread.TestReentrantLock$MyThread.run(TestReentrantLock.java:28)
        at java.lang.Thread.run(Thread.java:748)

如以上命令结果所示，名叫thread1和thread2的线程确实没有被提示“locked”住了某个对象，只有进入“阻塞”状态的thread2有一个parking标识——但是thread2确实进入了阻塞状态，并在在thread调用了unlock方法后确实又能够恢复到RUNNABLE状态。这实际上就是AQS同步框架的工作效果（后文详细讲解）——这时读者可以观察到在WAITING状态后的标识使用的是“(parking)”而不是“object monitor”。

2.1.3.4、使用LockSupport，并触发阻塞效果

LockSupport属于AQS框架的底层支持部分，LockSupport提供了线程元语级别的执行/阻塞控制，能够帮助开发者完成类似ReentrantLock、Semaphore等这样基于AQS框架的高级别同步工具。有了2.1.3.3中对ReentrantLock阻塞效果的分析后，这里我们大致检验一下直接使用LockSupport让指定线程进入阻塞模式后的效果。同样，先上代码片段（在这里，读者如果不清楚LockSupport中主要方法的功能也无所谓，后文将进行详细介绍）：

// ......之前的代码片段省略
private static Object lockObject = new Object();
// 相信不用写太多注释了吧。。。。
public static void main(String[] args) {
  Thread thread2 = new Thread(new MyThread2(), "thread2");
  Thread thread1 = new Thread(new MyThread1(thread2), "thread1");
  thread1.start();
  thread2.start();
}
private static class MyThread1 implements Runnable {
  private Thread targetThread;
  public MyThread1(Thread targetThread) {
    this.targetThread = targetThread;
  }
  @Override
  public void run() {
    LockSupport.unpark(targetThread);
    System.out.println("// do somethings");
  }
}
private static class MyThread2 implements Runnable {
  @Override
  public void run() {
    LockSupport.park(lockObject);
    System.out.println("// do somethings");
  }
}
// ......之后的代码片段省略

通过debug模式的支持，我们先让MyThread2调用LockSupport.park方法进入阻塞状态，MyThread1中的LockSupport.unpark方法可以让前者解除阻塞状态，但是我们还不忙执行。这时通过jstack命令观察进程中主要的线程状态如下：

jstack 341584
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.144-b01 mixed mode):
"thread2" #14 prio=5 os_prio=0 tid=0x000000001ea99000 nid=0x53624 waiting on condition [0x000000001faae000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x000000076c5c4f60> (a java.lang.Object)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at testThread.TestLockSupport$MyThread2.run(TestLockSupport.java:34)
        at java.lang.Thread.run(Thread.java:748)
"thread1" #15 prio=5 os_prio=0 tid=0x000000001ea98800 nid=0x532d0 at breakpoint[0x000000001f9af000]
   java.lang.Thread.State: RUNNABLE
        at testThread.TestLockSupport$MyThread1.run(TestLockSupport.java:26)
        at java.lang.Thread.run(Thread.java:748)