Goroutine chạy ở đâu? Go dùng mô hình GMP — G (goroutine) ghép lên M (OS thread) qua P (processor). Bài này đo thật: 100.001 goroutine chạy trên chỉ 5 thread qua 10 processor, và vì sao đó là lý do Go tạo goroutine gần như miễn phí. Go 1.23.
Sysmon là thread nền không gắn P, chạy suốt vòng đời chương trình Go. Đo thật: GOMAXPROCS=1, một goroutine kẹt syscall 320ms mà goroutine khác vẫn đếm được 103 triệu lần — vì sysmon giành lại P. Và 40 syscall blocking đẻ ra 43 OS thread. Go 1.23.
Goroutine sinh ra với stack 2KB chứ không phải 8MB như OS thread. Đo thật: 100.000 goroutine chỉ 2051 bytes stack mỗi cái; khi đệ quy sâu, runtime cấp stack gấp đôi (tỉ lệ x2.00 chính xác) và copy toàn bộ khung — địa chỉ biến cục bộ nhảy vùng. Go 1.23.
Vì sao spawn hàng nghìn goroutine chạy mượt còn hàng nghìn OS thread thì nghẹt? Đo thật: ping-pong qua channel tốn 164 ns/vòng và 0 cấp phát, còn ping-pong qua pipe giữa hai OS thread tốn 21465 ns/vòng — đắt hơn 130 lần. Vì một cái ở user-space, cái kia qua kernel. Go 1.23.
Goroutine kẹt vĩnh viễn (chờ channel không ai gửi) không thoát và GC không dọn được — mỗi request rò một cái, số goroutine tăng mãi tới khi hết RAM. Đo thật trong Go: 1000 request rò 1000 goroutine (NumGoroutine 1→1001 không giảm), và pprof goroutine chỉ đúng chỗ kẹt tại một dòng code.
App treo, không log, không phản hồi — làm sao biết nó kẹt ở đâu? Nhiều runtime có 'cửa hậu' qua tín hiệu để tự in trạng thái. Bài này chạy thật: gửi SIGQUIT cho một chương trình Go bị treo, runtime in stack tất cả goroutine và chỉ đúng dòng code đang kẹt (chan receive ở hang.go:12); và SIGSEGV/panic tự in nơi crash.