preemptone仅标记goroutine可抢占并发送sigurg信号，是否真正中断取决于m是否运行在安全点；常见失效场景包括mallocgc临界区、nosplit函数、纯寄存器循环及windows平台。
runtime.preemptone 不是“让 goroutine 立刻停住”的指令，它只是标记 + 尝试发信号；真正能否打断，取决于当前 m 是否在可安全中断的位置。
preemptone 调用后为什么 goroutine 还在跑
-
preemptone只做两件事：设置g.preempt = true，再调用preemptM向绑定的 M 发SIGURG - 信号是否送达、是否被处理、是否跳转到
asyncPreempt，全看当时执行流是否落在「安全点」 - 常见失效场景：
- goroutine 正在
runtime.mallocgc栈扫描阶段（临界区屏蔽信号） - 执行
//go:nosplit函数，如memclrNoHeapPointers，无栈检查、无信号入口 - 纯寄存器循环（如
for x := 0; ; x++）被优化成单条incq %rax，中间无桩代码可插 - Windows 平台默认不启用
asyncpreempt，SIGURG语义不存在
- goroutine 正在
asyncPreempt 安全点到底在哪
安全点不是编译器“随机选的”，而是由编译器在特定指令模式后插入桩（asyncPreempt 入口），仅以下位置有效：
- 函数调用返回后（ret 指令之后）
- 条件分支跳转后（je/jne/jg 等之后）
- 内存读写指令后（movq、lea、call 等含内存操作数的指令）
- 非内联函数入口（含栈扩张检查逻辑）
但注意：
-
atomic.AddInt64(&x, 1)在 amd64 上常被内联为单条xaddq，不触发安全点 -
for { i++ }若变量全程在寄存器、无内存访问、无分支，就根本没有安全点可落
sysmon.retake 和抢占的关系容易混淆
retake 是 sysmon 的核心调度干预函数，但它干的不是同一件事：
- 对
_Prunning状态的 P：检测运行 ≥10ms → 调preemptone→ 尝试发信号 - 对
_Psyscall状态的 P：检测系统调用 ≥20ms → 标记需抢占，但实际切换发生在exitsyscall返回用户态瞬间 - 关键区别：
retake本身不切换 goroutine，它只设标记或发信号；调度动作永远延迟到下一个安全点或系统调用出口
所以看到 trace 里某个 G 在 syscall 中“挂”了 5s，别以为它被切走了 500 次——它只在返回那一刻被调度出去一次。
真正难调试的，是那些既没函数调用、又没内存访问、还被编译器优化掉所有分支的 tight loop。这种代码在 asyncpreempt 下依然可能霸占 P，而 runtime.Gosched() 是唯一能稳稳让它让出的手段——前提是，你得亲手加进去。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
