go 1.14+ 的 for {} 不再完全卡死调度器，因引入基于 sigurg 信号的异步抢占机制，可在系统调用、gc 或定时器唤醒时强制调度，但对纯计算无函数调用、cgo、runtime 临界区等场景仍无效。
Go 1.14+ 的 for {} 死循环不会完全锁死调度器，但**仍可能饿死同 P 上其他 goroutine**——异步抢占不是实时中断，而是依赖信号与检查点的“尽力而为”机制。
为什么 for {} 在 Go 1.14+ 不再彻底卡死，但依然危险
Go 运行时在 1.14 引入基于 SIGURG 的异步抢占，让纯计算循环有机会被中断。但它不改变根本逻辑：抢占只在特定时机生效，而非像操作系统那样靠硬件时钟强制切出。
-
for {}本身无函数调用、无栈增长、无 GC 安全点 → 编译器无法插入协作式检查点 - 异步抢占默认每 10ms 尝试一次（由
forcePreemptNS = 10*1000*1000控制），且仅当目标 G 处于用户态、未屏蔽信号、未在 runtime 临界区时才可能送达 - 即使信号送达并触发
runtime.morestack，也只是把当前 G 标记为“可调度”，若本地运行队列（runq）为空，它大概率立刻被重新选中继续跑 - Linux/macOS 支持完整信号链路；Windows 因信号模型限制，
asyncpreempt效果显著弱化
runtime.Gosched() 和 runtime.osyield() 怎么选
手动让出仍是应对死循环最可靠的方式，但两者语义和开销不同，误用反而拖慢性能。
-
runtime.Gosched()：把当前 G 放回全局运行队列，让其他 G 有机会被调度；适合“计算密集但需保响应”的场景（如解析大 JSON 中间循环） -
runtime.osyield()：仅向 OS 提示当前线程可让出时间片，不参与 goroutine 调度；开销极低，但不保证其他 G 立即运行，仅适合自旋锁退避等微秒级等待 - 别在 tight loop 每轮都调
runtime.Gosched()——它有上下文切换成本；建议按迭代次数控制，例如每1024次调一次 - 若已用
//go:nosplit或处于lockOSThread()状态，runtime.Gosched()会静默失败（不 panic，但也不起效）
哪些死循环仍然完全逃逸抢占机制
以下模式下，Go 调度器几乎无法介入，for {} 行为等同于 Go 1.13 及以前：：
- 纯原子操作内联循环：
for { atomic.AddUint64(&x, 1) }—— 汇编指令无函数调用、无栈帧、无安全点 - CGO 调用期间：
for { C.some_busy_c_func() }—— Go 调度器交出全部控制权，直到 C 函数返回 - runtime 临界区内：
runtime.LockOSThread(); for {}—— 信号被屏蔽，抢占被禁用 - 显式关闭抢占：
GODEBUG=asyncpreemptoff=1环境变量下，所有异步抢占逻辑被绕过
如何验证你的死循环是否真被抢占
别靠“程序没卡住”来判断——那可能是碰巧触发了 GC、系统调用或定时器唤醒。要测就测调度行为本身：
- 开启调度追踪：
GODEBUG=schedtrace=1000，观察输出中gwait（等待中的 goroutine 数）是否稳定；若持续飙升，说明有 G 长期霸占 P - 配合
GODEBUG=scheddetail=1查看每个 P 的状态，确认是否存在长时间处于Prunning状态且schedtick几乎不更新的 P - 用
pprof抓取 CPU profile，若热点集中在某段无调用的纯循环内，且runtime.mcall/runtime.gopark调用极少，基本可判定抢占失效 - 注意：
select {}是阻塞语义，调度器会立即将 G 挂起，不属于“长时间运行”问题范畴，无需干预
真正棘手的从来不是 for {} 本身，而是那些看似无害、实则绕过所有安全点的内联原子操作或 CGO 调用——它们不会报错，也不会卡死整个进程，但会让局部 goroutine 彻底失去被调度的机会。
