Rò rỉ bộ nhớ: nó là gì, các kịch bản điển hình và chẩn đoán

Rò rỉ bộ nhớ trong ứng dụng di động là gì?

Rò rỉ bộ nhớ — tình huống khi bộ nhớ được cấp phát không được trả lại cho hệ thống sau khi đối tượng không còn cần thiết cho chương trình. Trình dọn rác coi đối tượng đó là còn sống vì có một chuỗi tham chiếu hoạt động từ GC Root trỏ đến nó.

Trong Java/Kotlin, trình dọn rác hoạt động tự động, nhưng nó không thể xác định rằng một đối tượng không cần thiết về mặt logic nếu có tham chiếu kỹ thuật đến nó. Nhà phát triển phải chủ động ngắt các kết nối không cần thiết. Trong Swift/Objective-C, ARC tự động đếm tham chiếu, nhưng retain cycles ngăn bộ đếm về không.

Nguy hiểm chính của rò rỉ là hiệu ứng tích lũy. Mỗi rò rỉ tiêu thụ một lượng nhỏ bộ nhớ, nhưng với các chuyển đổi màn hình lặp lại (xoay màn hình, mở/đóng Activity), rò rỉ tích tụ cho đến khi cạn kiệt giới hạn heap.

Rò rỉ khác với phình to thế nào?

Rò rỉ — đối tượng không thể truy cập được từ mã nhưng không bị GC xóa. Phình to — đối tượng cần thiết về mặt logic nhưng được lưu trữ với số lượng quá mức. Ví dụ về phình to: bộ đệm ảnh 100 MB với tập làm việc 30 MB. Cả hai vấn đề đều dẫn đến OOM, nhưng nguyên nhân và phương pháp xử lý khác nhau.

Trình dọn rác hoạt động thế nào và tại sao rò rỉ xảy ra?

ART (Android Runtime) sử dụng dọn rác theo thế hệ với nén đồng thời. Bộ nhớ được chia thành thế hệ trẻ (Young), thế hệ già (Old) và đối tượng lớn (Large). Các đối tượng sống qua nhiều chu kỳ GC được chuyển đến Old generation, nơi việc dọn ít xảy ra hơn — điều này tăng tốc các chu kỳ thông thường.

GC bắt đầu khi heap đạt đến một ngưỡng chiếm dụng nhất định (thường là 75-85%). Trong thời gian GC, tất cả các luồng của ứng dụng đều bị tạm dừng (STW — Stop The World). Càng nhiều đối tượng sống, thời gian tạm dừng càng lâu. Rò rỉ làm tăng số lượng đối tượng sống, kéo dài thời gian tạm dừng GC.

Trình dọn xác định các đối tượng sống bằng cách duyệt đồ thị từ GC Roots: trường tĩnh, biến stack của các luồng đang hoạt động, tham chiếu JNI. Bất kỳ đối tượng nào có thể truy cập qua tham chiếu từ các gốc này đều được coi là sống — ngay cả khi nhà phát triển biết rằng nó không còn cần thiết.

// Ví dụ: bộ sưu tập tĩnh như GC Root — rò rỉ vĩnh viễn
object GlobalHolder {
    val listeners = mutableListOf<WeakReference<Any>>()
}

class LeakingFragment : Fragment() {
    override fun onCreate(savedInstanceState: Bundle ?= null) {
        super.onCreate(savedInstanceState)
        GlobalHolder.listeners.add(WeakReference(this))
        // WeakReference không ngăn GC — hành vi đúng
    }
}

WeakReference giải quyết vấn đề: GC bỏ qua tham chiếu yếu khi xác định đối tượng sống. Nếu chỉ còn tham chiếu yếu đến một đối tượng, nó sẽ được dọn trong chu kỳ GC gần nhất.

Các kịch bản rò rỉ điển hình trong Android và iOS

Activity Context — kịch bản rò rỉ phổ biến nhất trong Android. Nếu singleton, trường tĩnh hoặc dịch vụ tồn tại lâu lưu trữ tham chiếu đến Activity Context, toàn bộ Activity với tất cả Views không thể được GC dọn. Giải pháp: sử dụng Application Context cho các đối tượng tồn tại lâu.

Handler và tin nhắn đã gửi — Handler.postDelayed(runnable, delay) đặt một tin nhắn vào hàng đợi Main Looper. Nếu Activity bị hủy trước khi hết thời gian trễ, tin nhắn vẫn ở trong hàng đợi và giữ tham chiếu qua Runnable → lớp ẩn danh → lớp bên ngoài (Activity).

