当主 goroutine 进入空忙循环（如 `for {}`）时，go 调度器无法抢占执行权，导致其他 goroutine 永远得不到运行机会；解决方法是避免无限忙循环，改用阻塞式等待（如 `time.sleep` 或 `select{}`）。
在 Go 中，调度器是协作式（cooperative）而非抢占式（preemptive）的——它依赖 goroutine 主动让出控制权（例如调用 time.Sleep、runtime.Gosched()、系统调用、channel 操作或函数调用），才能切换到其他 goroutine。而 for {} 是一个纯计算型忙循环，不触发任何调度点，因此即使设置了 GOMAXPROCS > 1，甚至调用 runtime.LockOSThread()，也无法让后台 goroutine 执行。
以下代码正是典型陷阱：
package main
import (
"fmt"
"time"
"runtime"
)
func main() {
runtime.GOMAXPROCS(runtime.NumCPU() * 8) // ✅ 设置并发线程数（但无效于本例）
go func() {
for {
time.Sleep(1 * time.Second)
fmt.Println("From routine")
}
}()
for {} // ❌ 危险！完全阻塞调度器，后台 goroutine 永不执行
}该程序将无任何输出，且 CPU 占用率飙升至 100%，因为主线程持续占用唯一可调度的 M（machine），且不释放控制权。
✅ 正确做法：使用阻塞式等待
方案一：短暂休眠（适合调试/简单场景）
go func() {
for {
time.Sleep(1 * time.Second)
fmt.Println("From routine")
}
}()
time.Sleep(time.Millisecond) // 让出一次调度权，使 goroutine 启动
for {} // ⚠️ 仍不推荐，仅作对比✅ 可工作，但 for {} 依然浪费 CPU；仅用于理解调度机制。
方案二（推荐）：select {} —— 零开销永久阻塞
go func() {
for {
time.Sleep(1 * time.Second)
fmt.Println("From routine")
}
}()
select {} // ✅ 永久阻塞，不消耗 CPU，且允许调度器自由管理所有 goroutineselect {} 是 Go 中最惯用、最高效的“主协程挂起”方式。它不执行任何 case，直接进入阻塞状态，将 OS 线程交还给运行时，从而确保其他 goroutine 可被正常调度。
方案三：优雅等待（生产环境首选）
若需等待多个 goroutine 完成，应配合 sync.WaitGroup：
package main
import (
"fmt"
"sync"
"time"
)
func main() {
var wg sync.WaitGroup
wg.Add(1)
go func() {
defer wg.Done()
for i := 0; i < 3; i++ {
time.Sleep(1 * time.Second)
fmt.Println("From routine:", i)
}
}()
wg.Wait() // 等待 goroutine 自然结束
fmt.Println("All done.")
}注意事项
- GOMAXPROCS 控制的是可同时执行用户代码的操作系统线程数，并非 goroutine 数量上限，也不能绕过调度协作机制；
- LockOSThread() 会将当前 goroutine 绑定到某个 OS 线程，但若该 goroutine 不让出控制权，反而会加剧调度僵局；
- Go 1.14+ 已引入异步抢占（基于信号的栈扫描），但对纯 for {} 循环仍不保证立即抢占（尤其短时间运行），因此绝不应依赖抢占来修复忙循环。
总结
永远避免 for {} 这类无调度点的死循环。正确的主 goroutine 等待方式是：
? 调试时用 time.Sleep 触发调度；
? 长期运行用 select {}；
? 多任务协同用 sync.WaitGroup 或 context 控制生命周期。
这才是符合 Go 并发哲学的健壮实践。
