Runtime

一个 goroutine 崩了，为什么你的 recover 根本接不住？

你在 HTTP 服务最外层加了 recovery middleware，以为兜底已经做完。后来某个 handler 里随手起了一个 goroutine；它空指针了，整个进程还是退出。

这不是 middleware 没挂上，也不是 …

Go 为什么不怕 goroutine 死循环：抢占不是玄学，是一套停机协议

把 GOMAXPROCS 设成 1，再启动一个没有函数调用、没有 I/O、没有 sleep 的死循环。

按很多人对 goroutine 的理解，程序应该完了：唯一的 P 被这个 goroutine 一直占着，其他 goroutine 没机会 …

Go 调度器真正厉害的地方：线程卡住了，P 不能跟着陪葬

把 GOMAXPROCS 设成 1，再让一个 goroutine 卡在 syscall.Read 里。

按直觉，整个 Go 程序应该只剩一个执行名额。这个名额被卡住了，其他 goroutine 也该一起停。

但你真跑一下，会看到另一件事 …

Go 为什么不让 selectgo 做 O(1) 抽奖：case 越多，runtime 付出的账越多

很多人写 select，脑子里都有一个抽奖箱。

几个 case 往里一扔，runtime 随机摸一个。哪个 channel 先 ready，哪个就中；都没 ready，就看 default；没有 default，就等。

这个理解不能说全错， …

Go 为什么让 close(ch) 批量唤醒等待者，而不是只给 channel 关个门

线上最烦的 channel 问题，往往不是“发不出去”。

而是你以为自己在等一个值，结果等来的是零值；你以为 close(ch) 只是关门，结果它把一批阻塞的 goroutine 全部叫醒；你以为 nil channel 和 closed …

Go 为什么宁可让 chansend 卡住，也不让你误以为 ch <- v 发成功了

goroutine dump 里刷出一排 [chan send]，你知道它卡住了。

但更麻烦的问题是：它到底卡在哪？

是 channel 本身是 nil？是已经有人在等接收，只差一次交付？是 buffer 满了？还是它已经被 runtime …

Go GMP 里最容易背错的不是 G 和 M，而是 P

很多人聊 Go 调度器，开口就能背：G 是 goroutine，M 是 machine，P 是 processor。

背完以后，问题来了：为什么已经有 M 这个 OS 线程，还要多一个 P？

如果这个问题答不上来，GMP 其实还没真的理解。 …