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

小灰灰 2022-10-10 14:53 50阅读 0赞

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

> > **问两个问题**

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

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

这个函数是阻塞的么？

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一个字节实际发生了什么》][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() 函数，强制进行一次**进程调度**。

> > **从进程调度看阻塞的本质**

关于进程是怎么调度的，可以看[《上帝视角看进程调度》][Link 1]。

我这里简单挑出重点，说明一下 schedule 也就是进程调度的过程，以 linux-0.11 为例。

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

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

![36b36c4091ecbdb33dda5efc89abff43.gif][]

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

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

我们只看第一条就好了，进程调度机制在选择下一个要调度的进程时，**会跳过不是 RUNNABLE 状态的进程**。

而我们刚刚将当前任务设置为 TASK\_INTERRUPTIBLE，就是告诉进程调度算法，下次不要调度我，相当于放弃了 CPU 的执行权，相当于**将当前进程挂起**。

而底层的这一个操作，直接导致上层看来，像是停在了那一行不走一样，就是这一行。

这就是阻塞的本质。

> > **再看唤醒的本质就简单了**

有阻塞就有唤醒，当我们按下键盘时，会触发**键盘中断**，会进入键盘中断处理函数，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，一会进程调度时，就可以参与了。

这就是阻塞后，唤醒的本质。

![e71f7faee20c3477fdffa47c7c29a133.png][]

**总结**

所以，Java 代码中的一行 readline 会导致**阻塞**，实际上就是运行到了这段代码。

interruptible_sleep_on (&tty->secondary->proc_list);

而键盘输入后会将其**唤醒**，实际上就是运行到了这段代码。

wake_up(&tty->secondary.proc_list);

这两段代码里，其实就是通过**改写 state 值**去玩的，剩下的交给**调度算法**。

// 阻塞
    current->state = TASK_INTERRUPTIBLE;
    // 唤醒
    (**p).state = TASK_RUNNABLE;

![701df6b685fcf0c035b78d0adba1497e.png][]

所以开篇两个问题，你可以回答了么？

这个函数是阻塞的么？

public void function() {
     while(true){}
    }

这个函数是阻塞的么？

public void function() {
     Thread.sleep(2000);
    }

答案都是否定的，因为这两个都没有让出 CPU 资源。（笔误，sleep是让出CPU资源的）

而阻塞的本质，是将进程挂起，不再参与进程调度。

而挂起的本质，其实就是将进程的 state 赋值为非 RUNNABLE，这样调度机制的代码中，就不会把它作为下一个获得 CPU 运行机会的可选项了。

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

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

[read]: http://mp.weixin.qq.com/s?__biz=MjM5Njg5NDgwNA%3D%3D&chksm=a6e3077991948e6f79b9a6a22f4a3305bced889d770cc8922ba7e68da2b3cd8c16f33b8fb3ed&idx=1&mid=2247484994&scene=21&sn=20c63d5f6e2be4fced5ab09a3047da93#wechat_redirect
[Link 1]: http://mp.weixin.qq.com/s?__biz=Mzk0MjE3NDE0Ng%3D%3D&chksm=c2c59726f5b21e308bfc32de09fe17ad5d0987b615220215bfdb96a33aae72f2baa8c30757cc&idx=1&mid=2247495051&scene=21&sn=34efbb3fa1fe89ad4529d2f2dbe22613#wechat_redirect
[36b36c4091ecbdb33dda5efc89abff43.gif]: /images/20221005/fa2b5cc9ab7a442e9e3010f784783056.png
[e71f7faee20c3477fdffa47c7c29a133.png]: /images/20221005/f8f820d1518942668fe4cb4c935efb5b.png
[701df6b685fcf0c035b78d0adba1497e.png]: /images/20221005/7714645f376a4594b2d2526e4d2eae99.png