Goroutine

🇬🇧 Read the English version of this article on tanhdev.com Answer-first: Quản lý đồng thời an toàn trong Go đòi hỏi các mẫu Goroutine Pool có giới hạn (bounded concurrency): errgroup cho tác vụ theo lô, semaphore có đệm cho I/O pipelines, và channel-based worker pools cho xử lý hàng đợi kèm backpressure, circuit breaking và graceful shutdown. Mọi kỹ sư Go cuối cùng đều viết cùng một sai lầm: một vòng lặp khởi chạy các goroutine vô điều kiện (unconditionally). Trong một bản demo với 10 mục, điều này hoạt động rất đẹp. Nhưng trong môi trường production (thực tế) với 50.000 sự kiện webhook đầu vào, nó sẽ sản sinh ra 50.000 goroutine cùng một lúc, làm cạn kiệt bộ nhớ và kích hoạt sát thủ diệt bộ nhớ (OOM killer). Kubernetes sẽ khởi động lại (restart) cái pod đó. Và rồi kỹ sư trực on-call nhận tiếng bíp gọi dậy lúc 3 giờ sáng. ...

🇬🇧 Read the English version of this article on tanhdev.com Answer-first: Rò rỉ Goroutine xảy ra khi goroutine bị block vĩnh viễn trên unbuffered channel, context thiếu hủy, hoặc HTTP body chưa đóng, dẫn đến giữ heap memory và gây sự cố Kubernetes OOM (exit code 137). Chẩn đoán bằng pprof goroutine profile, chặn đứng qua goleak trong CI và áp dụng Go 1.26 goroutine leak detection. Một pod Kubernetes đột ngột khởi động lại với mã thoát (exit code) 137. Biểu đồ giám sát bộ nhớ (memory metrics dashboard) hiển thị một mô hình bậc thang tăng dần đều đặn kéo dài suốt ba ngày. Không có bất kỳ log panic nào trong stdout, không có lỗi database, và không có mức tăng đột biến CPU bất thường nào. Chỉ là một cái chết êm đềm và từ từ do lỗi OOM (Out Of Memory). ...