Bộ nhớ JVM chia thế nào, và GC thế hệ hoạt động ra sao?

Hai vùng survivor tồn tại để nén: minor GC sao chép object còn sống từ eden và survivor đang dùng sang survivor còn lại, rồi xoá sạch cả hai vùng nguồn cùng lúc. Vì thao tác là sao chép chứ không quét-và-xoá, chi phí tỉ lệ với lượng object CÒN SỐNG chứ không phải với lượng rác. Đó là lý do cấp phát nhiều object chết ngay gần như miễn phí trong JVM — điều nghe rất phản trực giác với người quen C++.

G1 (mặc định từ Java 9) đổi mô hình một chút: nó chia heap thành hàng nghìn vùng nhỏ đều nhau, mỗi vùng tại một thời điểm đóng vai eden, survivor hoặc old. Nhờ đó nó chọn dọn những vùng NHIỀU RÁC NHẤT trước — “garbage first” — và ước lượng được thời gian dừng theo mục tiêu bạn đặt (-XX:MaxGCPauseMillis). Với heap rất lớn thì ZGC hoặc Shenandoah phù hợp hơn, vì chúng dừng dưới mili giây bất kể heap bao lớn, đổi lại tốn thêm CPU và bộ nhớ.

Điều thực tế đáng nhớ khi debug: OutOfMemoryError: Java heap space là hết heap, thường do rò rỉ hoặc heap quá nhỏ; Metaspace là quá nhiều lớp được nạp, dấu hiệu kinh điển của việc nạp lại ứng dụng nhiều lần trong cùng JVM hoặc sinh lớp động; unable to create native thread thì không liên quan gì tới heap mà là hết bộ nhớ native hoặc chạm giới hạn tiến trình của hệ điều hành. Ba lỗi này cần ba hướng điều tra khác nhau.