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.
GC Go dừng toàn bộ chương trình ở đúng hai điểm mỗi chu kỳ để chuyển pha an toàn. Đo thật: STW chỉ vài chục tới vài trăm micro-giây, tăng nhẹ từ 39 us (100 goroutine) lên 161 us (100k) nhưng luôn dưới 1 ms kể cả nửa triệu goroutine. Vì sao vẫn cần STW và điều gì làm nó dài ra. Go 1.23.
Giảm áp lực GC không phải một mẹo mà là gộp nhiều kỹ thuật. Đo thật cùng tác vụ: tái dùng strings.Builder + Grow prealloc + tránh fmt.Sprintf boxing cắt cấp phát từ 2756 xuống 901 alloc mỗi lần, làm GC chạy 511 thay vì 2068 lần và nhanh 4.2 lần. Quy trình thực chiến đo-tìm-sửa-đo lại. Go 1.23.
pprof cho biết cấp phát ở hàm nào, dòng nào. Nhưng có hai góc nhìn khác hẳn: đo thật cùng một chương trình, inuse_space chỉ hàm giữ 47MB RAM còn alloc_space chỉ hàm churn 515MB — hai thủ phạm hoàn toàn khác. Chọn sai chỉ số là đuổi nhầm. Go 1.23.
Go có bộ thu gom rác nhưng vẫn rò bộ nhớ được — vì GC chỉ dọn thứ không ai giữ. Đo thật một rò goroutine: NumGoroutine tăng 1001 lên 5001, HeapInuse tăng 63 lên 316 MB đều đặn dù GC chạy mỗi vòng. Bốn mẫu rò kinh điển và ba cách phát hiện. Go 1.23.
SetFinalizer đăng ký hàm chạy khi object thành rác, nghe tiện để dọn tài nguyên nhưng đầy cạm bẫy. Đo thật: finalizer chỉ chạy sau GC (0 trước), bất đồng bộ (9998/10000), giữ object sống thêm một chu kỳ GC (19MB vs 0MB), và KHÔNG chạy nếu chương trình thoát trước GC. Go 1.23.