Go程序因无限忙循环导致挂起：GOMAXPROCS设置无效的深层原因与修复方案

即使设置了runtime.GOMAXPROCS(2)，含无限空循环（for{}）的goroutine仍会抢占全部P资源、阻塞调度器与GC，造成程序假死和CPU飙高；根本解决方式是消除忙循环或显式让出执行权。

即使设置了runtime.GOMAXPROCS(2)，含无限空循环（for{}）的goroutine仍会抢占全部P资源、阻塞调度器与GC，造成程序假死和CPU飙高；根本解决方式是消除忙循环或显式让出执行权。

在Go并发模型中，GOMAXPROCS 仅限制可并行执行用户goroutine的操作系统线程数（即P的数量），而非限制goroutine的行为本身。问题代码中的 forever() 函数是一个典型的无限忙循环（busy loop）：

func forever() {
    for {
    }   // ❌ 无任何阻塞、无I/O、无函数调用、无调度点 → 永不主动让出CPU
}

该循环一旦被调度到某个P上，便会持续占用该P——因为Go的goroutine调度是协作式（cooperative） 的：运行中的goroutine必须主动触发调度点（如系统调用、channel操作、time.Sleep、runtime.Gosched() 等），调度器才有机会切换其他goroutine。而空for{}不包含任何此类操作，导致：

• 该P被长期独占，无法执行其他goroutine（包括show()和主goroutine）；
• Go运行时的关键后台任务（如垃圾回收的STW阶段、netpoll轮询、定时器管理）依赖空闲P执行，若所有P均被忙循环霸占，GC可能永久阻塞；
• 在多核机器上（如题中4核），即使GOMAXPROCS=2，两个P仍被forever完全锁死，show()虽已启动却始终得不到调度机会，程序“挂起”——表面看是卡住，实则是调度饥饿（scheduler starvation）。

✅ 正确修复方式不是增加GOMAXPROCS，而是打破忙循环的垄断：

方案一（推荐）：彻底移除无意义忙循环
若forever()仅为占位或测试，应直接删除；若需长期存活，改用阻塞等待：

func forever() {
    select {} // ✅ 永久阻塞且不消耗CPU，释放P给其他goroutine
}

方案二（临时调试）：插入调度让点
仅用于理解调度机制，不可用于生产环境：

func forever() {
    for {
        runtime.Gosched() // ✅ 主动让出P，允许其他goroutine运行
    }
}

⚠️ 注意：runtime.Gosched() 仅提示调度器“我可以被切换”，不保证立即让出；且频繁调用仍浪费CPU。它不能替代真正的异步等待。

验证效果：修复后运行，show()将正常逐行打印数字，CPU使用率回落至合理水平（select{}版本接近0%，Gosched版本略高但可控），程序响应恢复正常。

总结：Go的并发健壮性依赖于goroutine的“合作”。开发者须避免任何形式的无让渡循环——无论是空循环、密集计算未分片、还是未超时的死等。善用select{}、time.Sleep、channel通信等原语，让调度器真正发挥作用，才是编写高可用Go程序的核心原则。