多线程编程2——Thread类的构造方法和属性

渡上舟

于 2024-01-25 23:45:11 发布

阅读量924

点赞数 22

分类专栏：操作系统文章标签： java 开发语言

本文链接：https://blog.csdn.net/m0_61731585/article/details/135771639

版权

操作系统专栏收录该内容

10 篇文章 0 订阅

订阅专栏

一、Thread类是用来干啥的？

上节我们已经知道了在Java中如何进行多线程编程，会用到Thread类。Thread类是JVM用来管理线程的一个类，换句话说，每个线程都有一个唯一的Thread对象与之关联。我们对线程的各种操作都是根据Thread类进行展开的。

上节使用了5种方法来创建线程，这5种方法只是语法规则不同，本质上是一样的：

在run方法中描述要做的任务，即线程要干的活。start方法才是真的在操作系统中创建了个线程，并且让新线程调用run方法，执行run方法中的代码。

通俗的讲，就是run方法只是描述了要干的活是啥，调用start方法才真正找来了干活的人，并且把要干的活让他去干（调用run方法，执行run方法中的代码）。

二、Thread的构造方法

方法	说明
Thread()	创建Thread对象
Thread(Runnable target)	创建Thread对象
Thread(String name)	创建Thread对象，并给线程命名
Thread(Runnable target,String name)	创建Thread对象，并给线程命名

给线程命名的原因是，

t 调用 start方法创建的线程，默认的名字是thread-0之类的，往下就是thread-1,2,3......，

给线程起个名字，方便调试。

下面举个例子进行说明：

左边是没给线程命名的代码，右边是给线程命名了的代码。

打开 jconsole.exe 分别查看，发现：

没给线程命名，线程名为默认的Thread-0；给线程命名了的，线程名为myThread

我们还发现，调用main方法的主线程没了，这是为什么呢？

这是因为主线程已经执行完了。

主线程要干的活是调用main方法，执行main方法中的代码。main方法执行到 t.start() ，就执行完了。对于主线程来说，main方法执行完了，自己也就没了。

所以，进程中没有主线程。

其实，对于start 创建的新的线程来说，也是这样。

新线程要干的活是调用run方法，执行run方法中的代码。当run方法中的代码执行完了，自己也就没了。

三、Thread的常见属性和方法

属性和获取属性的方法：

属性	获取属性的方法	对方法的说明
ID	getId()	获取线程的ID
名称	getName()	获取Thread构造方法中给线程起的名字
状态	getState()	获取线程的状态（Java里的线程状态要比操作系统原生的线程状态更丰富一些）
优先级	getPriority()	优先级可以获取也可以设置，但没用

常见方法：

Thread的常见方法	对方法的说明
isDaemon()	是否是守护线程，可理解为是否是“后台线程”
setDaemon()	把线程设置成后台线程
isAlive()	判断线程是否存在
isInterrupted()	判断线程是否被终止
interrupt()	通知线程终止
join()	别的线程等待这个线程

常见类方法：（static修饰的）

Thread的常见类方法（静态方法）	对方法的说明
currentThread()	获取当前线程。在哪个线程里调用的这个方法，就是得到哪个线程的对象。
sleep()

getId()，getName()，getState()，getPriority() 这几个方法都很好理解

我对下面几个常见方法分别进行详细介绍：

1、isDaemon() —— 是否是后台线程

前台线程：

会阻止进程结束，前台线程的工作没做完，进程是完不了的

后台线程：

不会阻止进程结束，后台线程工作没做完，进程是可以结束的

代码里手动创建的线程，默认都是前台线程。调用main方法的主线程也是前台线程。其他的jvm自带的线程都是后台线程。

当然，我们也可以通过使用setDaemon()方法，把前台线程手动的设置成后台线程。

当你将这个线程设置成后台线程时，此时进程的结束与否就和这个线程无关了。

举个例子：

分析：

