FCFS（First come first serve）先來先服務算法：
簡單的排隊算法，維護一個隊列，后來的只能排在隊尾等待。
非搶占。
缺點：不夠智能，對於cpu密集型進程不友好，比如：一個只需要1ms運行時間的cpu密集型進程，但是之前有一個要讀5s的io密集型進程。那么即使那個cpu密集型進程只需要運行1ms，但是必須等待足足5s才能運行！
SJF（Shortest job first）最短作業優先：
這種算法假設我們可以預測每個進程需要運行的時間。比如有5個進程，分別運行時間是：1，3，2，5，1。
這個算法顧名思義，先取需要最短運行時間的進程來運行，所以執行順序就是：1，1，2，3，5。其實就是算法里的貪心法。
SJF調度是最優調度（貪心法），但問題是怎么預測運行時間呢？所以其實這個算法只能作為比較，無法真正實現。
非搶占。
SJF算法還有一個變種：最短剩余時間優先。是選擇剩余運行時間最少的進程來調度，所以這個算法是搶占的。
RR（Round robin）輪轉調度：
每個進程被分配一個時間片，一般為20~50ms。每個進程只能最多使用一個時間片的時間，如果沒用完時間片就運行完畢，那么可以直接調度下一個進程；如果用完了時間片還沒運行完畢，系統會把該進程重新放到隊尾。
時間片的選擇是有要求的，因為在切換進程的時候要進行上下文切換。如果上下文切換的時間不比一個時間片小多少，那輪轉調度的效率就會很差，因為我們花了太多時間在切換進程上。
由於系統會在一個時間片完成后主動切換下一個進程，所以RR調度算法是搶占的。
優先級調度：
考慮前面說過的RR調度，它對所有進程“一視同仁”。但實際中可不是這樣，人有三六九等，進程也分重要不重要。比如前台交互的進程就很重要，需要快點返回結果。如果是后台維護數據的進程，那等一會無所謂。
所以我們對每個進程加上一個優先級（一般是整數），對於高優先級的進程我們優先調度，優先級進程執行完后，再調度低優先級進程。像io密集型進程顯然我們應該設置較高的優先級，畢竟這類進程只需要占用一點點的cpu時間，之后工作就交給io硬件了。所以我們應當優先調度io密集型進程，這樣經過一點點運行時間，該io密集型進程就不再需要cpu了。所以cpu密集型進程的優先級應該比io密集型進程低。
但這樣有一個問題：如果我們不停地加入高優先級的進程（比如為2），但是之前我們有一個優先級為1的進程因為一直被高優先級進程搶占所以從來沒有運行過，這肯定不行阿。所以優先級不應該是固定的，比如我們可以將等待時間加入決定因素，隨着等待時間變長的，我們逐漸提高它的優先級，這樣隨着時間推遲，最終該進程會被執行。
將等待時間加入調度因素的優先級調度算法其實就是高響應比優先調度算法：根據“響應比=（進程執行時間+進程等待時間）/ 進程執行時間”這個公式得到的響應比來進行調度。高響應比優先算法在等待時間相同的情況下，作業執行的時間越短，響應比越高，滿足段任務優先，同時響應比會隨着等待時間增加而變大，優先級會提高，能夠避免飢餓現象。優點是兼顧長短作業，缺點是計算響應比開銷大，適用於批處理系統。
搶占的。
多級隊列調度：
該算法內部會實現多個調度隊列，隊列1每個進程可以運行1個時間片，隊列2每個進程可以運行2個，隊列3每個進程可以運行4個，隊列4每個進程可以運行8個，以此類推。
假設有n個隊列，那么前n-1個隊列都是FCFS調度，最后一個隊列是RR調度。
對於一個需要執行100個時間片的進程，先加入隊列1，運行1個時間片后放入隊列2。再運行2個時間片后放入隊列3。最終這個進程我們需要1+2+4+8+16+32+64，一共7次上下文切換。如果我們使用上面說的RR算法，需要整整100次！
對於不同隊列來說，高優先級的隊列如果有進程，那么優先清空高優先級的隊列，之后再情況次高優先級的隊列，以此類推。。
這種調度算法可以良好的兼顧長進程和短進程。
執行步驟：
搶占的。