名词解释：阻塞是什么意思？

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

问两个问题

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

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

这个函数是阻塞的么？

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

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

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

编辑：jq