将 t 设置成后台线程，此时进程的结束与否就和 t 无关了。即使 t 的工作没做完(run方法中的代码没执行完)，进程照样可以结束。

由于这个进程中只有主线程和 t线程这两个线程，t线程为后台线程，所以进程的结束只与主线程有关，main方法执行结束，主线程就结束了。进程也就结束了。控制台上什么都不打印

2、isAlive() —— 判断线程是否存在

new Thread对象操作并不创建线程（这里的线程指的是系统内核里的PCB），只有调用了start方法，才是真正创建了PCB，才真正有个货真价实的线程。

创建Thread对象，只是描述了要干啥活，调用start才真正创建了一个线程来干活。

所以，

在调用 start 之前，isAlive 是 false
在调用 start 之后，isAlive 是 true
线程干完活，销毁后，isAlive 是 false

对于第三点，再说明一下，

这个线程将run中的代码执行完了，此时线程销毁，操作系统内核中线程对应的PCB随之释放。但是 Thread t 这个对象不一定被释放了，这个对象释不释放不影响 isAlive 的结果，isAlive 还是 false。

isAlive只和操作系统内核中的PCB存不存在有关。

PCB存在，即线程存在，isAlive是true;

PCB不存在，即线程不存在，isAlive为false

举个例子：（ t 对象还存在，线程已经不存在）

分析：

主线程调用main方法，执行main方法中的代码，执行到 t.start() 时，主线程创建了一个新的线程。

此时，主线程继续执行下面的代码，新的线程调用run方法，执行run方法中的代码。

这时，主线程遇到sleep方法，休眠1秒，新线程执行打印hello的代码，在控制台输出hello，新线程执行完run方法中的代码，线程销毁，PCB随之释放。

但 t 这个对象还在，因此当主线程从休眠中醒来，继续向下执行代码，执行打印 t.isAlive()这行代码时，会在控制台输出false（因为 t 这个对象还存在，所以可以调用isAlive方法；因为虽然 t 这个对象还存在，但线程早已销毁不存在了，所以输出 false）

3、isInterrupted() —— 判断线程是否被终止

线程终止，字面意思，通知线程，让线程停下来，让线程干活干一半就不干。

但是，线程真正停不停下来，取决于线程自己，也就是线程这里具体的代码写法。

根据线程内部不同的代码写法，会出现3种情况：

线程干活干一半不干了，立即终止
线程再干一会活，稍后终止
假装没听见，不终止

那么如何通知线程终止呢？

有两种方法：

（1）使用标志位（自定义的boolean变量）

（2）使用 Thread 自带的标志位（Thread的方法内封装的boolean变量）

下面分别进行介绍：

（1）使用标志位（自定义的boolean变量）

举个例子：

定义一个boolean变量 flag，通过修改 flag 的值为 false 来控制线程终止，如下：

当主线程执行到start方法，创建一个线程时，接着，主线程继续往下执行，休眠3秒，与此同时，线程打印hello，休眠1秒。由于打印hello用时极快，几乎可以忽略不计，也就是说，线程执行循环3次，共休眠3秒后，主线程和线程才分别从休眠中醒来（谁先醒来不知道，醒来后谁先往下执行也不知道，谁先抢到cpu谁就先执行），主线程醒来后才会接着往下执行 flag=false 这行代码，线程醒来后，才会接着进行第四次循环，flag = false，循环结束。代码执行完了，线程就结束了。

由于 t线程内部的代码是那样写的，所以修改 flag 变量，t线程会结束。

但是，如果线程内根本没有 flag 变量，是while(true)，那么即使你将 flag 的值改为 false , t线程也不会结束的。

所以说，线程会不会终止，取决于线程内部自己的代码是如何写的。

使用自定义变量这种方式固然可以，但不太理想，

因为线程不能及时响应终止，尤其在sleep休眠时间比较久的时候，时间浪费在等待上。

比如下面两个代码，

