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

低并发编程

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

很简答,这个函数就做了三件事:

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 运行机会的可选项了。

怎么样,阻塞这个妖魔,除了么?

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

浏览 44
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报