Heisenbug: apa itu, mengapa terjadi dan metode penangkapan

Apa itu Heisenbug dalam pengembangan mobile?

Heisenbug — kelas kesalahan yang muncul di lingkungan produksi atau saat operasi normal, tetapi menghilang saat mencoba mereproduksinya di lingkungan debug. Istilah ini diperkenalkan pada tahun 1980-an oleh programmer Jim Gray dalam konteks sistem terdistribusi, tetapi paling relevan saat ini untuk aplikasi mobile karena sifat asinkronnya.

Penyebab utama: alat debug standar mengubah lingkungan eksekusi. Breakpoint menghentikan thread selama beberapa milidetik, logging menambahkan I/O sinkron, pemeriksaan tambahan mengubah urutan operasi. Dalam lingkungan multi-thread, bahkan penundaan mikrodetik pun dapat mengubah urutan eksekusi thread dan menyembunyikan race condition.

Menurut data Microsoft Research (2022), sekitar 15-25% dari semua bug di aplikasi mobile multi-thread diklasifikasikan sebagai Heisenbug. Waktu untuk menemukan dan memperbaiki satu Heisenbug rata-rata 5-10 kali lebih lama daripada bug biasa, karena ketidakmungkinan reproduksi langsung.

Contoh Heisenbug

Aplikasi crash di produksi saat menggesek daftar dengan cepat, tetapi saat debugger terhubung atau log ditambahkan — berfungsi sempurna. Penyebab: race condition antara thread UI (memperbarui RecyclerView) dan thread latar belakang (memperbarui data adapter). Log menambahkan penundaan yang secara acak menyinkronkan thread.

Bohrbug, Mandelbug, Heisenbug: klasifikasi bug

Bohrbug — bug yang dapat diprediksi, stabil dan dapat direproduksi. Dinamai dengan analogi model atom Bohr: seperti atom, bug berperilaku sama setiap kali diamati. Contoh: NullPointerException saat mengklik tombol sebelum data dimuat. Diobati dengan pengujian unit standar.

Mandelbug — bug dengan hubungan sebab-akibat yang kompleks dan kacau (dinamai dengan analogi himpunan Mandelbrot). Muncul hanya pada kombinasi kondisi tertentu: versi OS, model perangkat, status jaringan, fase bulan. Berbeda dari Heisenbug karena tidak hilang saat debug — masalahnya terletak pada kesulitan reproduksi, bukan perubahan perilaku akibat alat.

Heisenbug — bug yang hilang justru karena alat debug. Jika Anda menambahkan log — bug hilang. Jika Anda memasang breakpoint — bug tidak muncul. Jika Anda menghapus semuanya — bug kembali. Penyebab utama: timing yang berubah saat debug.

Penyebab utama munculnya Heisenbug

Race condition — nomor satu di antara penyebab Heisenbug. Dua thread mengakses data bersama tanpa sinkronisasi. Debugger menimbulkan penundaan, yang memungkinkan thread untuk sinkron secara alami. Tanpa debugger, urutan eksekusi tidak dapat diprediksi.

Kesalahan tergantung timing — bug yang muncul hanya pada kecepatan eksekusi tertentu. Misalnya, animasi yang harus selesai sebelum operasi berikutnya dimulai. Di debugger, animasi berjalan lebih lambat dan operasi berhasil dimulai setelah animasi selesai. Di produksi — sebaliknya.

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

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

    fun getItems(): List<String> = items.toList()
    // Race condition: pembacaan getItems dapat tumpang tindih dengan penulisan loadFromNetwork
}

Optimasi kompiler — kompiler (JIT, ART, Kotlin/Native) dapat mengatur ulang instruksi untuk optimasi. Di debug build, optimasi dinonaktifkan dan kode dieksekusi “sebagaimana ditulis”. Di release build, kompiler mengubah urutan operasi, yang dapat mengungkapkan asumsi tersembunyi dalam kode.

• ThreadLocal — penggunaan variabel thread-local yang salah, tidak terlihat oleh thread lain
• Variabel yang tidak diinisialisasi — kode yang bergantung pada nilai default bidang kelas
• Antrian GCD/dispatch — di iOS, urutan eksekusi blok yang tidak ditentukan dalam antrian concurrent
• I/O buffer — data tidak ditulis ke disk hingga buffer penuh

Strategi menangkap bug yang sulit ditemukan

ThreadSanitizer (TSan) — alat Google untuk mendeteksi race condition di C/C++ dan Kotlin/Native. Tertanam dalam build dan mendeteksi setiap akses ke memori bersama tanpa sinkronisasi. Tidak seperti log, TSan tidak memengaruhi timing karena bekerja melalui instrumented code, bukan melalui I/O.

Test deterministik — ganti asyncronisitas nyata dengan yang terkontrol. Gunakan TestDispatcher (Kotlin), RxJava Plugins atau GCD test queues (iOS) untuk kontrol penuh atas urutan eksekusi. Tetapkan skenario spesifik: thread A dijalankan, lalu B, lalu A lagi.

Logging siklik — logging ke buffer siklik di memori (bukan ke disk). Saat bug terjadi, buffer disimpan ke file. Karena menulis ke memori membutuhkan nanodetik (alih-alih milidetik untuk I/O disk), log semacam itu tidak memengaruhi timing dan tidak menyembunyikan 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) } }
    }
}

Logging di produksi — jika bug tidak dapat direproduksi secara lokal, kumpulkan data di produksi. Gunakan Firebase Crashlytics logs, Sentry Breadcrumbs atau logger siklik kustom. Penting: logging harus asinkron dan memiliki dampak minimal pada kinerja.

Pencegahan Heisenbug di tingkat arsitektur

Isolasi status — minimalkan status bersama yang dapat diubah. Setiap komponen harus memiliki status terisolasi sendiri, tidak dapat diakses untuk penulisan langsung dari komponen lain. Gunakan Unidirectional Data Flow (UDF) — status mengalir dalam satu arah: Event → Reducer → State → UI.

Pendekatan fungsional — fungsi murni tanpa efek samping lebih mudah diuji dan di-debug. Efek samping (jaringan, database, file) diisolasi dalam lapisan yang ditentukan secara ketat (repository, data source). Kesalahan terkait thread dalam kode fungsional praktis tidak mungkin terjadi.

Strict mode — aktifkan Android StrictMode di debug build. Ini mendeteksi pelanggaran kebijakan threading (jaringan di main thread, I/O disk di main thread) dan melempar pengecualian. Ini mengubah potensi Heisenbug menjadi Bohrbug deterministik yang langsung terlihat.

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

Code review dengan fokus pada asinkronisitas — bagian wajib dari proses. Setiap pull request harus diperiksa untuk status bersama yang dapat diubah, koleksi yang tidak thread-safe, kurangnya sinkronisasi. Gunakan aturan lint untuk melarang otomatis pola tertentu (misalnya, akses ke MutableList tanpa synchronized).