第一个代码，线程中没有sleep休眠，从运行结果可以看到：创建线程到线程终止耗时约为0毫秒。也就是说，当主线程执行到 flag = false 这串代码时，线程执行到循环的代码，判断 flag 然后循环终止，代码执行完了，线程终止了。立即响应了终止。

第二个代码，线程中有3000毫秒的休眠，先休眠3000毫秒，才往下执行循坏的代码。从运行结果可以看到：从创建线程到线程结束耗时约为3009毫秒。也就是说，当主线程执行到 flag = false 这串代码时，线程还在休眠呢。你得等它休眠结束才能执行到循环的代码，判断flag，然后线程结束。在它休眠的过程中，是无法响应终止的。这就浪费了很多时间。

更好的方法是，使用 Thread 自带的标志位，它可以唤醒sleep，让线程从休眠中醒来。

（2）使用 Thread 自带的标志位（isInterrupted方法和 interrupt方法内封装的boolean变量）

使用Thread自带的标志位（Thread方法里封装的boolean变量）通知线程终止，

代码和运行结果如下：

我们很明显的发现和使用标志位的代码的运行结果是不同的。

为什么会不同？

	自定义的boolean变量	Thread自带的标志位
第一处	while(flag)	while(!Thread.currentThread().isInterrupted())
第二处	flag = false	t.interrupt()

观察发现，使用Thread自带的标志位（Thread的方法里封装的boolean变量）的代码和使用标志位（自定义的boolean变量）的代码只有上面两处不同。

那么原因肯定在这里。

对Thread的这两个方法，我来分别进行介绍。

第一个：isInterrupted()

while(!Thread.currentThread().isInterrupted())

Thread.currentThread() : 这是Thread类的静态方法，该方法的作用是 获取当前线程。在哪个线程里调用的这个方法，就是得到哪个线程的对象。

isInterrupted() : 判断线程是否被终止。被终止返回 true ，未被终止返回 false

被终止，isInterrupted为true，取反为false，循环进不去

未被终止，isInterrupted为false，取反为true，进入循环

第二个： interrupt()

t.interrupt()

interrupt方法的功能：（通知线程终止）

1、把线程内部的标志位（封装的那个boolean变量）设置成 true

2、如果线程正在进行sleep休眠，就会触发sleep内部的异常，将线程唤醒。在sleep被唤醒时，会把刚刚设置的标志位（boolean变量）再设置成 false（即清空标志位）

为什么运行结果会不一样，原因就在 interrupt 方法上。

上述代码的运行过程如下：

当主线程执行到start方法，创建一个线程时，接着，主线程继续往下执行，休眠3秒，与此同时，线程打印hello，休眠1秒。由于打印hello用时极快，几乎可以忽略不计，也就是说，线程执行循环3次，共休眠3秒后，主线程和线程才分别从休眠中醒来，才能往下执行代码。（谁先执行取决于谁先抢到CPU）。所以，控制台先打印了三个hello

从结果看出，是主线程先从sleep休眠中醒来，往下执行 interrupt方法，将标志位设置成true。这时，线程sleep还在休眠。于是触发sleep内部的异常，将线程唤醒，并且将标志位重新设置成false。

于是线程醒来后，先是往下执行catch里的代码，打印异常信息。

然后才判断循环条件，发现为true（标志位取反），能进入循环，于是继续往下执行代码，线程不终止。

sleep清空标志位的操作，就将主动权交给了线程自己，线程自己决定要不要终止。

上面这样写，线程就会假装没听见，不终止。

当然，也可以出现其它两种情况：

下面第一个代码，就是，线程干活干一半不干了，立即终止。

下面第二个代码，就是，线程再干一会活，稍后终止。

所以说，线程会不会终止，取决于线程内部自己的代码是如何写的。

使用标志位和使用Thread自带的标志位有什么区别呢？

前者是直接操作一个boolean变量，后者是将boolean变量的操作封装到Thread的isInterrupted方法和 interrupt方法里了，本质上都是操作boolean变量。

