Stack vs heap vs static — chọn vùng nhớ nào

6:33Stack vs Heap — biến của bạn thực sự sống ở đâu? (và quy tắc chọn vùng nhớ)7 phút nắm ý chính · bài viết dưới đây là bản đầy đủ ~16 phút

TL;DR: Bộ nhớ của một tiến trình chia thành các vùng có vai trò khác nhau. Stack chứa biến cục bộ và frame lời gọi — nhanh, tự dọn theo frame, nhưng nhỏ và vòng đời ngắn. Heap chứa object cấp phát động — linh hoạt về kích thước và vòng đời, nhưng chậm hơn và cần quản lý (free thủ công hoặc GC). Static/global chứa biến toàn cục, hằng số, và code — cấp một lần lúc nạp chương trình, sống tới khi thoát. Chọn đúng vùng là một quyết định thiết kế: dữ liệu nhỏ, ngắn hạn → stack; dữ liệu lớn hoặc phải sống lâu hơn hàm → heap; hằng dùng chung toàn chương trình → static. Bài này đặt ba vùng cạnh nhau và rút ra quy tắc chọn.

Ba bài trước mổ xẻ stack và heap riêng lẻ. Bài này lắp chúng vào một bức tranh: toàn bộ không gian địa chỉ của một chương trình đang chạy, các vùng nằm đâu, và làm sao quyết định dữ liệu của bạn nên sống ở vùng nào.

1. Analogy — căn hộ ba khu

Hình dung một căn hộ với ba khu lưu đồ, mỗi khu một thói quen khác nhau:

• Phòng khách (static): bàn ghế, kệ tivi — đồ cố định, đặt một lần khi dọn vào, ai trong nhà cũng dùng chung, ở nguyên đó tới khi chuyển nhà.
• Ngăn kéo bàn (stack): bạn mở ngăn lấy bút dùng tạm, xong đẩy ngăn vào là gọn — đồ trong ngăn gắn với việc bạn đang làm, tự "biến mất" khỏi tầm mắt khi đóng ngăn. Nhanh, gọn, nhưng không để đồ lâu dài.
• Nhà kho (heap): chứa đồ lớn, đồ chưa biết khi nào cần — phải quản lý chìa khoá, tự sắp xếp, và nếu không dọn thì bừa bộn dần (đồ cũ chiếm chỗ).

Câu hỏi "để đồ ở đâu" trong nhà giống hệt câu hỏi "đặt dữ liệu vào vùng nào" trong chương trình: đồ dùng tạm theo việc → ngăn kéo (stack); đồ lớn hoặc sống lâu → nhà kho (heap); đồ cố định dùng chung → phòng khách (static).

2. Bản đồ bộ nhớ một tiến trình

Khi OS nạp chương trình, nó dựng một không gian địa chỉ với các vùng cố định:

Dia chi cao
  +-----------------------------+
  | Stack                       |  <- bien cuc bo, frame; lon xuong duoi
  |   |                         |
  |   v                         |
  |                             |
  |   ^                         |
  |   |                         |
  | Heap                        |  <- object dong; lon len tren
  +-----------------------------+
  | BSS / Data (static)         |  <- bien toan cuc, static
  +-----------------------------+
  | Text (code)                 |  <- lenh may, chi doc
  +-----------------------------+
Dia chi thap

• Text (code): lệnh máy của chương trình, chỉ đọc (OS đánh dấu vùng này không cho ghi, để một bug hay mã độc không thể ghi đè lệnh của chính chương trình). Một bản dùng chung cho mọi luồng.
• Data + BSS (static): biến toàn cục và static. Data chứa biến có giá trị khởi tạo; BSS chứa biến khởi tạo 0 (không tốn chỗ trong file thực thi).
• Heap: lớn dần lên trên khi cấp phát động.
• Stack: lớn dần xuống dưới khi gọi hàm. Stack và heap mọc về phía nhau — thiết kế này cho mỗi vùng dùng tối đa không gian còn lại.

Mỗi luồng có stack riêng; heap, static và code dùng chung giữa các luồng — đây là gốc của nhiều vấn đề đồng thời bạn sẽ gặp ở Course 3 (hai luồng cùng sửa một object trên heap).

Thử ngẫmhai luồng trong cùng tiến trình cùng gọi một hàm add(int x). Tham số x của luồng này có bị luồng kia nhìn thấy hay ghi đè không, và vì sao?

3. Ba vùng cạnh nhau

4. Một biến đi đâu — trace một hàm

Xét một đoạn Java và xem mỗi thứ sống ở vùng nào:

class Config {
    static final int MAX = 100;          // MAX: vung static (hang, dung chung)
}

int[] build(int n) {                     // n: tham so -> stack frame cua build
    int local = n * 2;                   // local: bien cuc bo -> stack
    int[] result = new int[local];       // bien 'result': tham chieu tren stack
                                         // mang int that su: tren HEAP
    return result;                       // tra ve tham chieu; mang song tiep tren heap
}

• Config.MAX nằm ở vùng static — cấp một lần, mọi nơi dùng chung, sống tới khi chương trình thoát.
• n và local nằm trên stack (trong frame của build) — sinh khi gọi build, chết khi build return.
• Biến result (một tham chiếu) cũng nằm trên stack, nhưng mảng int mà nó trỏ tới nằm trên heap.
• Khi build return, frame pop: n, local, và biến result biến mất — nhưng mảng trên heap vẫn sống vì nơi gọi nhận được tham chiếu và GC giữ nó chừng nào còn ai trỏ tới. Đây chính là lý do dữ liệu thoát khỏi hàm phải nằm trên heap (bài 02).

