当go程序中存在无休止的空循环（如for{}）时，即使已通过gomaxprocs限制p数量，仍会抢占全部m资源、阻塞调度器和gc，造成程序假死与cpu飙高。根本解决方式是避免忙循环，或显式调用runtime.gosched()让出执行权。
当go程序中存在无休止的空循环（如for{}）时，即使已通过gomaxprocs限制p数量，仍会抢占全部m资源、阻塞调度器和gc，造成程序假死与cpu飙高。根本解决方式是避免忙循环，或显式调用runtime.gosched()让出执行权。
在Go并发模型中，GOMAXPROCS 控制的是可并行执行用户goroutine的逻辑处理器（P）数量，而非操作系统线程（M）总数。它影响的是调度器能同时运行多少个goroutine，但无法约束单个goroutine对底层OS线程的独占行为。
你提供的代码中，forever() 是一个典型的无限忙循环（busy loop）：
func forever() {
for {}
}
该函数一旦启动，就会持续占用一个OS线程（M），且不主动让出控制权。由于Go 1.4及更早版本采用协作式调度（cooperative scheduling），goroutine只有在发生以下情况时才会被调度器抢占：
- 系统调用（如time.Sleep, fmt.Println, net.Read等）；
- channel操作（发送/接收阻塞）；
- 显式调用runtime.Gosched()；
- 函数调用（部分版本中触发栈检查）。
而纯计算型空循环既不触发系统调用，也不含函数调用或channel操作，因此会长期霸占其绑定的M，导致：
- 其他goroutine（如show()）虽就绪，却因缺乏可用M而无法被调度；
- main中的主goroutine同样被阻塞在time.Sleep(1000)后等待唤醒，但调度器本身可能已被饿死；
- CPU使用率飙升（>100%），实为单核满载+上下文切换开销；
- Go 1.5+中更严重：可能阻塞垃圾回收（GC）的STW（Stop-The-World）阶段，进一步加剧不可响应性。
✅ 正确做法：消除无意义忙循环
最健壮的方案是彻底移除forever()——若需“保持程序运行”，应依赖主goroutine的阻塞逻辑（如select{}监听信号或sync.WaitGroup等待）：
func main() {
runtime.GOMAXPROCS(2)
go show()
// 等待用户中断或优雅退出，而非用忙循环维持
select {} // 永久阻塞，零CPU消耗
}
⚠️ 临时修复（仅用于调试/学习）：插入调度点
若必须保留循环结构，应在循环体内显式让出时间片：
func forever() {
for {
runtime.Gosched() // 主动让出M，允许其他goroutine运行
}
}
runtime.Gosched() 会将当前goroutine从运行状态移至就绪队列尾部，使调度器有机会选择其他goroutine执行，从而打破死锁局面。但请注意：这仍是低效设计，不应出现在生产代码中。
? 补充建议：
- 避免在goroutine中编写无暂停、无I/O、无channel、无函数调用的纯计算循环；
- 使用go tool trace或pprof分析goroutine阻塞与调度延迟；
- 升级到Go 1.14+可受益于异步抢占式调度（基于信号的栈扫描），缓解但不消除忙循环危害；
- 对需要周期性工作的场景，优先使用time.Ticker或time.AfterFunc替代轮询。
归根结底，Go的并发哲学是「通过通信共享内存」，而非「靠轮询抢夺资源」。尊重调度器机制，才能写出高效、稳定、可维护的并发程序。