但是，Thread的方法不仅仅只有操作boolean变量这个功能。如果线程在sleep休眠，此时调用interrupt方法会触发sleep内部的异常，线程会从sleep中提前返回（线程被唤醒了）。同时，sleep会清空标志位。这也是使用Thread自带的标志位更好的原因。（原因一：唤醒sleep中的线程，不浪费时间等待。原因二：sleep被唤醒之后，会清空标志位，将是否终止的主动权交给线程自己。）

为什么不设计成 A线程让 B线程终止， B线程就立即终止呢？

因为 A、B是并发执行，随机调度的。B线程执行到哪里了，A线程并不清楚。如果A线程让B线程终止，B线程就立即终止，当B线程正在做非常重要不能终止的任务时，就会导致B线程出现严重的问题。所以，我们把主动权交给B，让B线程自己决定是否终止，什么时候终止。

4、 join() —— 别的线程等待这个线程

线程是一个随机调度的过程，我们可以通过 join方法，让别的线程等待这个线程，从而控制两个线程的结束顺序

在主线程中，调用 t.join() ，就是让主线程等待 t线程结束，此时主线程就会进入阻塞等待的状态。

如下代码：

在主线程执行start方法之后，主线程和 t线程就会并发执行各自的代码，当主线程执行到 t.join() ，会发生阻塞，等到 t线程执行结束，主线程才会从 join 中恢复回来，继续往下执行。（t线程肯定比主线程先结束）

那么，如果主线程执行到 t.join()时，t线程已经执行结束了，会怎么办呢？

主线程不会发生阻塞，不需要等待，会立刻往下执行代码。

示例代码如下：

在主线程执行start方法之后，主线程和 t线程就会并发执行各自的代码，主线程执行到sleep休眠5秒，在主线程休眠的过程中，t线程已经执行完了，当主线程从休眠中醒来往下执行到 t.join() ，由于t线程已经执行完了，所以主线程不会会发生阻塞，不需要等待，直接往下执行代码（t线程肯定比主线程先结束）

总结：

对于 join方法：

线程没结束，就等待；

线程结束了，就立即返回，往下执行代码。

可以保证这俩线程的结束顺序

join方法除了无参版本，还有有参版本

join(long millis) —— 规定了一个最大等待时间，超过此时间，就不等了。

这种方法更常见，死等容易出问题。

5、currentThread() —— 获取当前线程

public static Thread currentThread();

类方法，通过类名(类名)来调用，不需要实例。

作用是：获取当前线程。在哪个线程里调用的这个方法，就是得到哪个线程的对象。

比如下面这个代码：

主线程调用main方法，执行main方法中的代码。所以，在main方法中调用这个方法，获取的是main这个主线程。（主线程在操作系统内核中的名字叫main）

t线程调用run方法，执行run方法中的代码。所以，在run方法中调用这个方法，获取的是Thread-0这个t线程。 （t线程在操作系统内核中的名字叫Thread-0）

6、sleep(long millis) —— 让线程休眠

public static void sleep(long millis) throws InterruptedException

让线程休眠，本质上就是让这个线程对应的PCB暂时不去参与CPU的调度，处于阻塞状态。等到sleep时间到了才会醒来，回到就绪状态。

PCB是用链表来组织的，但并不是一个简单的链表，是一系列以链表为核心的数据结构。就绪状态有个就绪队列，阻塞状态有个阻塞队列。操作系统每次调度只需要从就绪队列中选一个线程。

线程A进入休眠，对应的PCB就会从就绪队列出去，放到阻塞队列中，就暂时无法参与CPU调度了。比如sleep(1000)，对应的线程就需要在阻塞队列中待 1000ms，休眠结束后才会重新回到就绪队列，等待CPU调度。CPU是随机调度的，所以什么时候能调度到这个线程并不清楚，所以说，实际的时间间隔，一般要多于1000ms。