说说多线程中常用的几个方法

àì夳堔傛蜴生んèń 2021-08-27 19:29 459阅读 0赞

点击上方 [Java后端][Java]，选择 设为星标

优质文章，及时送达

--------------------

Object中的wait、notify、notifyAll，可以用于线程间的通信，核心原理为借助于监视器的入口集与等待集逻辑。

通过这三个方法完成线程在指定锁（监视器）上的等待与唤醒，这三个方法是以锁（监视器）为中心的通信方法。

除了他们之外，还有用于线程调度、控制的方法，他们是sleep、yield、join方法，他们可以用于线程的协作，他们是围绕着线程的调度而来的。更多关于多线程的文章放在了本公众号（Java后端），回复 666 即可获取。

**sleep方法**

有两个版本的sleep方法，看得出来，核心仍旧是native方法，非native方法只是进行了参数校验，接着仍旧是调用的native方法，这个情形与wait是类似的。

![format_png][]

接下来仔细看下，native版本的sleep

> 在指定的毫秒数内让当前正在执行的线程休眠（暂停执行），此操作受到系统计时器和调度程序精度和准确性的影响。该线程不丢失任何监视器的所属权。

**注意**

sleep不会释放锁，不会释放锁，不会释放锁，可以理解为他进入监视器这个房间之后，在这房间里面睡着了。

与wait类似的是，sleep也是可中断方法（从方法签名可以看得出来，可能抛出InterruptedException），也就是说如果一个线程正在sleep，如果另外的线程将他中断（调用interrupt方法），将会抛出异常，并且中断状态将会擦除。

所以对于sleep方法，要么自己醒来，要么被中断后也会醒来。

对于sleep始终有一个超时时间的设置，所以，尽管他是在监视器内睡着了，但是并不会导致死锁，因为他终究是要醒来的。

如下，线程休眠500毫秒，主线程50毫秒打印一次状态

> ps：sleep方法的调用结果为状态：TIMED\_WAITING

**![format_png 1][]**

**借助于sleep方法，可以模拟线程的顺序执行**

比如下面示例，两个阶段，第二个阶段将在第一个阶段执行之后才会执行。

package test1;
    import java.lang.Thread.State;
    public class T16 {
    public static void main(String[] args) {
    //模拟执行任务的第一个阶段的执行
    Thread stepOne = new Thread(() -> {
    System.out.println(Thread.currentThread().getName()+" : 第一阶段任务开始执行");
    try {
    Thread.sleep(1000);
    System.out.println(Thread.currentThread().getName()+" : 第一阶段任务执行结束");
    } catch (InterruptedException e) {
    }
    }, "firstStage");
    stepOne.start();
    //模拟任务第二个阶段的执行
    Thread stepTwo = new Thread(() -> {
    while (!State.TERMINATED.equals(stepOne.getState())) {
    try {
    Thread.sleep(100);
    System.out.println(Thread.currentThread().getName()+" : 我在等待第一阶段任务执行结束");
    } catch (InterruptedException e) {
    }
    }
    System.out.println(Thread.currentThread().getName()+" : 第二阶段任务执行结束");
    }, "secondStage");
    stepTwo.start();
    }
    }

![format_png 2][]

另外，你应该已经注意到**sleep方法都有static修饰，既然是静态方法，在Thread中的惯例就是针对于：当前线程，当前线程，当前线程**

## **yield方法** ##

对于sleep或者wait方法，他们都将进入特定的状态，伴随着状态的切换，也就意味着等待某些条件的发生，才能够继续，比如条件满足，或者到时间等

但是yield方法不涉及这些事情，他针对的是时间片的划分与调度，所以对开发者来说只是临时让一下，让一下他又不会死，就只是再等等。

yield方法将会暂停当前正在执行的线程对象，并执行其他线程，他始终都是RUNNABLE状态。

![format_png 3][]

不过要注意，可以认为yield只是一种建议性的，如果调用了yield方法，对CPU时间片的分配进行了“礼让”，他仍旧有可能继续获得时间片，并且继续执行。

所以一次调用yield 并不一定会代表肯定会发生什么。

**![format_png 4][]**

借助于while循环以及yield方法，可以看得出来，也能一定程度上达到线程排序等待的效果。

![format_png 5][]

yield也是静态方法，所以，也是针对于当前线程，当前线程，当前线程。

## **join方法** ##

## 三个版本的join方法 ##

![format_png 6][]

方法的实现过程，与wait也是非常类似，下面两个版本的方法一个调用join（0）,一个参数校验后，调用join（millis），所以根本还是单参数版本的join方法。

