Goroutine仅在明确阻塞点被Go runtime主动挂起，如系统调用、channel操作或主动抢占检查，而非OS强制抢占。
Goroutine 不会像线程那样被 OS 强制抢占，它的“挂起”完全由 Go runtime 主动触发，且只发生在明确的阻塞点上。
goroutine 在哪些函数调用里会被挂起
不是所有函数都会导致挂起，只有那些涉及同步、I/O 或调度让出的运行时函数才会。关键看它是否进入系统调用、等待 channel、或主动检查抢占点：
ch 或 <code>：无缓冲 channel 会直接挂起发送/接收方，直到配对操作出现；有缓冲 channel 仅在缓冲满/空时挂起-
runtime.Gosched()：显式让出当前 M，强制调度器选下一个 G -
sync.Mutex.Lock()在竞争激烈时可能触发休眠（底层调用semasleep），G 被挂起并移入 wait queue -
time.Sleep()、net.Conn.Read()、os.ReadFile()等：最终都落到 syscall 或网络轮询器（netpoller）上，G 会脱离 M，M 继续执行其他 G -
runtime.LockOSThread()后的阻塞调用不会挂起 G，而是阻塞整个 M —— 这是少数会让 P 空转的场景
为什么 goroutine 阻塞时 M 不会跟着卡死
因为 Go 的 GMP 模型设计了分离机制：G 阻塞 ≠ M 阻塞。当 G 进入系统调用或网络 I/O，runtime 会执行 Hand Off：
- 若该 M 是绑定到某个 P 的（即
m.p != nil），runtime 会先尝试将 P 转交给其他空闲 M；成功后，原 M 可以安全进入系统调用 - 若没有空闲 M，当前 M 会释放 P，然后阻塞；Sysmon 线程会在约 20ms 后检测到，并唤醒新 M 来接管这个 P
- 网络 I/O 更进一步：通过
epoll/kqueue注册事件，G 挂起后不占 M，等事件就绪再唤醒 G 并重新绑定 M
这意味着一个阻塞的 http.Get() 不会影响同一 P 上其他 G 的执行 —— 和 pthread 完全不同。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
goroutine 挂起后怎么被唤醒
唤醒不是靠“定时轮询”，而是依赖事件驱动和队列迁移：
- channel 操作：配对的 send/receive 会互相唤醒对方 G，从等待队列移到 P 的 local runq 或 global runq
- timer 触发：
time.AfterFunc()或select中的case ，由 timer goroutine 调用 <code>ready()唤醒目标 G - 系统调用返回：内核返回后，runtime 将 G 标记为 runnable，并尝试“偷”回一个 P（或加入 global runq）
- Sysmon 检测到长时间休眠的 G（如锁等待超 10ms），会强制将其从 wait queue 移出，避免饿死
注意：唤醒后的 G 不一定立刻执行，它得排队等 P 分配时间片 —— 所以 runtime.Gosched() 后也不保证下一个就是你。
容易被忽略的调度细节
很多面试者只答“channel、锁、sleep”，但真正区分水平的是这些边界情况：
-
for range ch在 channel 关闭后不会挂起，但若 channel 永不关闭且无人写入，它会一直阻塞在—— 这是 goroutine 泄漏常见源头 -
select中多个 case 都 ready 时，Go 会伪随机选择，不是 FIFO；如果default存在，则永远不会挂起 - GC 标记阶段会短暂 STW，所有 G 停摆，但这是全局暂停，不属于单个 G 的“挂起”行为
- goroutine 刚创建时被放进
_p_.runnext，大概率下一次就被调度 —— 这就是为什么循环中不传参的go func(){...}()总输出最后一个 i 值
