降妖除魔 | 究竟什么是阻塞？
前言：很多詞匯，不論對(duì)科班生還是非科班生，如果不知道底層原理，就永遠(yuǎn)是一個(gè)魔法詞匯。這些魔法詞匯一多，就會(huì)導(dǎo)致暈頭轉(zhuǎn)向。所以開個(gè)新系列，降妖除魔，就是要斬殺這些如妖魔鬼怪般的魔法詞匯。
問(wèn)兩個(gè)問(wèn)題
阻塞，是我們程序員口中常常提到的詞。
這個(gè)詞，既熟悉，又陌生，熟悉到一提到它就倍感親切，但一具體解釋，就迷迷糊糊。
這個(gè)函數(shù)是阻塞的么？
public void function() {
while(true){}
}如果你說(shuō)不出來(lái)，那你再看看這個(gè)函數(shù)是阻塞的么？
public void function() {
Thread.sleep(2000);
}為了搞清楚這個(gè)問(wèn)題，我們就來(lái)一起追蹤一下阻塞的本質(zhì)，消滅阻塞這個(gè)魔法詞匯。
從一段 Java 代碼開始
寫一段很簡(jiǎn)單的 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);
}
}運(yùn)行這段代碼發(fā)現(xiàn)，程序?qū)?huì)"阻塞"在 scanner.nextLine() 這一行代碼，直到用戶輸入并且按下了回車鍵，程序才會(huì)繼續(xù)往下走，打印我們輸入的內(nèi)容，并且結(jié)束。
我們跟蹤一下這一行代碼的源碼，九曲十八彎之后，終于跟蹤到了一個(gè)不能再往下跟蹤的 native 代碼。
private native int readBytes(byte b[], int off, int len) throws IOException;當(dāng)然我們可以通過(guò) openJDK 源碼繼續(xù)查下去，但我有點(diǎn)懶，怕翻車，這里用另一個(gè)巧妙的辦法。
由于我們知道這個(gè)代碼一定最終會(huì)觸發(fā)一次 linux 的 IO 操作相關(guān)的系統(tǒng)調(diào)用，所以我們用 strace 命令直接將其找到。
strace -ff -e trace=desc java Zuse我們看到程序阻塞在了這里。
read(0,當(dāng)我們輸入一個(gè)字符串 "hello" 并按下回車后，這個(gè)系統(tǒng)調(diào)用函數(shù)被補(bǔ)全。
read(0, "hello\n", 8192)OK大功告成，觸發(fā) linux 的系統(tǒng)調(diào)用就是 read()
這樣，我們成功通過(guò) strace 命令，直接跨越到了 linux 內(nèi)核里，中間的調(diào)用過(guò)程，就不用瞎操心了。
來(lái)到 linux 內(nèi)核
linux 的系統(tǒng)調(diào)用會(huì)注冊(cè)到系統(tǒng)調(diào)用表（sys_call_table）中，通常是在前綴加一個(gè) 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 函數(shù)，這個(gè)函數(shù)在 linux 內(nèi)核源碼的 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 (...);
...
}我們讀取的是標(biāo)準(zhǔn)輸入，屬于字符型文件，走第一個(gè)分支。
之后，要經(jīng)過(guò)非常非常多的調(diào)用棧，我感覺(jué)是 linux 當(dāng)中最繁瑣的歷程了，這個(gè)過(guò)程在我腦子里還是一片漿糊。具體可以看飛哥的《read一個(gè)字節(jié)實(shí)際發(fā)生了什么》，一行一行源碼給你分析清楚，不過(guò)是以讀取磁盤為例，和這個(gè)讀取終端設(shè)備一樣也要經(jīng)歷文件系統(tǒng)的層層折磨。
由于我們只想知道阻塞的本質(zhì)，所以，忽略中間這一大坨。
跟到最后，發(fā)現(xiàn)一句關(guān)鍵代碼，讓我提起了精神。
if (EMPTY (tty->secondary)) {
sleep_if_empty (&tty->secondary);
}再往里跟
static void sleep_if_empty (struct tty_queue *queue) {
// 關(guān)中斷
cli ();
// 只要隊(duì)列為空
while (EMPTY (*queue))
// 可中斷睡眠
interruptible_sleep_on (&queue->proc_list);
// 開中斷
sti ();
}繼續(xù)往里跟
// 將當(dāng)前任務(wù)置為可中斷的等待狀態(tài)
void interruptible_sleep_on (struct task_struct **p) {
...
current->state = TASK_INTERRUPTIBLE;
schedule ();
...
}OK，整個(gè)流程簡(jiǎn)單描述就是，只要用戶不輸入，字符隊(duì)列就為空，此時(shí)將調(diào)用一個(gè) interruptible_sleep_on 函數(shù)，將線程狀態(tài)變?yōu)?/span>可中斷的等待狀態(tài)，同時(shí)調(diào)用 schedule() 函數(shù)，強(qiáng)制進(jìn)行一次進(jìn)程調(diào)度。
從進(jìn)程調(diào)度看阻塞的本質(zhì)
關(guān)于進(jìn)程是怎么調(diào)度的，可以看《上帝視角看進(jìn)程調(diào)度》。
我這里簡(jiǎn)單挑出重點(diǎn)，說(shuō)明一下 schedule 也就是進(jìn)程調(diào)度的過(guò)程，以 linux-0.11 為例。
很簡(jiǎn)答，這個(gè)函數(shù)就做了三件事：
我們只看第一條就好了，進(jìn)程調(diào)度機(jī)制在選擇下一個(gè)要調(diào)度的進(jìn)程時(shí)，會(huì)跳過(guò)不是 RUNNABLE 狀態(tài)的進(jìn)程。
而我們剛剛將當(dāng)前任務(wù)設(shè)置為 TASK_INTERRUPTIBLE，就是告訴進(jìn)程調(diào)度算法，下次不要調(diào)度我，相當(dāng)于放棄了 CPU 的執(zhí)行權(quán)，相當(dāng)于將當(dāng)前進(jìn)程掛起。
而底層的這一個(gè)操作，直接導(dǎo)致上層看來(lái)，像是停在了那一行不走一樣，就是這一行。
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);
}
}
這就是阻塞的本質(zhì)。
再看喚醒的本質(zhì)就簡(jiǎn)單了
有阻塞就有喚醒，當(dāng)我們按下鍵盤時(shí)，會(huì)觸發(fā)鍵盤中斷，會(huì)進(jìn)入鍵盤中斷處理函數(shù)，keyboard_interrupt。
這個(gè)函數(shù)是提前注冊(cè)在中斷向量表里的。
再次經(jīng)過(guò)九曲十八彎的跟蹤后，發(fā)現(xiàn)這樣一句代碼。
wake_up(&tty->secondary.proc_list);跟進(jìn)去。
void wake_up(struct task_struct **p)
{
if (p && *p) {
(**p).state = TASK_RUNNABLE;
*p = NULL;
}
}一目了然，將進(jìn)程的狀態(tài)改為 RUNNABLE，一會(huì)進(jìn)程調(diào)度時(shí)，就可以參與了。
這就是阻塞后，喚醒的本質(zhì)。
總結(jié)
所以，Java 代碼中的一行 readline 會(huì)導(dǎo)致阻塞，實(shí)際上就是運(yùn)行到了這段代碼。
interruptible_sleep_on (&tty->secondary->proc_list);而鍵盤輸入后會(huì)將其喚醒，實(shí)際上就是運(yùn)行到了這段代碼。
wake_up(&tty->secondary.proc_list);這兩段代碼里，其實(shí)就是通過(guò)改寫 state 值去玩的，剩下的交給調(diào)度算法。
// 阻塞
current->state = TASK_INTERRUPTIBLE;
// 喚醒
(**p).state = TASK_RUNNABLE;
所以開篇兩個(gè)問(wèn)題，你可以回答了么？
這個(gè)函數(shù)是阻塞的么？
public void function() {
while(true){}
}這個(gè)函數(shù)是阻塞的么？
public void function() {
Thread.sleep(2000);
}答案都是否定的，因?yàn)檫@兩個(gè)都沒(méi)有讓出 CPU 資源。（筆誤，sleep是讓出CPU資源的）
而阻塞的本質(zhì)，是將進(jìn)程掛起，不再參與進(jìn)程調(diào)度。
而掛起的本質(zhì)，其實(shí)就是將進(jìn)程的 state 賦值為非 RUNNABLE，這樣調(diào)度機(jī)制的代碼中，就不會(huì)把它作為下一個(gè)獲得 CPU 運(yùn)行機(jī)會(huì)的可選項(xiàng)了。
怎么樣，阻塞這個(gè)妖魔，除了么？
同時(shí)，歡迎大家提供更多的魔法詞匯，讓我來(lái)扒開他們的外衣！