Heisenbug: nó là gì, tại sao xảy ra và phương pháp bắt lỗi

Heisenbug trong phát triển di động là gì?

Heisenbug — một lớp lỗi xuất hiện trong môi trường production hoặc khi vận hành bình thường, nhưng biến mất khi cố gắng tái tạo chúng trong môi trường gỡ lỗi. Thuật ngữ này được lập trình viên Jim Gray đặt ra vào những năm 1980 trong bối cảnh hệ thống phân tán, nhưng ngày nay nó liên quan nhất đến ứng dụng di động do tính chất bất đồng bộ của chúng.

Lý do chính: các công cụ gỡ lỗi tiêu chuẩn thay đổi môi trường thực thi. Breakpoint tạm dừng luồng trong vài mili giây, ghi log thêm I/O đồng bộ, kiểm tra bổ sung thay đổi thứ tự các thao tác. Trong môi trường đa luồng, thậm chí độ trễ micro giây cũng có thể thay đổi thứ tự thực thi luồng và che giấu race condition.

Theo Microsoft Research (2022), khoảng 15-25% tất cả các lỗi trong ứng dụng di động đa luồng được phân loại là Heisenbug. Đồng thời, thời gian tìm và sửa một Heisenbug trung bình lâu hơn 5-10 lần so với lỗi thông thường, do không thể tái tạo trực tiếp.

Ví dụ về Heisenbug

Ứng dụng bị crash trong production khi vuốt nhanh danh sách, nhưng khi kết nối với trình gỡ lỗi hoặc thêm log — nó hoạt động hoàn hảo. Nguyên nhân: race condition giữa luồng UI (cập nhật RecyclerView) và luồng nền (cập nhật dữ liệu adapter). Log thêm độ trễ đồng bộ hóa các luồng một cách ngẫu nhiên.

Bohrbug, Mandelbug, Heisenbug: Phân loại lỗi

Bohrbug — lỗi có thể dự đoán, tái tạo ổn định. Được đặt tên tương tự mô hình nguyên tử Bohr: giống như nguyên tử, lỗi hoạt động giống nhau mỗi khi được quan sát. Ví dụ: NullPointerException khi nhấn nút trước khi tải dữ liệu. Được xử lý bằng kiểm thử đơn vị tiêu chuẩn.

Mandelbug — lỗi có mối quan hệ nhân quả phức tạp, hỗn loạn (được đặt tên tương tự tập Mandelbrot). Chỉ xuất hiện dưới một tổ hợp điều kiện nhất định: phiên bản OS, model thiết bị, trạng thái mạng. Khác với Heisenbug ở chỗ nó không biến mất trong quá trình gỡ lỗi — vấn đề là khó tái tạo, không phải thay đổi hành vi do công cụ.

Heisenbug — lỗi biến mất chính xác vì các công cụ gỡ lỗi. Nếu bạn thêm log — lỗi biến mất. Nếu bạn đặt breakpoint — lỗi không xuất hiện. Nếu bạn loại bỏ mọi thứ — lỗi quay trở lại. Nguyên nhân chính: thay đổi thời gian trong quá trình gỡ lỗi.

Nguyên nhân chính gây ra Heisenbug

Race condition — nguyên nhân số một của Heisenbug. Hai luồng truy cập dữ liệu chia sẻ mà không đồng bộ hóa. Trình gỡ lỗi tạo ra độ trễ, khiến các luồng đồng bộ hóa một cách tự nhiên. Không có trình gỡ lỗi, thứ tự thực thi không thể dự đoán trước.

Lỗi phụ thuộc thời gian — lỗi chỉ xuất hiện ở một tốc độ thực thi nhất định. Ví dụ: hoạt ảnh phải kết thúc trước khi thao tác tiếp theo bắt đầu. Trong trình gỡ lỗi, hoạt ảnh chạy chậm hơn và thao tác có thời gian bắt đầu sau khi hoạt ảnh kết thúc. Trong production — ngược lại.

// Example race condition — typical Heisenbug
class ListViewModel : ViewModel() {
    private var items = mutableListOf<String>()

    fun loadFromNetwork() {
        viewModelScope.launch(Dispatchers.IO) {
            val result = api.fetchItems()
            items.addAll(result) // ❌ Not thread-safe
        }
    }

    fun getItems(): List<String> = items.toList()
    // Race condition: getItems read may overlap with loadFromNetwork write
}

