進程調度， 一個調度器的自白

我是一個進程調度器。

個人職責是調度計算機內全部的進程，爲他們分配 CPU 資源。

1. 批處理時代

想當初，操做系統創造我時，只是打算讓我用 FCFS 調度算法，簡單維護下進程的秩序。但我後來的發展，遠遠超過了他的想象。

1.1 FCFS

所謂 FCFS 就是「先來先服務（First Come First Serve）」，每一個進程按進入內存的時間前後排成一隊。每當 CPU 上的進程運行完畢或者阻塞，我就會選擇隊伍最前面的進程，帶着他前往 CPU 執行。

就拿這幾個進程來講吧：

按照 FCFS 算法，我就會就按 A，B，C，D，E這樣的順序來將他們送往 CPU：

這一算法聽起來簡單又公平，然而好景不長，我收到了一個短進程的抱怨：」上次我前面排了一個長進程，等了足足 200 秒他才運行完。我只用 1 秒就運行結束了，就由於等他，我多花了這麼長時間，太不值得了。」

我仔細一想， FCFS 算法確實有這個缺陷——短進程的響應時間太長了，用戶交互體驗會變差。

因此我決定，更換調度算法。

1.2 SPN

此次我設計的算法叫作「短任務優先」（Shortest Process Next，SPN）。每次選擇預計處理時間最短的進程。所以，在排隊的時候，我會把短進程從隊列裏提到前面。

這一次，短進程獲得了很好的照顧，進程的平均響應時間大大下降，我和操做系統都很滿意。

但長進程們不幹了：那些短進程每天插隊，致使他們常常得不到 CPU 資源，形成了「飢餓」現象。

取消 SPN 算法的呼聲愈來愈高。

這但是個大問題。FCFS 雖然響應時間長，但最後全部進程必定有使用 CPU 資源的機會。但 SPN 算法就不同了，若是短進程源源不斷加入隊列，長進程們將永遠得不到執行的機會——太可怕了。

所以，短任務優先算法須要獲得改進。有什麼方法既能照顧短進程，又能照顧長進程呢？

1.3 HRRN

通過和操做系統的討論，咱們決定綜合考量進程的兩個屬性：等待時間和要求服務時間——等待時間長，要求服務時間短（就是短進程）的進程更容易被選中。

爲了量化，咱們制定了一個公式：響應比 = （等待時間+要求服務時間）/ 要求服務時間。響應比高的算法會先執行。咱們稱之爲「高響應比優先」（Highest Response Ratio Next，HRRN）。

這個算法獲得了長短進程的一致好評。雖然個人工做量增長了（每次調度前，我都要從新計算全部等待進程的響應比）但爲了進程們的公平性，這一切都是值得的。

2. 併發時代

新時代到了。

隨着計算機的普及，我的用戶大量增加，併發，即一次運行多個程序的需求出現了。這可難倒我了——處理器只有一個，怎麼運行多個程序？

所幸 CPU 點醒了我：「我如今的運算速度既然這麼快，何不發揮這項長處，弄一個「僞並行」出來？「

「僞並行？什麼意思」

「就是看起來像並行，實際上仍是串行。每一個進程短期交替使用個人資源，但在人類看來，這些進程就像在「同時」運行。」

我恍然大悟。

2.1 RR

通過 CPU 的提醒，我很快制定出了新的調度算法——時間片輪轉算法（Round Robin，RR）。

在這個算法裏，每一個進程將輪流使用 CPU 資源，只不過在他們開始運行時，我會爲他們打開定時器，若是定時器到時間（或者執行阻塞操做），進程將被迫「下機」，切換至下一個進程。至於下一個進程的選擇嘛，直接用 FCFS 就行了。

新的算法必然會面臨新的問題，如今個人問題就是，時間片的長度怎麼設計？

直觀來看，時間片越短，固定時間裏可運行的進程就越多，可 CPU 說過，切換進程是要消耗他很多指令週期的，時間片太短會致使大量 CPU 資源浪費在切換上下文上。時間片過長，短交互指令響應會變慢。因此具體怎麼取，還得看交互時間大小（感受像沒說同樣，但至少給了個標準嘛）。

這一階段，個人工做量大大提高——之前十幾秒都不用切換一次程序，如今倒好，一秒鐘就得切換數十次。

2.2 VRR

時間片輪轉算法看起來十分公平——全部的進程時間片都是同樣的。但事實真是這樣嗎？

I/O 密集型進程不這麼認爲，他對我說：「調度器大哥，時間片輪轉沒有照顧到咱們這類進程啊！咱們常常在 CPU 沒呆到一半時間片，就遇到了阻塞操做，被你趕下去。並且咱們在阻塞隊列，每每要停留很長時間。等阻塞操做結束，咱們還得在就緒隊列排好長時間隊。那些處理器密集型進程，使用了大部分的處理器時間，致使咱們性能下降，響應時間跟不上」

考慮到這些進程的要求，我決定爲他們建立一個新的輔助隊列。阻塞解除的進程，將進入這個輔助隊列，進行進程調度時，優先選擇輔助隊列裏的進程。

這就是「虛擬輪轉法」（Virtual Round Robin，VRR）。

從後來實際性能結果來看，這種方法確實優於輪轉法。我頗爲自豪。

2.3 優先級調度

有一天，操做系統突然找到我，神神祕祕的說：「調度器啊，你是知道的，我要給整個系統提供服務，可最近用戶進程太多，致使個人服務進程有時候響應跟不上。我有點擔憂這會給系統穩定性形成影響。」

我一聽，這但是個大事，系統不穩定那還得了？調度算法得換！

既然要讓操做系統的服務獲得足夠的運行資源，那就，乾脆讓他們具備最高的 CPU 使用優先權吧。

優先級調度算法就此產生了。

我向你們作出了規定——每一個進程將被賦予一個優先級，本身根據本身的狀況肯定優先級數值，可是，用戶進程的優先級不許高於內核進程的優先級。

切換程序的時候，我會從優先級 1 的隊列裏選擇一個進程，若是優先級 1 隊列爲空，纔會選擇優先級 2 中的進程，以此類推。

固然，爲了保證低優先級進程不會飢餓，我會調高等待時間長的進程的優先級。

使用這個算法，我更忙碌了，不只須要大量切換進程，還須要動態調節優先級。可能這就是能力越大，責任越大吧。

不過我知道，正是由於個人存在，人類才能在計算機上運行多道程序——這令我感到自豪。

但願你在看完個人文章以後有所收穫。

感謝你的閱讀，咱們後會有期！

聲明：原創文章，未經受權，禁止轉載