![format_png 7][]

在方法深入介绍前先看个例子。

> 一个线程，循环5次，每次sleep 1s，主线程中打印信息

从结果可以看到，主线程总是在线程执行之后，才会执行，也就是主线程在等待我们创建的这个线程结束，结束了之后才会继续进行。

![format_png 8][]

![format_png 9][]

如果调整下顺序--->start 与 join的先后顺序，再次看下情况，可以发现顺序没有保障了。

![format_png 10][]

**结论**

> 主线程main中调用启动线程（调用start），然后调用该线程的join方法，可以达到主线程等待工作线程运行结束才执行的效果，并且join要在start调用后

如何做到的？

![format_png 11][]

从上面源代码可以看得出来，内部调用了wait方法，所以也能明白为啥join也会抛出InterruptedException了吧

主线程main中调用thread.join（）方法，join方法相当于join（0），也就是

while (isAlive()) {
       wait(0);
    }

而这个wait（0）就相当于是this.wait（0），this就是我们自己创建的那个线程thread，看看方法的签名是不是有一个synchronized

isAlive（）也是this.isAlive（），也就是如果当前线程alive（已经启动，但是未终止），那么将持续等待，等待的临界资源就是我们创建的这个线程对象本身。

所以这两行代码的含义就是：

> 该线程是否还存活？如果存活，调用join的那个线程将会在这个对象上进行等待（进入该线程对象的等待集）

也就是说调用一个线程的join方法，就是在这个线程是等待，这个线程对象就是我们的锁对象（不要疑惑，Object都可以作为锁，Thread实例对象怎么不可以？）

肯定大家很奇怪，既然是等待，wait又不会自己醒来，那不是出问题了吗？

其实线程结束后，会调用this.notifyAll，所以主线程main会被唤醒。

如果传递的参数不为0，将会走到下面的分支，会wait指定时长，与上面的逻辑一致，只不过是有指定超时时长而已。

long delay = millis - now;
    if (delay <= 0) {
       break;
      }
    wait(delay);
    now = System.currentTimeMillis() - base;

手动版本的等待结束，只是将join方法换成了同步代码块，锁对象为那个线程的实例对象thread，调用他的wait方法。

从结果上看，效果一样（不过此处没有持续监测isAlive（），所以一旦主线程醒来，即使线程没有结束，也会继续，不能百分百确保main肯定等待线程结束）。

![format_png 12][]

不过要注意：注释中有说明，自己不要使用Thread类的实例对象作为锁对象，如果是现在这种场景，使用join即可。

为什么？从我们目前来看，join方法就是以这个对象为锁，如果你自己在使用，又是wait又是notify（notifyAll）的，万一出现什么隐匿的问题咋办？

![format_png 13][]

所以join方法的原理就是：将指定的Thread实例对象作为锁对象，在其上进行同步，只要那个线程还活着，那么就会持续等待（或者有限时长）

线程终止之后会调用自身this.notifyAll，以通知在其上等待的线程。

简单说，只要他活着大家就都等着， 他死了会通知，所以效果就是在哪里调用了谁的join，哪里就要等待这个线程结束，才能继续。

### **为什么要在start之后？** ###

![format_png 14][]

如上面所示，将join改造成同步代码块如下所示，如果这段同步代码在start方法之前。

看下结果，没有等待指定线程结束，main主线程就结束了。

![format_png 15][]

因为如果还没有调用start方法，那么isAlive是false（已开始未结束），主线程根本就不会等待，所以继续执行，然后继续到下面的start，然后主线程结束

所以，为什么join方法一定要在start之前？

就是因为这个isAlive方法的校验，你没有start，isAlive就是false，就不会同步等待，所以必须要先start，然后才能join

### **小结** ###

对于join方法，有两个关键：

*  调用的哪个对象的join？
 *  在哪里调用的？

换一个说法：

join的效果是：一个线程等待另一个线程（直到结束或者持续一段时间）才执行，那么谁等待谁？

在哪个线程调用，哪个线程就会等待；调用的哪个Thread对象，就会等待哪个线程结束；

## **状态图回顾** ##

在回顾下之前状态一文中的切换图，又了解了这几个方法后，应该对状态切换有了更全面的认识

![format_png 16][]

**总结**

对于yield方法，比较容易理解，只是简单地对于CPU时间片的“礼让”，除非循环yield，否则一次yield，可能下次该线程仍旧可能会抢占到CPU时间片，可能方法调用和不调用没差别。

