当 GOMAXPROCS 已设为 2，程序仍因 for{} 空循环高占 CPU 并假死，根本原因是该循环不主动让出调度权，阻塞了 Go 运行时的协程调度与垃圾回收，需通过 runtime.Gosched() 显式让渡或彻底移除无意义忙等。
当 `gomaxprocs` 已设为 2，程序仍因 `for{}` 空循环高占 cpu 并假死，根本原因是该循环不主动让出调度权，阻塞了 go 运行时的协程调度与垃圾回收，需通过 `runtime.gosched()` 显式让渡或彻底移除无意义忙等。
在 Go 中，GOMAXPROCS 控制的是可并行执行用户 goroutine 的 OS 线程数（P 的数量），而非限制 CPU 使用率或强制调度。问题代码中的 forever() 函数是一个典型的无限空循环（busy loop）：
func forever() {
for {}
}它持续占用一个逻辑处理器（P），且不触发任何调度点（如系统调用、channel 操作、锁竞争或显式让渡），导致以下严重后果：
- ✅ 抢占失效：Go 1.14+ 虽引入异步抢占，但空循环仍可能长时间逃逸（尤其在低负载下）；
- ❌ GC 阻塞：运行时 GC 的“stop-the-world”阶段需所有 P 进入安全点，而该 goroutine 永不进入，造成 GC 卡死（可通过 GOGC=off 复现）；
- ❌ 其他 goroutine 饥饿：show() 和主 goroutine 依赖定时器唤醒，但若 forever 独占一个 P 且调度器无法切换，time.Sleep 的底层 timer goroutine 可能延迟响应，加剧 hang 表象；
- ⚠️ 资源浪费：单个 goroutine 持续 100% 占用一个核心，违背 Go “不要通过共享内存来通信”的并发哲学。
正确解法：避免空循环，或主动让渡
✅ 推荐方案：彻底移除无意义的 forever()
若仅用于保持程序运行，应由主 goroutine 承担：
func main() {
runtime.GOMAXPROCS(2)
go show()
// 移除 go forever()
select {} // 永久阻塞，零 CPU 开销
}⚠️ 临时修复（仅用于调试/学习）：插入调度点
若必须保留循环结构，需显式调用 runtime.Gosched() 让出当前 P，允许其他 goroutine 运行：
func forever() {
for {
runtime.Gosched() // 主动让渡控制权
}
}? 注意：Gosched() 不是睡眠，它仅将当前 goroutine 放入全局运行队列尾部，不保证立即执行——但它足以打破调度僵局，使 show() 和 GC 能正常工作。
补充说明与最佳实践
- time.Sleep(1000) 在原代码中单位是纳秒（非毫秒！），实际仅休眠 1 微秒，几乎等效于空循环。正确写法应为 time.Sleep(time.Millisecond)；
- Go 程序应优先使用 channel、timer、sync 包 等协作式同步机制，而非轮询或忙等待；
- 生产环境务必禁用 for{} 类型空循环；监控工具（如 pprof）可快速定位此类热点 goroutine。
总之，Go 的并发模型建立在协作调度基础上——每个 goroutine 应主动交出控制权，而非依赖强制抢占。理解并尊重这一设计哲学，是写出健壮 Go 程序的关键。