5. Ngôn ngữ quản lý các vùng này thế nào

Cùng một mô hình ba vùng, nhưng mỗi ngôn ngữ lộ ra khác nhau:

• C/C++: bạn kiểm soát trực tiếp. Biến cục bộ → stack; malloc/new → heap (bạn phải free/delete); biến static/global → static. Quyền lực tối đa, trách nhiệm tối đa (rò bộ nhớ nếu quên free).
• Java: primitive cục bộ và tham chiếu nằm trên stack; mọi object (new) nằm trên heap, GC dọn; static field nằm trong vùng metadata của class (gần static). Bạn không chọn stack hay heap cho object — JVM quyết (xem escape analysis bên dưới).
• Python: gần như mọi thứ là object trên heap, kể cả số nguyên; biến chỉ là tên trỏ tới object. Quản lý bằng ref-counting + GC. Stack chỉ giữ frame và tham chiếu.
• Go: bạn viết như thể mọi thứ trên stack, nhưng compiler chạy escape analysis — biến nào "thoát" khỏi hàm (bị trả về hoặc lưu ra ngoài) tự động chuyển lên heap; còn lại ở stack. Bạn không gọi free; GC dọn heap.

Thử ngẫmmột hàm Go tạo local := &Point{1,2} rồi return con trỏ đó. Escape analysis buộc local phải chuyển lên đâu, và ai chịu trách nhiệm dọn nó sau này?

6. Áp dụng vào code của bạn

Quy tắc quyết định vùng nhớ, theo thứ tự ưu tiên:

1. Dữ liệu nhỏ, chỉ dùng trong hàm → để cục bộ (stack). Biến tạm, bộ đếm, kết quả trung gian. Nhanh, tự dọn, không áp lực GC. Đây là mặc định tốt nhất khi đủ.

2. Dữ liệu phải sống lâu hơn hàm, hoặc kích thước không biết trước → heap. Object trả về từ hàm, collection lớn dần, cấu trúc dữ liệu chia sẻ. Trong Java/Go bạn không gọi gì đặc biệt — new/make là đủ, runtime lo phần còn lại.

3. Hằng số bất biến dùng toàn chương trình → static/constant. Bảng tra cứu, cấu hình chỉ-đọc, hằng. Cấp một lần, không lặp lại chi phí.

Cảnh giác với static mutable (trạng thái toàn cục). Một static field thay đổi được là trạng thái dùng chung giữa mọi luồng — gốc của race condition và bug khó tái hiện:

// NGUY HIEM: static mutable -> moi luong cung sua, race condition
public class Counter {
    static int count = 0;            // dung chung toan chuong trinh
    void inc() { count++; }          // khong an toan da luong
}

// AN TOAN HON: dong goi trang thai, hoac dung kieu atomic
public class Counter {
    private final AtomicInteger count = new AtomicInteger();
    void inc() { count.incrementAndGet(); }
}

Quy tắc: static nên là final (hằng) trong hầu hết trường hợp. static mutable chỉ dùng khi thật sự cần trạng thái toàn cục và phải bảo vệ đồng bộ cẩn thận.

Đừng ép object lên stack chỉ vì "nhanh hơn". Trong Java/Go bạn không chọn được, và escape analysis đã tự tối ưu các object cục bộ an toàn. Tập trung viết code rõ ràng; chỉ can thiệp khi profiler chỉ ra cấp phát/GC là bottleneck thật.

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

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

• Bài 02 — Stack và stack frame: chi tiết cơ chế vùng stack — frame, vòng đời, stack overflow.
• Bài 03 — Heap và cấp phát động: chi tiết cơ chế vùng heap — allocator, fragmentation, chi phí.
• Module 4 — Quản lý bộ nhớ ngôn ngữ bậc cao: ai giải phóng heap (bạn hay GC) và rò bộ nhớ phát sinh thế nào.
• Course 3 — Tiến trình & luồng: stack riêng mỗi luồng, heap/static dùng chung — gốc của race condition.

9. Tóm tắt

• Không gian địa chỉ một tiến trình gồm: text (code, chỉ đọc), static/data (toàn cục, hằng), heap (động, lớn lên), stack (frame, lớn xuống).
• Stack: nhanh, tự dọn theo frame, nhỏ, vòng đời ngắn, riêng mỗi luồng. Mặc định tốt cho dữ liệu cục bộ nhỏ.
• Heap: linh hoạt về kích thước và vòng đời, chậm hơn, cần free/GC, dùng chung giữa luồng. Cho dữ liệu sống lâu hơn hàm hoặc kích thước chưa biết.
• Static: cấp một lần, sống suốt đời chương trình, dùng chung. Tốt cho hằng; static mutable là trạng thái toàn cục nguy hiểm (race condition).
• Mỗi ngôn ngữ lộ ba vùng khác nhau; escape analysis (Java, Go) có thể dời object cục bộ không thoát từ heap về stack — thậm chí xoá hẳn bằng scalar replacement.
• Quy tắc chọn: nhỏ và ngắn hạn → stack; lớn hoặc sống lâu → heap; hằng dùng chung → static. Ưu tiên code rõ ràng, tối ưu vùng nhớ chỉ khi profiler yêu cầu.

10. Tự kiểm tra

Bài tiếp theo: Tổng kết Module 1