Cấp phát thủ công vs garbage collection — ai dọn rác

TL;DR: Trong C, mỗi malloc đi kèm một trách nhiệm: gọi free đúng chỗ đúng lúc. Quên free là memory leak; free hai lần là undefined behavior có thể sập process. Trong Java, Go, Python, runtime có một garbage collector (GC) tự tìm và thu hồi bộ nhớ "không còn ai truy cập được" — lập trình viên không cần gọi free, và cả lớp bug double-free/use-after-free biến mất. Chìa khoá là khái niệm reachability: object còn truy cập được từ root (biến trên stack, biến static) thì "sống"; không reachable là "rác" — GC thu. Tradeoff: thủ công cho chi phí runtime thấp và kiểm soát chính xác; GC cho an toàn và code đơn giản hơn, nhưng GC pause và overhead là cái giá phải trả.

Hai đồng nghiệp nhận cùng một task: viết hàm đọc file và trả về nội dung. Một người viết C, một người viết Java. Người viết C phải nghĩ thêm: bộ nhớ cấp phát cho buffer được giải phóng chưa, và giải phóng ở path nào nếu có nhiều điểm return? Người viết Java không cần nghĩ — runtime lo. Nhưng đổi lại, đôi khi chương trình Java dừng đột ngột vài chục millisecond để GC dọn dẹp. Ai dọn rác, và cái giá là gì?

1. Analogy — căn hộ tự dọn vs dịch vụ dọn phòng

Hình dung thuê căn hộ. Trong chế độ tự dọn (C), bạn mang đồ vào thì bạn phải tự mang ra — dịch vụ không can thiệp. Quên mang ra, đồ chất đống (memory leak). Mang cùng một thứ ra hai lần, nhân viên toà nhà nhầm và dọn nhầm phòng khác (double-free, undefined behavior). Trong chế độ dịch vụ dọn phòng (GC), nhân viên định kỳ đi qua, nhìn xem thứ gì không ai nhắc đến nữa rồi mang đi. Bạn không cần nhớ dọn — nhưng đôi khi nhân viên vào đúng lúc bạn đang làm việc (GC pause).

2. Cấp phát thủ công — C và trách nhiệm lập trình viên

Trong C, malloc(n) cấp phát n byte trên heap và trả về con trỏ. free(ptr) trả bộ nhớ đó về cho hệ thống. Hai lệnh này phải cân bằng: mỗi malloc đúng một free.

// Correct: cap phat va giai phong can bang
char *buf = malloc(256);
if (buf == NULL) return -1;   // kiem tra that bai
// ... dung buf ...
free(buf);
buf = NULL;                   // tranh dangling pointer

Bốn bug phổ biến khi quản lý thủ công sai:

Memory leak — quên free:

// SAI: leak -- buf khong bao gio duoc free neu early return
char *buf = malloc(256);
if (parse_header(buf) < 0) {
    return -1;                // ❌ SAI: buf bi leak o day
}
free(buf);

Mỗi lần hàm đi theo nhánh return -1, 256 byte bị mất. Trong server chạy lâu dài, leak nhỏ tích luỹ thành vấn đề nghiêm trọng.

Double-free — giải phóng hai lần:

free(buf);
// ... code khac ...
free(buf);   // ❌ SAI: undefined behavior, co the corrupt heap allocator

Heap allocator duy trì metadata về block đã cấp phát. free hai lần làm hỏng cấu trúc nội bộ đó, thường dẫn tới crash hoặc lỗ hổng bảo mật.

Use-after-free — dùng sau khi đã giải phóng:

free(buf);
printf("%s\n", buf);   // ❌ SAI: buf la dangling pointer -- gia tri khong xac dinh

Con trỏ buf vẫn giữ địa chỉ cũ, nhưng bộ nhớ đó đã được trả về heap allocator và có thể đã cấp phát cho mục đích khác. Đọc/ghi vào đó là undefined behavior.

Dangling pointer — con trỏ trỏ vào vùng không còn hợp lệ:

int *p;
{
    int x = 42;
    p = &x;
}                    // x het scope, giai phong tren stack
printf("%d\n", *p);  // ❌ SAI: p la dangling pointer

Ưu điểm của manual memory: không có overhead GC, lập trình viên kiểm soát chính xác khi nào và ở đâu bộ nhớ được giải phóng — quan trọng cho real-time system và embedded.

3. Garbage collection — runtime tự thu qua reachability

Garbage collector không theo dõi từng lần malloc/free. Thay vào đó, nó định nghĩa một tập root — tất cả object mà chương trình đang chạy chắc chắn còn cần:

• Biến cục bộ trên stack của tất cả thread đang chạy.
• Biến static và global.
• Thanh ghi CPU.

