实例方法:
interrupt()方法是设置结束阻塞(sleep、wait等),并且设置中断标记true
isInterrupted()判断当前是否中断
静态方法:
Thread.interrupted():调用这个方法的线程中断标记位还原为false
那么好,既然上面的方法作用是清晰的,尝试启动个线程进行操作:
一.疑惑1,为什么如下代码调用后会出现false
java
@Slf4j
public class InterruptTest {
public static void main(String[] args) {
Thread t1 = new Thread(() -> {
try {
Thread.currentThread().sleep(5000);
} catch (InterruptedException e) {
log.info("中断状态1:{}", Thread.currentThread().isInterrupted());
}
});
t1.start();
try {
Thread.sleep(2000); // 等待2秒,确保主线程调用t1线程interrupt时t1是启动好的
} catch (InterruptedException e) {
e.printStackTrace();
}
t1.interrupt();
}
}
bash
输出结果: InterruptTest - 中断状态1:false
不是说线程实例方法interrupt()调用后会设置中断标记嘛,为什么是false
解答:当 InterruptedException
被抛出时,JVM 会自动清除当前线程的中断标志。
它清除中断标志是为了避免开发者不小心忽略异常后,线程还带着一个"脏标志"继续运行,导致逻辑混乱,真是贴心的很。
一.疑惑2,既然JVM自动清理标记,再调用interrupt()总可以看到true了吧
java
public static void main(String[] args) {
Thread t1 = new Thread(() -> {
try {
Thread.currentThread().sleep(5000);
} catch (InterruptedException e) {
log.info("中断状态1:{}", Thread.currentThread().isInterrupted());
Thread.currentThread().interrupt();
log.info("中断状态2:{}", Thread.currentThread().isInterrupted());
Thread.interrupted();
log.info("中断状态3:{}", Thread.currentThread().isInterrupted());
}
});
t1.start();
try {
Thread.sleep(2000); // 等待2秒,确保主线程调用t1线程interrupt时t1是启动好的
} catch (InterruptedException e) {
e.printStackTrace();
}
t1.interrupt();
}
运行结果:果然出现了true
bash
thread.InterruptTest2 - 中断状态1:false
thread.InterruptTest2 - 中断状态2:true
thread.InterruptTest2 - 中断状态3:false
thread.cpp下的interrupt函数:(807行是调用操作系统的逻辑)

继续跟进到os_linux.cpp,也可以分系统选看,我直接选Linux的了


如果线程不是阻塞状态(例如未在 sleep()、park() 或 wait() 等阻塞点),这段代码的效果仅仅是改了中断标志位,其他操作(如 unpark() 唤醒线程)不会有实际作用,也不会耽误线程继续运行。
thread.cpp的is_interrupted函数:

同样溯源到os_linux.cpp

一.疑惑3,wait、notify-all为什么都要加同一个synchronized
阅读Object相关源码:objectMonitor.cpp
wait函数:

尾插法放入队列:

_WaitSetLock 是一个自旋锁,用于保护 WaitSet 的并发访问,在objectMonitor.hpp中

也就是WAIT/TIME WAIT本质上是用一个Object中的等待队列去存储需要等待的线程对象,每一个Object对象都可以充当这个角色,获取这个对象的waitset才能把Thread放入,唤醒相当于再从这个waitset中把线程剔除来再唤醒,这也就是为什么wait notify/all 方法需要synchronized同一个对象了
再来看一下notify函数:(出一个线程对象,然后唤醒)


上图表明从头部出队列

也就是说,插入顺序是:_WAIT_SET 1 2 3 4 5,获取顺序也是1 2 3 4 5符合FIFO队列先进先出
再来看一下notifyAll函数:(全部唤醒)

由于迭代器用的还是DequeueWaiter,所以这个仍然是顺序出队列,并不是随机的