前言:很多詞匯,不論對科班生還是非科班生,如果不知道底層原理,就永遠(yuǎn)是一個魔法詞匯。這些魔法詞匯一多,就會導(dǎo)致暈頭轉(zhuǎn)向。所以開個新系列,降妖除魔,就是要斬殺這些如妖魔鬼怪般的魔法詞匯。
問兩個問題
阻塞,是我們程序員口中常常提到的詞。
這個詞,既熟悉,又陌生,熟悉到一提到它就倍感親切,但一具體解釋,就迷迷糊糊。
這個函數(shù)是阻塞的么?
while(true){}
}
如果你說不出來,那你再看看這個函數(shù)是阻塞的么?
public void function() {
Thread.sleep(2000);
}
為了搞清楚這個問題,我們就來一起追蹤一下阻塞的本質(zhì),消滅阻塞這個魔法詞匯。
從一段 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ā)現(xiàn),程序?qū)白枞痹?scanner.nextLine() 這一行代碼,直到用戶輸入并且按下了回車鍵,程序才會繼續(xù)往下走,打印我們輸入的內(nèi)容,并且結(jié)束。
我們跟蹤一下這一行代碼的源碼,九曲十八彎之后,終于跟蹤到了一個不能再往下跟蹤的 native 代碼。
private native int readBytes(byte b[], int off, int len) throws IOException;
當(dāng)然我們可以通過 openJDK 源碼繼續(xù)查下去,但我有點懶,怕翻車,這里用另一個巧妙的辦法。
由于我們知道這個代碼一定最終會觸發(fā)一次 linux 的 IO 操作相關(guān)的系統(tǒng)調(diào)用,所以我們用 strace 命令直接將其找到。
strace -ff -e trace=desc java Zuse
我們看到程序阻塞在了這里。
read(0,
當(dāng)我們輸入一個字符串 “hello” 并按下回車后,這個系統(tǒng)調(diào)用函數(shù)被補全。
read(0, “hello
”, 8192)
OK大功告成,觸發(fā) linux 的系統(tǒng)調(diào)用就是 read()
這樣,我們成功通過 strace 命令,直接跨越到了 linux 內(nèi)核里,中間的調(diào)用過程,就不用瞎操心了。
來到 linux 內(nèi)核
linux 的系統(tǒng)調(diào)用會注冊到系統(tǒng)調(diào)用表(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 函數(shù),這個函數(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)輸入,屬于字符型文件,走第一個分支。
之后,要經(jīng)過非常非常多的調(diào)用棧,我感覺是 linux 當(dāng)中最繁瑣的歷程了,這個過程在我腦子里還是一片漿糊。具體可以看飛哥的《read一個字節(jié)實際發(fā)生了什么》,一行一行源碼給你分析清楚,不過是以讀取磁盤為例,和這個讀取終端設(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 ();
// 只要隊列為空
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,整個流程簡單描述就是,只要用戶不輸入,字符隊列就為空,此時將調(diào)用一個 interruptible_sleep_on 函數(shù),將線程狀態(tài)變?yōu)榭芍袛嗟牡却隣顟B(tài),同時調(diào)用 schedule() 函數(shù),強制進行一次進程調(diào)度。
從進程調(diào)度看阻塞的本質(zhì)
關(guān)于進程是怎么調(diào)度的,可以看《上帝視角看進程調(diào)度》。
我這里簡單挑出重點,說明一下 schedule 也就是進程調(diào)度的過程,以 linux-0.11 為例。
很簡答,這個函數(shù)就做了三件事:
1. 拿到剩余時間片(counter的值)最大且在 runnable 狀態(tài)(state = 0)的進程號 next。
2. 如果所有 runnable 進程時間片都為 0,則將所有進程(注意不僅僅是 runnable 的進程)的 counter 重新賦值(counter = counter/2 + priority),然后再次執(zhí)行步驟 1。3. 最后拿到了一個進程號 next,調(diào)用了 switch_to(next) 這個方法,就切換到了這個進程去執(zhí)行了。
我們只看第一條就好了,進程調(diào)度機制在選擇下一個要調(diào)度的進程時,會跳過不是 RUNNABLE 狀態(tài)的進程。
而我們剛剛將當(dāng)前任務(wù)設(shè)置為 TASK_INTERRUPTIBLE,就是告訴進程調(diào)度算法,下次不要調(diào)度我,相當(dāng)于放棄了 CPU 的執(zhí)行權(quán),相當(dāng)于將當(dāng)前進程掛起。
而底層的這一個操作,直接導(dǎo)致上層看來,像是停在了那一行不走一樣,就是這一行。
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ì)就簡單了
有阻塞就有喚醒,當(dāng)我們按下鍵盤時,會觸發(fā)鍵盤中斷,會進入鍵盤中斷處理函數(shù),keyboard_interrupt。
這個函數(shù)是提前注冊在中斷向量表里的。
再次經(jīng)過九曲十八彎的跟蹤后,發(fā)現(xiàn)這樣一句代碼。
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,一會進程調(diào)度時,就可以參與了。
這就是阻塞后,喚醒的本質(zhì)。
總結(jié)
所以,Java 代碼中的一行 readline 會導(dǎo)致阻塞,實際上就是運行到了這段代碼。
interruptible_sleep_on (&tty-》secondary-》proc_list);
而鍵盤輸入后會將其喚醒,實際上就是運行到了這段代碼。
wake_up(&tty-》secondary.proc_list);
這兩段代碼里,其實就是通過改寫 state 值去玩的,剩下的交給調(diào)度算法。
// 阻塞
current-》state = TASK_INTERRUPTIBLE;
// 喚醒
(**p).state = TASK_RUNNABLE;
所以開篇兩個問題,你可以回答了么?
這個函數(shù)是阻塞的么?
public void function() {
while(true){}
}
這個函數(shù)是阻塞的么?
public void function() {
Thread.sleep(2000);
}
答案都是否定的,因為這兩個都沒有讓出 CPU 資源。(筆誤,sleep是讓出CPU資源的)
而阻塞的本質(zhì),是將進程掛起,不再參與進程調(diào)度。
而掛起的本質(zhì),其實就是將進程的 state 賦值為非 RUNNABLE,這樣調(diào)度機制的代碼中,就不會把它作為下一個獲得 CPU 運行機會的可選項了。
怎么樣,阻塞這個妖魔,除了么?
編輯:jq
-
阻塞
+關(guān)注
關(guān)注
0文章
24瀏覽量
8073
原文標(biāo)題:究竟什么是阻塞?
文章出處:【微信號:gh_3980db2283cd,微信公眾號:開關(guān)電源芯片】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論