1樓：馮東
題主說的情況基本不會遇到。現代作業系統雖然都是 preemptive multitask。但是 99.
99% 的情況下是乙個程序 voluntarily relinquish CPU。比如說，乙個程序讀 disk 的時候，控制權就交給 disk controller 了，這時程序就被掛起了，直到 disk controller 告訴作業系統任務完成，這個程序才會再參與到 schedule 中。
在 95% 以上的時間裡，系統裡的所有程序都是被掛起的：都在等待某個外圍裝置。現代作業系統中很少有程序發起全力計算兩分鐘以上的，對於 MBP 來說，這個時候風扇就已經開始高速了。
CPU 的使用率：CPU 是不存在「什麼都不做」的狀態的。當所有程序都掛起的時候，作業系統會執行核心裡的乙個零號程序。
這個程序占用 CPU 的百分比就是系統的 idle 率。在古老的 386 裡，這個零號程序就是空迴圈。後來有了高階電源管理，這個零號程序就是呼叫高階電源管理的功能讓 CPU 降頻等等，把發熱降下來。
2樓：pretty kernel
先簡單回答一下:
以linux來講, 不管個人桌面還是sever端, 都不太可能有100個以上的物理執行緒.
其次, linux的"時間片"預設是4ms.
如何保證每個程序的運作近似連續的？
沒辦法三言兩語說清楚, 簡單說就是每個執行緒輪流執行.
一般情況下如果乙個執行緒結束了，只需要分配CPU給下乙個就好了啊.
還有負載均衡的問題, 比較複雜.
不會存在中間什麼都不做的空狀態的吧，那佔用率應該是100%啊？
簡單說, 會的, 所以使用率不會一直是100%.
請參考 @馮東 的答案.
現在虛擬化技術很常見了, 這種情況下統計各任務cpu準確使用率比較複雜, 不細講.
任務排程其實重點就是計算優先順序（權重）的策略不同而已，優先順序的策略不同導致了時間片分配策略不同。os分配時間片時還要考慮虛擬化的因素。細節搜vruntime
資料結構linux核心cfs用rbtree實現優先佇列，rt排程用雙向鍊表。有些使用者態job scheduler也有用graph，其實基本就是實現優先佇列。軟實時硬實時啥的我就不扯了，自己google
排程策略就主動sleep/sche_yield，或者被動等kernel每次硬中斷時統一處理work queue（linux預設是4ms）。
切換時不同的task實現需要儲存的context（簡單理解為結構體）不同而已，比如linux的task_struct（內嵌thread_info標識執行緒），lua的lua_state，erlang的 process等等。
概念上, 程序比執行緒多了切換頁表的開銷.
userland task優點是沒有進出核心的切換開銷, 缺點是需要自行實現任務排程和context管理, 一般人都使用庫或者原生支援userland task的語言.
掃盲看看Schedule
作業系統執行緒排程為什麼沒有goroutine高效？
已登出 糾正乙個觀念 goroutine並不是執行緒，也不是乙個什麼 輕量級執行緒 它只是乙個函式，這個函式是跑在runtime中線程池上的。作業系統的執行緒切換上下文的開銷是不可避免的，本質上是因為CPU執行緒是有限的，而作業系統的執行緒不設上限。 我覺得這是相當好的乙個問題！我當時就是帶著這個問...
作業系統實時排程中的可排程判斷條件是怎麼得出來的？
sum T 這個我也糾結了一下，本人是東秦的小菜雞，看到了就隨便寫寫 先明確兩個定義 處理時間Ci和週期時間Pi 處理時間Ci 指的是乙個任務每次需要處理的時間長度，我們假設單位是ms。週期時間Pi 指的是HRT 硬實時任務 每次執行的間隔，我們也假設單位是ms。然後明確一下本算式使用情況 單處理機...
CPU 的執行緒與作業系統的執行緒有何關係？
力爭 軟執行緒是OS提供的，不對使用者透明 CPU是對使用者透明的。CPU裡面的執行緒本質上還是併發執行的，要想做到真正的並行，還要靠多核。他們都是排程基本單位，OS在中間層進行任務匹配。 已登出 cpu的執行緒對作業系統看來就是核心，而在cpu上是有乙個物理核心模擬出來的，所以是 邏輯核心 作業系...