Từ root, GC trace (duyệt) toàn bộ đồ thị object theo các tham chiếu. Object nào truy cập được từ root (trực tiếp hoặc qua chuỗi tham chiếu) là reachable — còn sống. Object nào không truy cập được từ bất kỳ root nào là unreachable — rác, GC thu.

flowchart TD
  subgraph roots["Root set (stack + static)"]
    R1["bien list"]
    R2["bien config"]
  end
  R1 --> A["ArrayList"]
  A --> B["Node B (reachable)"]
  A --> C["Node C (reachable)"]
  B --> D["Node D (reachable)"]
  R2 --> E["Config (reachable)"]
  F["Node F (unreachable)"] -. "khong co root nao tro toi" .-> F
  G["Node G (unreachable)"] -. "khong co root nao tro toi" .-> G

  style F fill:#fee2e2,stroke:#ef4444
  style G fill:#fee2e2,stroke:#ef4444

Object F và G không có đường nào từ root tới — GC sẽ thu.

Code Java tương đương với ví dụ C ở trên — không cần free:

// Java: khong can free -- GC tu thu khi buf het scope
public int parseHeader(byte[] data) {
    byte[] buf = new byte[256];   // cap phat tren heap
    if (parse(buf, data) < 0) {
        return -1;                // OK: GC se thu buf sau khi het reachable
    }
    process(buf);
    return 0;
    // buf het scope -- unreachable -- GC se thu sau
}

Lập trình viên không cần nhớ free ở mỗi nhánh return. Khi buf ra khỏi scope (và không có tham chiếu nào khác giữ nó), GC sẽ thu.

Double-free và use-after-free không thể xảy ra trong Java vì GC chỉ thu object khi không còn tham chiếu nào — nếu bạn còn một biến giữ tham chiếu, object không bị thu; nếu object đã bị thu, bạn không còn tham chiếu hợp lệ nào tới nó.

4. Bảng tradeoff

5. Pitfall tổng hợp

❌ Pitfall 1 — Nghĩ GC nghĩa là khỏi lo bộ nhớ. GC thu object unreachable. Nếu bạn vô tình giữ tham chiếu tới object không còn cần — ví dụ một static list gom toàn bộ event, một cache không có giới hạn size — object đó reachable, GC không thu. Đây là logical leak: leak không phải vì quên free, mà vì giữ tham chiếu quá lâu. Chi tiết ở bài 03 — Vì sao vẫn rò bộ nhớ dù có GC.

❌ Pitfall 2 — Tưởng GC pause không đáng kể. Với Java Stop-The-World GC cũ, pause vài trăm millisecond xảy ra trong production là thực tế phổ biến. Hệ thống trading, game engine, real-time control — GC pause không chấp nhận được. Bài 02 — Ref-counting vs tracing GC giải thích vì sao pause xảy ra và cách giảm thiểu.

❌ Pitfall 3 — Nhầm manual memory trong C với "kiểm soát hoàn hảo". Manual memory đúng là cho kiểm soát, nhưng trả giá bằng bug tinh vi khó tìm. Use-after-free thường không crash ngay mà âm thầm đọc/ghi sai dữ liệu, chỉ phát hiện khi heap corrupt theo cách không liên quan. Công cụ như Valgrind, AddressSanitizer tồn tại chính vì lý do này.

6. Đào sâu (tuỳ chọn)

7. Liên hệ các bài khác

• Module 1 — Heap và cấp phát động: malloc lấy bộ nhớ từ heap; bài đó giải thích heap được tổ chức thế nào và tại sao cấp phát heap chậm hơn stack.
• Bài 02 — Ref-counting vs tracing GC: hai cơ chế GC cụ thể — cách runtime tìm object unreachable và thu hồi, với ưu nhược điểm từng cách.
• Bài 03 — Vì sao vẫn rò bộ nhớ dù có GC: GC không thu được object khi bạn còn giữ tham chiếu — nguyên nhân và cách chẩn đoán logical leak trong Java/Go/Python.

8. Tóm tắt

• Manual memory (C): lập trình viên gọi malloc/free; cân bằng không đúng → leak, double-free, use-after-free. Ưu: chi phí thấp, kiểm soát chính xác.
• Garbage collection: runtime tự thu object unreachable — không còn tham chiếu từ root nào. Ưu: loại bỏ cả lớp bug; nhược: GC pause, overhead CPU và bộ nhớ.
• Root set: biến trên stack, biến static/global, thanh ghi — điểm khởi đầu để GC trace reachability.
• Reachable = sống; unreachable = rác — GC không quan tâm bạn "muốn" giải phóng hay không, chỉ quan tâm còn tham chiếu hay không.
• GC không bảo vệ bạn khỏi logical leak — giữ tham chiếu không cần thiết thì object mãi reachable, mãi không bị thu.

9. Tự kiểm tra

Bài tiếp theo: Ref-counting vs tracing GC