class SafeActivity : AppCompatActivity() {
    private val mainHandler = Handler(Looper.getMainLooper())
    private val callback = Runnable { /* update UI */ }

    override fun onResume() {
        super.onResume()
        mainHandler.postDelayed(callback, 5000)
    }

    override fun onPause() {
        mainHandler.removeCallbacks(callback) // bắt buộc: xóa hàng đợi
        super.onPause()
    }
}

Lớp bên trong — lớp bên trong không tĩnh có tham chiếu ngầm đến thể hiện của lớp bên ngoài. Nếu lớp bên ngoài là Activity và lớp bên trong được truyền ra ngoài (ví dụ, vào RecyclerView.Adapter), Activity không thể được dọn.

• TimerTask và ScheduledExecutorService — tác vụ đã lên lịch trước khi Activity bị hủy
• BroadcastReceiver — không hủy đăng ký trong onPause/onDestroy tiếp tục giữ Context
• ViewModel với tham chiếu đến View — ViewModel sống lâu hơn Activity, tham chiếu đến View dẫn đến rò rỉ
• Retrofit Call — nếu Call không bị hủy, phản hồi đến Fragment đã bị hủy

Công cụ chẩn đoán rò rỉ bộ nhớ

Android Studio Memory Profiler — công cụ tích hợp để giám sát heap thời gian thực. Hiển thị biểu đồ bộ nhớ đã dùng, số lượng cấp phát và đối tượng theo loại. Cho phép ghi heap dump và xuất sang định dạng HPROF để phân tích trong MAT.

Eclipse MAT (Memory Analyzer Tool) — trình phân tích heap dump trên máy tính để bàn. Tự động xây dựng báo cáo Leak Suspects, làm nổi bật các đối tượng có retained size lớn nhất và đề xuất chuỗi GC Root nghi ngờ cho mỗi đối tượng khả nghi.

Xcode Memory Graph Debugger — dành cho iOS. Tạm dừng ứng dụng và trực quan hóa đồ thị đối tượng. Retain cycles được tô màu đỏ; bạn có thể nhấp vào bất kỳ đối tượng nào để xem retain count và tham chiếu của nó.

Theo Uber Engineering Blog, việc tích hợp lược sử bộ nhớ tự động (LeakCanary + phân tích heap dump) vào đường ống CI/CD giảm 60% sự cố liên quan đến bộ nhớ trong sản xuất trong vòng 3 tháng.

Phương pháp loại bỏ rò rỉ

Thay thế Context — nếu đối tượng sống lâu hơn Activity, hãy sử dụng applicationContext. Tất cả các đối tượng tồn tại lâu (singleton, repository, helper cơ sở dữ liệu) nên nhận Application Context, không phải Activity Context. Ngoại lệ: thành phần UI cần truy cập theme hoặc tài nguyên cụ thể của Activity.

Thành phần nhận biết vòng đời — sử dụng LifecycleObserver, DefaultLifecycleObserver hoặc phần mở rộng phản ứng tự động hủy đăng ký tại onDestroy. Android Jetpack cung cấp lifecycleScope và viewModelScope, được dọn dẹp bởi sự kiện vòng đời tương ứng.

Lớp bên trong tĩnh — nếu lớp bên trong không cần truy cập vào các trường của lớp bên ngoài, hãy làm cho nó static. Lớp bên trong tĩnh không có tham chiếu ngầm đến lớp bên ngoài. Nếu cần truy cập, hãy sử dụng WeakReference cho tham chiếu tường minh.

class MyActivity : AppCompatActivity() {

    // ❌ Lớp bên trong không tĩnh — tham chiếu ngầm đến MyActivity
    inner class BadListener : SomeListener {
        override fun onEvent() { /*...*/ }
    }

    // ✅ Lớp bên trong tĩnh — không có tham chiếu ngầm
    class GoodListener(private val activityRef: WeakReference<MyActivity>) : SomeListener {
        override fun onEvent() { /*...*/ }
    }
}

Trong iOS, sử dụng danh sách chụp: [weak self] trong các closure có thể sống lâu hơn người tạo ra chúng. Cho delegate, sử dụng tham chiếu yếu (weak var delegate). Cho các closure được đảm bảo chỉ được gọi trong vòng đời của self, có thể sử dụng [unowned self], nhưng cẩn thận — truy cập đối tượng đã giải phóng sẽ gây treo.