前言：很多詞匯，不論對(duì)科班生還是非科班生，如果不知道底層原理，就永遠(yuǎn)是一個(gè)魔法詞匯。這些魔法詞匯一多，就會(huì)導(dǎo)致暈頭轉(zhuǎn)向。所以開(kāi)個(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 代碼開(kāi)始

寫(xiě)一段很簡(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（） 這一行代碼，直到用戶輸入并且按下了回車(chē)鍵，程序才會(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)懶，怕翻車(chē)，這里用另一個(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” 并按下回車(chē)后，這個(gè)系統(tǒng)調(diào)用函數(shù)被補(bǔ)全。

read（0， “hello

”， 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ò)是以讀取磁盤(pán)為例，和這個(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）;

// 開(kāi)中斷

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)榭芍袛嗟牡却隣顟B(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ù)就做了三件事：

1. 拿到剩余時(shí)間片（counter的值）最大且在 runnable 狀態(tài)（state = 0）的進(jìn)程號(hào) next。

2. 如果所有 runnable 進(jìn)程時(shí)間片都為 0，則將所有進(jìn)程（注意不僅僅是 runnable 的進(jìn)程）的 counter 重新賦值（counter = counter/2 + priority），然后再次執(zhí)行步驟 1。3. 最后拿到了一個(gè)進(jìn)程號(hào) next，調(diào)用了 switch_to（next） 這個(gè)方法，就切換到了這個(gè)進(jìn)程去執(zhí)行了。

我們只看第一條就好了，進(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)我們按下鍵盤(pán)時(shí)，會(huì)觸發(fā)鍵盤(pán)中斷，會(huì)進(jìn)入鍵盤(pá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）;

而鍵盤(pán)輸入后會(huì)將其喚醒，實(shí)際上就是運(yùn)行到了這段代碼。

wake_up（&tty-》secondary.proc_list）;

這兩段代碼里，其實(shí)就是通過(guò)改寫(xiě) state 值去玩的，剩下的交給調(diào)度算法。

// 阻塞

current-》state = TASK_INTERRUPTIBLE;

// 喚醒

（**p）.state = TASK_RUNNABLE;

所以開(kāi)篇兩個(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è)妖魔，除了么？

編輯：jq