前言：很多詞匯，不論對科班生還是非科班生，如果不知道底層原理，就永遠是一個魔法詞匯。這些魔法詞匯一多，就會導致暈頭轉向。所以開個新系列，降妖除魔，就是要斬殺這些如妖魔鬼怪般的魔法詞匯。

問兩個問題

阻塞，是我們程序員口中常常提到的詞。

這個詞，既熟悉，又陌生，熟悉到一提到它就倍感親切，但一具體解釋，就迷迷糊糊。

這個函數是阻塞的么？

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）;

}

}

運行這段代碼發(fā)現，程序將會“阻塞”在 scanner.nextLine（） 這一行代碼，直到用戶輸入并且按下了回車鍵，程序才會繼續(xù)往下走，打印我們輸入的內容，并且結束。

我們跟蹤一下這一行代碼的源碼，九曲十八彎之后，終于跟蹤到了一個不能再往下跟蹤的 native 代碼。

private native int readBytes（byte b［］， int off， int len） throws IOException;

當然我們可以通過 openJDK 源碼繼續(xù)查下去，但我有點懶，怕翻車，這里用另一個巧妙的辦法。

由于我們知道這個代碼一定最終會觸發(fā)一次 linux 的 IO 操作相關的系統(tǒng)調用，所以我們用 strace 命令直接將其找到。

strace -ff -e trace=desc java Zuse

我們看到程序阻塞在了這里。

read（0，

當我們輸入一個字符串 “hello” 并按下回車后，這個系統(tǒng)調用函數被補全。

read（0， “hello

”， 8192）

OK大功告成，觸發(fā) linux 的系統(tǒng)調用就是 read（）

這樣，我們成功通過 strace 命令，直接跨越到了 linux 內核里，中間的調用過程，就不用瞎操心了。

來到 linux 內核

linux 的系統(tǒng)調用會注冊到系統(tǒng)調用表（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一個字節(jié)實際發(fā)生了什么》，一行一行源碼給你分析清楚，不過是以讀取磁盤為例，和這個讀取終端設備一樣也要經歷文件系統(tǒng)的層層折磨。

由于我們只想知道阻塞的本質，所以，忽略中間這一大坨。

跟到最后，發(fā)現一句關鍵代碼，讓我提起了精神。

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 （）;

}

繼續(xù)往里跟

// 將當前任務置為可中斷的等待狀態(tài)void interruptible_sleep_on （struct task_struct **p） {

。。。

current-》state = TASK_INTERRUPTIBLE;

schedule （）;

。。。

}

OK，整個流程簡單描述就是，只要用戶不輸入，字符隊列就為空，此時將調用一個 interruptible_sleep_on 函數，將線程狀態(tài)變?yōu)榭芍袛嗟牡却隣顟B(tài)，同時調用 schedule（） 函數，強制進行一次進程調度。

從進程調度看阻塞的本質

關于進程是怎么調度的，可以看《上帝視角看進程調度》。

我這里簡單挑出重點，說明一下 schedule 也就是進程調度的過程，以 linux-0.11 為例。

很簡答，這個函數就做了三件事：

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

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

我們只看第一條就好了，進程調度機制在選擇下一個要調度的進程時，會跳過不是 RUNNABLE 狀態(tài)的進程。

而我們剛剛將當前任務設置為 TASK_INTERRUPTIBLE，就是告訴進程調度算法，下次不要調度我，相當于放棄了 CPU 的執(zhí)行權，相當于將當前進程掛起。

而底層的這一個操作，直接導致上層看來，像是停在了那一行不走一樣，就是這一行。

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）;

}

}

這就是阻塞的本質。

再看喚醒的本質就簡單了

有阻塞就有喚醒，當我們按下鍵盤時，會觸發(fā)鍵盤中斷，會進入鍵盤中斷處理函數，keyboard_interrupt。

這個函數是提前注冊在中斷向量表里的。

再次經過九曲十八彎的跟蹤后，發(fā)現這樣一句代碼。

wake_up（&tty-》secondary.proc_list）;

跟進去。

void wake_up（struct task_struct **p）

{

if （p && *p） {

（**p）.state = TASK_RUNNABLE;

*p = NULL;

}

}

一目了然，將進程的狀態(tài)改為 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