（接上文《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)
这时我们看到的效果和前文中使用ReentrantLock使线程进入“阻塞”状态的效果是一致的。
====================================
（接下文）