降妖除魔 | 究竟什么是阻塞?
扫描二维码
随时随地手机看文章
问两个问题
阻塞,是我们程序员口中常常提到的词。
这个词,既熟悉,又陌生,熟悉到一提到它就倍感亲切,但一具体解释,就迷迷糊糊。这个函数是阻塞的么?
public void function() {
while(true){}
}
如果你说不出来,那你再看看这个函数是阻塞的么?public void function() {
Thread.sleep(2000);
}
为了搞清楚这个问题,我们就来一起追踪一下阻塞的本质,消灭阻塞这个魔法词汇。
从一段 Java 代码开始
写一段很简单的 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_。来到 linux 内核
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 (