sleep是静态方法，针对当前线程，进入休眠状态，两个版本的sleep方法始终有时间参数，所以必然会在指定的时间内苏醒，他也不会释放锁，当然，sleep方法的调用非必须在同步方法（同步代码块）内。

join是实例方法，表示等待谁，是用于线程顺序的调度方法，可以做到一个线程等待另外一个线程，join有三个版本，指定超时时间或者持续等待直到目标线程执行结束，join也无需在同步方法（同步代码块）内。

sleep和join都是可中断方法，被其他线程中断时，都会抛出InterruptedException异常，并且会醒来。

join方法底层依赖wait，我们对比下wait与sleep。

*  wait和sleep都会使线程进入阻塞状态，都是可中断方法，被中断后都会抛出异常
 *  wait是Object的方法，sleep是Thread的方法
 *  wait必须在同步中执行，sleep不需要（join底层依赖wait，但是不需要在同步中，因为join方法就是synchronized的）
 *  wait会释放锁，sleep不会释放锁
 *  wait（无超时设置的版本）会持续阻塞，必须等待唤醒，而sleep必然有超时，所以一定会自己醒来
 *  wait 实例方法（Object），在对象上调用，表示在其上等待；sleep静态方法，当前线程

作者：noteless

链接：cnblogs.com/noteless/p/10443446.html

--------------------

\-END-

如果看到这里，说明你喜欢这篇文章，请**转发****、点赞**。同时标星（置顶）本公众号可以第一时间接受到博文推送。

**推****荐****阅****读**

***1. ***[一个基于 Spring Boot 的项目骨架][Spring Boot]

***2. ***[聊聊重构那些事][Link 1]

***3.*** [今年的毕业生也太太太太难了吧！][Link 2]

***4. ***[7 小时上线了 1 个秒杀系统！][7 _ 1]

![format_png 17][]

[Java]: https://blog.csdn.net/qq_37217713/article/details/101445094
[format_png]: /images/20210730/fd97067d2457449591a0033bea9b072a.png
[format_png 1]: /images/20210730/c5432ebdc6504ec99c80a4c3b7bfdaf3.png
[format_png 2]: /images/20210730/b8de3c722d674730bd27c5bce45b4500.png
[format_png 3]: /images/20210730/35dfe10ea89d43d7a0f354607d68dfab.png
[format_png 4]: /images/20210730/aa4dbc7fc67e4f7ab35f4c4043b9cb8c.png
[format_png 5]: /images/20210730/7c5464b044164cf2b78f45076ef9ff22.png
[format_png 6]: /images/20210730/e74265bdde2b4b50936b839e431ff837.png
[format_png 7]: /images/20210730/2017cd2c6c9d49bbbaeeb04d37149974.png
[format_png 8]: /images/20210730/e15b19dda37c49679a94df3e6be1e92f.png
[format_png 9]: /images/20210730/ad5e8f05f47f411f85856dd5aa451fb5.png
[format_png 10]: /images/20210730/f32223d650d143d4a7dca678ddfe1473.png
[format_png 11]: /images/20210730/483b203466cd469f834eba7d6fc72fda.png
[format_png 12]: /images/20210730/17916a530fc342288e98e22711e46748.png
[format_png 13]: /images/20210730/776e5ef7d45d4dd4afa49ebee7af25a5.png
[format_png 14]: /images/20210730/700b871b62bb443b9401a9fb607ca962.png
[format_png 15]: /images/20210730/5b2fe88cabbf4e949c397341e36be394.png
[format_png 16]: /images/20210730/891885b465bb4543bcff71ce411b03a4.png
[Spring Boot]: http://mp.weixin.qq.com/s?__biz=Mzg2MjEwMjI1Mg%3D%3D&chksm=ce0e544ef979dd582fd3c4427cb9c32641da58975fa7977d584f35bf75fecd9599a19dabfbe6&idx=1&mid=2247492557&scene=21&sn=8d72f264faf55fc241ed42eb724073f1#wechat_redirect
[Link 1]: http://mp.weixin.qq.com/s?__biz=Mzg2MjEwMjI1Mg%3D%3D&chksm=ce0e544ef979dd58302f43cb9a467af950b55e637c108a6c6ded0f7d97b15018deaa349628d1&idx=2&mid=2247492557&scene=21&sn=6841276dd3a508dc036669a4037357ec#wechat_redirect
[Link 2]: https://blog.csdn.net/qq_37217713/article/details/105154367
[7 _ 1]: https://blog.csdn.net/qq_37217713/article/details/105132380
[format_png 17]: /images/20210730/259e19bf611448ce86f885a166f77e0a.png