降妖除魔 | 究竟什么是阻塞?
共 6160字,需浏览 13分钟
·
2021-06-22 14:01
前言:很多词汇,不论对科班生还是非科班生,如果不知道底层原理,就永远是一个魔法词汇。这些魔法词汇一多,就会导致晕头转向。所以开个新系列,降妖除魔,就是要斩杀这些如妖魔鬼怪般的魔法词汇。
问两个问题
阻塞,是我们程序员口中常常提到的词。
这个词,既熟悉,又陌生,熟悉到一提到它就倍感亲切,但一具体解释,就迷迷糊糊。
这个函数是阻塞的么?
public void function() {
while(true){}
}
如果你说不出来,那你再看看这个函数是阻塞的么?
public void function() {
Thread.sleep(2000);
}
为了搞清楚这个问题,我们就来一起追踪一下阻塞的本质,消灭阻塞这个魔法词汇。
从一段 Java 代码开始
写一段很简单的 java 代码
import java.util.Scanner;
public class Zuse {
public static void main(String[] args) {
Scanner scanner = new Scanner(System.in);
String line = scanner.nextLine();
System.out.println(line);
}
}
运行这段代码发现,程序将会"阻塞"在 scanner.nextLine() 这一行代码,直到用户输入并且按下了回车键,程序才会继续往下走,打印我们输入的内容,并且结束。
我们跟踪一下这一行代码的源码,九曲十八弯之后,终于跟踪到了一个不能再往下跟踪的 native 代码。
private native int readBytes(byte b[], int off, int len) throws IOException;
当然我们可以通过 openJDK 源码继续查下去,但我有点懒,怕翻车,这里用另一个巧妙的办法。
由于我们知道这个代码一定最终会触发一次 linux 的 IO 操作相关的系统调用,所以我们用 strace 命令直接将其找到。
strace -ff -e trace=desc java Zuse
我们看到程序阻塞在了这里。
read(0,
当我们输入一个字符串 "hello" 并按下回车后,这个系统调用函数被补全。
read(0, "hello\n", 8192)
OK大功告成,触发 linux 的系统调用就是 read()
这样,我们成功通过 strace 命令,直接跨越到了 linux 内核里,中间的调用过程,就不用瞎操心了。
来到 linux 内核
linux 的系统调用会注册到系统调用表(sys_call_table)中,通常是在前缀加一个 sys_。
fn_ptr sys_call_table[] = { sys_setup, sys_exit, sys_fork, sys_read,
sys_write, sys_open, sys_close, sys_waitpid, sys_creat, sys_link,
sys_unlink, sys_execve, sys_chdir, sys_time, sys_mknod, sys_chmod,
sys_chown, sys_break, sys_stat, sys_lseek, sys_getpid, sys_mount,
sys_umount, sys_setuid, sys_getuid, sys_stime, sys_ptrace, sys_alarm,
sys_fstat, sys_pause, sys_utime, sys_stty, sys_gtty, sys_access,
sys_nice, sys_ftime, sys_sync, sys_kill, sys_rename, sys_mkdir,
sys_rmdir, sys_dup, sys_pipe, sys_times, sys_prof, sys_brk, sys_setgid,
sys_getgid, sys_signal, sys_geteuid, sys_getegid, sys_acct, sys_phys,
sys_lock, sys_ioctl, sys_fcntl, sys_mpx, sys_setpgid, sys_ulimit,
sys_uname, sys_umask, sys_chroot, sys_ustat, sys_dup2, sys_getppid,
sys_getpgrp, sys_setsid, sys_sigaction, sys_sgetmask, sys_ssetmask,
sys_setreuid, sys_setregid
};
所以我们就定位到 sys_read 函数,这个函数在 linux 内核源码的 read_write.c 文件中。
int sys_read (unsigned int fd, char *buf, int count)
{
...
if (S_ISCHR (inode->i_mode))
return rw_char (...);
if (S_ISBLK (inode->i_mode))
return block_read (...);
...
}
我们读取的是标准输入,属于字符型文件,走第一个分支。
之后,要经过非常非常多的调用栈,我感觉是 linux 当中最繁琐的历程了,这个过程在我脑子里还是一片浆糊。具体可以看飞哥的《read一个字节实际发生了什么》,一行一行源码给你分析清楚,不过是以读取磁盘为例,和这个读取终端设备一样也要经历文件系统的层层折磨。
由于我们只想知道阻塞的本质,所以,忽略中间这一大坨。
跟到最后,发现一句关键代码,让我提起了精神。
if (EMPTY (tty->secondary)) {
sleep_if_empty (&tty->secondary);
}
再往里跟
static void sleep_if_empty (struct tty_queue *queue) {
// 关中断
cli ();
// 只要队列为空
while (EMPTY (*queue))
// 可中断睡眠
interruptible_sleep_on (&queue->proc_list);
// 开中断
sti ();
}
继续往里跟
// 将当前任务置为可中断的等待状态
void interruptible_sleep_on (struct task_struct **p) {
...
current->state = TASK_INTERRUPTIBLE;
schedule ();
...
}
OK,整个流程简单描述就是,只要用户不输入,字符队列就为空,此时将调用一个 interruptible_sleep_on 函数,将线程状态变为可中断的等待状态,同时调用 schedule() 函数,强制进行一次进程调度。
从进程调度看阻塞的本质
关于进程是怎么调度的,可以看《上帝视角看进程调度》。
我这里简单挑出重点,说明一下 schedule 也就是进程调度的过程,以 linux-0.11 为例。
很简答,这个函数就做了三件事:
我们只看第一条就好了,进程调度机制在选择下一个要调度的进程时,会跳过不是 RUNNABLE 状态的进程。
而我们刚刚将当前任务设置为 TASK_INTERRUPTIBLE,就是告诉进程调度算法,下次不要调度我,相当于放弃了 CPU 的执行权,相当于将当前进程挂起。
而底层的这一个操作,直接导致上层看来,像是停在了那一行不走一样,就是这一行。
import java.util.Scanner;
public class Zuse {
public static void main(String[] args) {
Scanner scanner = new Scanner(System.in);
String line = scanner.nextLine();
System.out.println(line);
}
}
这就是阻塞的本质。
再看唤醒的本质就简单了
有阻塞就有唤醒,当我们按下键盘时,会触发键盘中断,会进入键盘中断处理函数,keyboard_interrupt。
这个函数是提前注册在中断向量表里的。
再次经过九曲十八弯的跟踪后,发现这样一句代码。
wake_up(&tty->secondary.proc_list);
跟进去。
void wake_up(struct task_struct **p)
{
if (p && *p) {
(**p).state = TASK_RUNNABLE;
*p = NULL;
}
}
一目了然,将进程的状态改为 RUNNABLE,一会进程调度时,就可以参与了。
这就是阻塞后,唤醒的本质。
总结
所以,Java 代码中的一行 readline 会导致阻塞,实际上就是运行到了这段代码。
interruptible_sleep_on (&tty->secondary->proc_list);
而键盘输入后会将其唤醒,实际上就是运行到了这段代码。
wake_up(&tty->secondary.proc_list);
这两段代码里,其实就是通过改写 state 值去玩的,剩下的交给调度算法。
// 阻塞
current->state = TASK_INTERRUPTIBLE;
// 唤醒
(**p).state = TASK_RUNNABLE;
所以开篇两个问题,你可以回答了么?
这个函数是阻塞的么?
public void function() {
while(true){}
}
这个函数是阻塞的么?
public void function() {
Thread.sleep(2000);
}
答案都是否定的,因为这两个都没有让出 CPU 资源。(笔误,sleep是让出CPU资源的)
而阻塞的本质,是将进程挂起,不再参与进程调度。
而挂起的本质,其实就是将进程的 state 赋值为非 RUNNABLE,这样调度机制的代码中,就不会把它作为下一个获得 CPU 运行机会的可选项了。
怎么样,阻塞这个妖魔,除了么?
同时,欢迎大家提供更多的魔法词汇,让我来扒开他们的外衣!