Go quản lý bộ nhớ và garbage collection như thế nào?

Question

Accepted Answer

Go **tự động quản lý bộ nhớ** với một garbage collector, giải phóng bạn khỏi việc cấp phát/giải phóng thủ công. GC của nó là một collector **mark-and-sweep concurrent, độ trễ thấp, non-generational** được thiết kế để giảm thiểu thời gian dừng (pause time) — một lý do then chốt khiến Go phù hợp với các dịch vụ nhạy cảm với độ trễ.

## Stack vs heap và escape analysis

```go
// trình biên dịch quyết định mỗi giá trị nằm ở đâu qua ESCAPE ANALYSIS
func noEscape() int {
    x := 42        // ở lại STACK — không escape, giải phóng khi hàm trả về (rẻ)
    return x
}
func escapes() *int {
    x := 42        // ESCAPE lên HEAP — con trỏ của nó sống lâu hơn hàm (do GC quản lý)
    return &x
}
```

Trình biên dịch của Go thực hiện **escape analysis** tại thời điểm biên dịch: các giá trị không sống lâu hơn hàm của chúng ở lại trên **stack** rẻ, được giải phóng tự động; các giá trị có tham chiếu escape thì lên **heap** (nơi GC quản lý chúng). Cấp phát trên stack về cơ bản là miễn phí, nên giảm thiểu việc escape lên heap giúp giảm công việc của GC.

## Garbage collector: mark-and-sweep concurrent

```text
Đặc điểm GC của Go:
  ✓ MARK-AND-SWEEP — đánh dấu các object có thể tới được (từ root), quét sạch phần còn lại
  ✓ CONCURRENT — chạy chủ yếu song song với chương trình của bạn (không stop-the-world)
  ✓ ĐỘ TRỄ THẤP — tối ưu cho pause ngắn (thường dưới mili-giây), không phải throughput
  ✓ NON-GENERATIONAL — khác JVM, đối xử đồng nhất với mọi object (đơn giản hơn)
```

Go cố tình ưu tiên **thời gian dừng thấp** hơn throughput thô — GC làm phần lớn công việc concurrent với chương trình của bạn, giữ các pause "stop-the-world" rất ngắn. Điều này khiến Go mạnh cho các server nhạy cảm với độ trễ.

## Tinh chỉnh GC

```bash
GOGC=100   # mặc định: kích hoạt GC khi heap tăng 100% kể từ lần collection trước
           # GOGC cao hơn → GC ít thường xuyên hơn (nhiều bộ nhớ, ít CPU)
           # GOGC thấp hơn → GC thường xuyên hơn (ít bộ nhớ, nhiều CPU)
GOMEMLIMIT=2GiB   # một giới hạn bộ nhớ mềm (Go 1.19+) — GC làm việc cật lực hơn khi gần nó
```

## Giảm áp lực GC (kỹ thuật hiệu năng)

```go
// 1. tái sử dụng object với sync.Pool để giảm cấp phát
var bufPool = sync.Pool{New: func() any { return new(bytes.Buffer) }}
buf := bufPool.Get().(*bytes.Buffer)
defer bufPool.Put(buf)

// 2. cấp phát trước slice với capacity đã biết (tránh tăng trưởng/realloc lặp lại)
data := make([]int, 0, 1000)

// 3. giảm thiểu escape lên heap; tránh con trỏ/cấp phát không cần thiết trong vòng lặp nóng
```

Ít cấp phát hơn = ít công việc GC hơn. `sync.Pool` (tái sử dụng object), cấp phát trước, và giảm thiểu escape là các cách chính để giảm áp lực GC trong các đường nóng (hot path).

## Rò rỉ bộ nhớ vẫn xảy ra

```text
GC chỉ giải phóng các object KHÔNG TỚI ĐƯỢC. Rò rỉ đến từ các THAM CHIẾU còn lưu lại:
  ✗ rò rỉ goroutine (một goroutine bị chặn giữ cho bộ nhớ nó tham chiếu còn sống)
  ✗ map/slice toàn cục tăng trưởng, tài nguyên chưa đóng, các subscription bị quên
```

## Tại sao điều này quan trọng

Quản lý bộ nhớ tự động của Go là một thắng lợi lớn về năng suất và an toàn (không free thủ công, không dangling pointer), nhưng hiểu *cách* nó hoạt động có giá trị cho các ứng dụng quan trọng về hiệu năng và nhạy cảm với độ trễ — vốn là thứ Go thường được chọn để làm.

Các điểm chính: **escape analysis** quyết định cấp phát stack vs heap (stack miễn phí; giảm thiểu escape lên heap giảm công việc GC), và **GC concurrent, độ trễ thấp** của Go ưu tiên pause ngắn hơn throughput (lý tưởng cho server, khác với các collector tập trung vào throughput).

Biết cách giảm áp lực GC (`sync.Pool`, cấp phát trước, ít cấp phát trong vòng lặp nóng), tinh chỉnh nó (`GOGC`, `GOMEMLIMIT`), và nhận ra rằng **rò rỉ vẫn xảy ra** từ các tham chiếu còn lưu lại (đặc biệt là rò rỉ goroutine) là quan trọng để vận hành các dịch vụ Go hiệu năng cao.

Đây là kiến thức sâu, thực tế giúp phân biệt các lập trình viên Go senior và là một chủ đề phỏng vấn nâng cao phổ biến cho các vai trò nhạy cảm về hiệu năng.