降妖除魔 | 究竟什么是阻塞？

来源丨本文经授权转载自 低并发编程（ID：dibingfa）

作者丨闪电sun 

前言：很多词汇，不论对科班生还是非科班生，如果不知道底层原理，就永远是一个魔法词汇。这些魔法词汇一多，就会导致晕头转向。所以开个新系列，降妖除魔，就是要斩杀这些如妖魔鬼怪般的魔法词汇。

问两个问题

阻塞，是我们程序员口中常常提到的词。

这个词，既熟悉，又陌生，熟悉到一提到它就倍感亲切，但一具体解释，就迷迷糊糊。

这个函数是阻塞的么？

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 为例。

很简答，这个函数就做了三件事：

1. 拿到剩余时间片（counter的值）最大且在 runnable 状态（state = 0）的进程号 next。

2. 如果所有 runnable 进程时间片都为 0，则将所有进程（注意不仅仅是 runnable 的进程）的 counter 重新赋值（counter = counter/2 + priority），然后再次执行步骤 1。

3. 最后拿到了一个进程号 next，调用了 switch_to(next) 这个方法，就切换到了这个进程去执行了。

我们只看第一条就好了，进程调度机制在选择下一个要调度的进程时，会跳过不是 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 运行机会的可选项了。

怎么样，阻塞这个妖魔，除了么？

同时，欢迎大家提供更多的魔法词汇，让我来扒开他们的外衣！

点分享

点点赞

点在看