Heisenbug: nima, nima uchun paydo bo'ladi va tutish usullari

Mobil ishlab chiqishda Heisenbug nima?

Heisenbug — ishlab chiqarish muhitida yoki normal ish paytida paydo bo‘ladigan, ammo tuzatish muhitida takrorlashga urinishda yo‘qoladigan xatolar sinfi. Bu atama 1980-yillarda dasturchi Jim Gray tomonidan taqsimlangan tizimlar kontekstida kiritilgan, ammo bugungi kunda asinxron tabiati tufayli mobil ilovalar uchun eng dolzarb hisoblanadi.

Asosiy sabab: standard tuzatish vositalari bajarish muhitini o‘zgartiradi. Breakpoint oqimni bir necha millisekundga to‘xtatadi, loglash sinxron I/O qo‘shadi, qo‘shimcha tekshirishlar operatsiyalar tartibini o‘zgartiradi. Ko‘p oqimli muhitda hatto mikrosekundlik kechikish ham oqimlarning bajarilish tartibini o‘zgartirishi va ma‘lumot poygasini yashirishi mumkin.

Microsoft Research (2022) ma‘lumotlariga ko‘ra, ko‘p oqimli mobil ilovalardagi barcha xatolarning taxminan 15-25% i Heisenbug sifatida tasniflanadi. Bitta Heisenbugni topish va tuzatish vaqti oddiy xatoga qaraganda o‘rtacha 5-10 baravar ko‘p, chunki to‘g‘ridan-to‘g‘ri takrorlash imkonsiz.

Heisenbug namunasi

Ilova ishlab chiqarish muhitida ro‘yxatni tez surishda ishdan chiqadi, ammo debugger ulanganda yoki loglar qo‘shilganda mukammal ishlaydi. Sabab: UI oqimi (RecyclerView yangilanishi) va fon oqimi (adapter ma‘lumotlarini yangilash) o‘rtasidagi ma‘lumot poygasi. Loglar kechikish qo‘shadi, bu esa oqimlarni tasodifiy ravishda sinxronlashtiradi.

Bohrbug, Mandelbug, Heisenbug: xatolar tasnifi

Bohrbug — oldindan aytish mumkin bo‘lgan, barqaror takrorlanadigan xato. Bor atom modeliga o‘xshatib nomlangan: atom kabi, xato har bir kuzatishda bir xil harakat qiladi. Misol: ma‘lumot yuklanmasdan oldin tugmani bosganda NullPointerException. Standard birlik testi bilan davolanadi.

Mandelbug — murakkab, xaotik sabab-natija bog‘liqligi bo‘lgan xato (Mandelbrot to‘plamiga o‘xshatib nomlangan). Faqat ma‘lum shartlar kombinatsiyasida namoyon bo‘ladi: OS versiyasi, qurilma modeli, tarmoq holati, oy fazasi. Heisenbugdan farqi shundaki, tuzatish paytida yo‘qolmaydi — muammo takrorlashning murakkabligida, vositalarning xatti-harakatni o‘zgartirishida emas.

Heisenbug — aynan tuzatish vositalari sababli yo‘qoladigan xato. Log qo‘shsangiz — xato yo‘qoladi. Breakpoint qo‘ysangiz — xato namoyon bo‘lmaydi. Hammasini olib tashlasangiz — xato qaytadi. Asosiy sabab: tuzatish paytida o‘zgartirilgan timing.

Heisenbug paydo bo‘lishining asosiy sabablari

Race condition — Heisenbug sabablari orasida birinchi raqam. Ikki oqim sinxronizatsiyasiz umumiy ma‘lumotlarga murojaat qiladi. Debugger kechikish kiritadi, buning natijasida oqimlar tabiiy ravishda sinxronlashishga ulguradi. Debuggersiz bajarilish tartibi oldindan aytib bo‘lmaydi.

Timingga bog‘liq xatolar — faqat ma‘lum bajarilish tezligida paydo bo‘ladigan xatolar. Masalan, keyingi operatsiya boshlanishidan oldin tugashi kerak bo‘lgan animatsiya. Debuggerda animatsiya sekinroq ishlaydi va operatsiya animatsiya tugagandan so‘ng boshlanadi. Ishlab chiqarish muhitida — aksincha.

// Race condition namunasi — odatiy Heisenbug
class ListViewModel : ViewModel() {
    private var items = mutableListOf<String>()

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

