1樓：「已登出」
糾正乙個觀念：goroutine並不是執行緒，也不是乙個什麼「輕量級執行緒」，它只是乙個函式，這個函式是跑在runtime中線程池上的。作業系統的執行緒切換上下文的開銷是不可避免的，本質上是因為CPU執行緒是有限的，而作業系統的執行緒不設上限。
2樓：
我覺得這是相當好的乙個問題！我當時就是帶著這個問題去修的 Concurrent and Parallel Programming. 我認為這個問題是理解 go routine、其他 coroutine 以及各種非同步架構的關鍵。
回答問題：
棧大小不能自動擴容是因為有指標。擴容意味著所有棧上的資料位址要變，所以除非有辦法追蹤所有指向棧上的指標，棧的位址必須固定不動。當然理論上也可以用虛擬記憶體之類的黑魔法，如果真的有興趣可以自己寫個 RTOS 試試看。
最常見的可以追蹤只想棧的指標的方法是 GC，因此 go 和 .NET 這些環境都理論上支援。作業系統層面支援 GC 也是理論上可行的，微軟就幹過（Midori），有興趣的話也可以試試寫 RTOS，應該會非常有趣。
不管什麼方案 context switch 的次數都不會變少的，所以是做的事情太多。此外，「高效」不僅僅指計算量與響應上，也包括記憶體占用。如果你把 OS 執行緒的各種隔離統統拿掉，棧也只給 256KB，那 go routine 也就沒什麼優勢了。
當然，那樣做的話你的 OS 也會變得像乙個 RTOS。
不太明白。題主想問什麼時候 OS 需要 context switch 嗎？任何 syscall 的時候，大多數時候是 IO。
非阻塞 IO 的 syscall 一樣要 context switch.
3樓：
1.執行緒的棧大小為什麼不能動態擴容。
不知道，不懂 linux 大神為什麼這麼設計。
但是動態擴容有缺點，乙個是每次呼叫函式都要檢查容量，二是擴容還要老資料搬家，有複製開銷。嗯，他挺慢的。
2.上下文切換是次數太多，還是每次切換做的事太多。是否有優化空間？
做的事情太多。
3.作業系統能否只在遇到IO阻塞時切換(再增加乙個很長的超時）不可行，不公平。
曾經我們在指令碼語言vm裡加入了超時功能，但是使用者態很難控制精度，效能和精度是矛盾的。
現代作業系統的核心執行緒排程是什麼方式，和CPU使用率什麼關係？
馮東 題主說的情況基本不會遇到。現代作業系統雖然都是 preemptive multitask。但是 99.99 的情況下是乙個程序 voluntarily relinquish CPU。比如說，乙個程序讀 disk 的時候，控制權就交給 disk controller 了，這時程序就被掛起了，直到...
作業系統排程如何實現？
the gc 系統裡的程序可以理解為乙個鍊錶，每個節點都儲存了對應程序的資訊，然後定時器會定時觸發中斷，中斷處理程式會判斷當前程序的時間片是否用完，是否處於就緒狀態等等，然後找到乙個可執行的程序，切換上下文。細節挺多的。 用心閣 一般來說，多工有搶占式多工和協作式多工。前者就是到了乙個時間片，作業系...
CPU 的執行緒與作業系統的執行緒有何關係？
力爭 軟執行緒是OS提供的，不對使用者透明 CPU是對使用者透明的。CPU裡面的執行緒本質上還是併發執行的，要想做到真正的並行，還要靠多核。他們都是排程基本單位，OS在中間層進行任務匹配。 已登出 cpu的執行緒對作業系統看來就是核心，而在cpu上是有乙個物理核心模擬出來的，所以是 邏輯核心 作業系...