Tối ưu hóa trình biên dịch — trình biên dịch (JIT, ART, Kotlin/Native) có thể sắp xếp lại các lệnh để tối ưu hóa. Trong bản dựng gỡ lỗi (debug build), các tối ưu hóa bị vô hiệu hóa và mã thực thi «như đã viết». Trong bản dựng phát hành (release build), trình biên dịch thay đổi thứ tự các thao tác, điều này có thể tiết lộ các giả định ẩn trong mã.

• ThreadLocal — sử dụng sai biến thread-local không hiển thị với các luồng khác
• Biến chưa khởi tạo — mã phụ thuộc vào giá trị mặc định của trường lớp
• Hàng đợi GCD/dispatch — trong iOS, thứ tự thực thi khối không xác định trong hàng đợi đồng thời
• I/O có bộ đệm — dữ liệu không được ghi vào đĩa cho đến khi bộ đệm đầy

Chiến lược bắt lỗi khó nắm bắt

ThreadSanitizer (TSan) — công cụ của Google để phát hiện race condition trong C/C++ và Kotlin/Native. Nó được nhúng vào bản dựng và phát hiện mọi truy cập bộ nhớ chia sẻ mà không đồng bộ hóa. Không giống log, TSan không ảnh hưởng đến thời gian vì nó hoạt động thông qua mã được instrument, không phải qua I/O.

Kiểm thử tất định — thay thế bất đồng bộ thực tế bằng bất đồng bộ được kiểm soát. Sử dụng TestDispatcher (Kotlin), RxJava Plugins hoặc hàng đợi kiểm thử GCD (iOS) để kiểm soát hoàn toàn thứ tự thực thi. Chỉ định các kịch bản cụ thể: luồng A chạy, sau đó B, sau đó A lại.

Ghi log vòng — ghi log vào bộ đệm vòng trong bộ nhớ (không phải đĩa). Khi lỗi xảy ra, bộ đệm được lưu vào tệp. Vì ghi vào bộ nhớ chỉ mất nano giây (thay vì mili giây cho I/O đĩa), việc ghi log như vậy không ảnh hưởng đến thời gian và không che giấu Heisenbug.

class CyclicBuffer(val capacity: Int = 1000) {
    private val buffer = ArrayDeque<String>(capacity)
    private val lock = Any()

    fun log(message: String) {
        synchronized(lock) {
            if (buffer.size >= capacity) buffer.removeFirst()
            buffer.addLast(message)
        }
    }

    fun flush() {
        synchronized(lock) { buffer.forEach { fileWriter.write(it) } }
    }
}

Ghi log trong production — nếu lỗi không tái tạo được cục bộ, hãy thu thập dữ liệu trong production. Sử dụng log Firebase Crashlytics, Sentry Breadcrumbs hoặc trình ghi log vòng tùy chỉnh. Quan trọng: việc ghi log phải không đồng bộ và có tác động tối thiểu đến hiệu suất.

Phòng ngừa Heisenbug ở cấp kiến trúc

Cô lập trạng thái — giảm thiểu trạng thái có thể thay đổi được chia sẻ. Mỗi thành phần nên có trạng thái cô lập riêng, không thể ghi trực tiếp từ các thành phần khác. Sử dụng Unidirectional Data Flow (UDF) — trạng thái chảy theo một hướng: Sự kiện → Bộ giảm → Trạng thái → UI.

Cách tiếp cận hàm — các hàm thuần túy không có tác dụng phụ dễ kiểm thử và gỡ lỗi hơn. Cô lập các tác dụng phụ (mạng, DB, tệp) trong các lớp được xác định chặt chẽ (kho lưu trữ, nguồn dữ liệu). Lỗi luồng trong mã hàm gần như không thể.

Chế độ nghiêm ngặt — bật Android StrictMode trong bản dựng gỡ lỗi. Nó phát hiện vi phạm chính sách luồng (mạng trên luồng chính, I/O đĩa trên luồng chính) và ném ngoại lệ. Điều này biến Heisenbug tiềm ẩn thành Bohrbug tất định hiển thị ngay lập tức.

class DebugApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        if (BuildConfig.DEBUG) {
            StrictMode.setThreadPolicy(
                StrictMode.ThreadPolicy.Builder()
                    .detectDiskReads()
                    .detectDiskWrites()
                    .detectNetwork()
                    .penaltyLog()
                    .build()
            )
        }
    }
}

Đánh giá mã tập trung vào bất đồng bộ — một phần bắt buộc của quy trình. Mỗi pull request phải được kiểm tra trạng thái có thể thay đổi được chia sẻ, bộ sưu tập không an toàn luồng và thiếu đồng bộ hóa. Sử dụng quy tắc lint để tự động cấm các mẫu nhất định (ví dụ: truy cập MutableList mà không có synchronized).