    fun getItems(): List<String> = items.toList()
    // Race condition: getItems o‘qishi loadFromNetwork yozishi bilan ustma-ust tushishi mumkin
}

Kompilyator optimizatsiyasi — kompilyator (JIT, ART, Kotlin/Native) optimizatsiya uchun ko‘rsatmalarni qayta tartiblashi mumkin. Debug buildda optimizatsiyalar o‘chirilgan va kod “yozilganidek” bajariladi. Release buildda kompilyator operatsiyalar tartibini o‘zgartiradi, bu esa koddagi yashirin taxminlarni ochib berishi mumkin.

• ThreadLocal — boshqa oqimlarga ko‘rinmaydigan thread-local o‘zgaruvchilardan noto‘g‘ri foydalanish
• Initsializatsiya qilinmagan o‘zgaruvchilar — sinf maydonlarining standart qiymatlariga tayanadigan kod
• GCD/dispatch navbatlari — iOSda concurrent navbatlardagi bloklarning noaniq bajarilish tartibi
• Buferlashtirilgan I/O — bufer to‘lgunga qadar ma‘lumotlar diskka yozilmaydi

Tutib bo‘lmaydigan xatolarni qo‘lga olish strategiyalari

ThreadSanitizer (TSan) — C/C++ va Kotlin/Native da ma‘lumot poygasini aniqlash uchun Google vositasi. Buildga o‘rnatiladi va sinxronizatsiyasiz umumiy xotiraga har bir kirishni aniqlaydi. Loglardan farqli o‘laroq, TSan timingga ta‘sir qilmaydi, chunki I/O orqali emas, instrumented code orqali ishlaydi.

Deterministik testlar — haqiqiy asinxronlikni boshqariladigan bilan almashtiring. Bajarilish tartibi ustidan to‘liq nazorat qilish uchun TestDispatcher (Kotlin), RxJava Plugins yoki GCD test queues (iOS) dan foydalaning. Aniq stsenariylarni belgilang: oqim A bajariladi, keyin B, keyin A yana.

Siklik loglash — diskka emas, xotiradagi siklik buferga loglash. Xato sodir bo‘lganda, bufer faylga saqlanadi. Xotiraga yozish nanosekundlar davom etgani uchun (disk I/O uchun millisekundlar o‘rniga), bunday log timingga ta‘sir qilmaydi va Heisenbugni niqoblamaydi.

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) } }
    }
}

Ishlab chiqarish muhitida loglash — agar xato lokal takrorlanmasa, ishlab chiqarishda ma‘lumot to‘plang. Firebase Crashlytics logs, Sentry Breadcrumbs yoki maxsus siklik loggerdan foydalaning. Muhim: loglash asinxron bo‘lishi va unumdorlikka minimal ta‘sir ko‘rsatishi kerak.

Arxitektura darajasida Heisenbug profilaktikasi

Holatni izolyatsiya qilish — umumiy o‘zgaruvchan holatni minimallashtiring. Har bir komponent boshqa komponentlardan to‘g‘ridan-to‘g‘ri yozish uchun mavjud bo‘lmagan o‘zining izolyatsiya qilingan holatiga ega bo‘lishi kerak. Unidirectional Data Flow (UDF) dan foydalaning — holat bir yo‘nalishda oqadi: Event → Reducer → State → UI.

Funksional yondashuv — yon ta‘sirlari bo‘lmagan toza funksiyalarni sinash va tuzatish osonroq. Yon ta‘sirlarni (tarmoq, ma‘lumotlar bazasi, fayllar) qat‘iy belgilangan qatlamlarda (repository, data source) izolyatsiya qiling. Funksional koddagi oqim xatolari amalda mumkin emas.

Strict mode — debug buildda Android StrictMode-ni yoqing. Threading siyosati buzilishlarini (asosiy oqimda tarmoq, asosiy oqimda disk I/O) aniqlaydi va istisno tashlaydi. Bu potensial Heisenbugni darhol ko‘rinadigan deterministik Bohrbugga aylantiradi.

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

Asinxronlikka e‘tibor qaratgan code review — jarayonning majburiy qismi. Har bir pull request umumiy o‘zgaruvchan holat, oqim xavfsiz bo‘lmagan kolleksiyalar, sinxronizatsiya yo‘qligi uchun tekshirilishi kerak. Muayyan naqshlarni avtomatik taqiqlash uchun lint qoidalari dan foydalaning (masalan, synchronized siz MutableListga kirish).