Heisenbug: що це, чому виникає та методи вилову

Що таке Heisenbug у мобільній розробці?

Heisenbug — клас помилок, які проявляються в production або під час нормальної роботи, але зникають при спробі відтворити їх у середовищі налагодження. Термін був введений у 1980-х роках програмістом Jim Gray у контексті розподілених систем, але найбільш актуальний сьогодні для мобільних застосунків через їхню асинхронну природу.

Основна причина: стандартні інструменти налагодження змінюють середовище виконання. Брейкпоінт зупиняє потік на кілька мілісекунд, логування додає синхронний I/O, додаткові перевірки змінюють порядок операцій. У багатопотоковому середовищі навіть мікросекундна затримка може змінити порядок виконання потоків і приховати гонку даних.

За даними Microsoft Research (2022), близько 15–25% всіх багів у багатопотокових мобільних застосунках класифікуються як Heisenbug. При цьому час на пошук і виправлення одного Heisenbug у середньому в 5–10 разів більший, ніж на звичайний баг, через неможливість прямого відтворення.

Приклад Heisenbug

Застосунок вилітає в production при швидкому свайпі по списку, але при підключенні до налагоджувача або додаванні логів — працює ідеально. Причина: гонка даних між UI-потоком (оновлення RecyclerView) і фоновим потоком (оновлення даних адаптера). Логи додають затримку, яка синхронізує потоки випадковим чином.

Bohrbug, Mandelbug, Heisenbug: класифікація багів

Bohrbug — передбачуваний, стабільно відтворюваний баг. Названий за аналогією з атомною моделлю Бора: як атом, баг веде себе однаково при кожному спостереженні. Приклад: NullPointerException при натисканні на кнопку до завантаження даних. Лікується стандартним unit-тестуванням.

Mandelbug — баг зі складним, хаотичним причинно-наслідковим зв’язком (названий за аналогією з множиною Мандельброта). Проявляється тільки за певної комбінації умов: версія ОС, модель пристрою, стан мережі. Відрізняється від Heisenbug тим, що не зникає при налагодженні — проблема в складності відтворення, а не в зміні поведінки від інструментів.

Heisenbug — баг, який зникає саме через інструменти налагодження. Якщо додати лог — баг зникає. Якщо поставити брейкпоінт — баг не проявляється. Якщо прибрати все — баг повертається. Основна причина: змінений timing при налагодженні.

Основні причини виникнення Heisenbug

Race condition — номер один серед причин Heisenbug. Два потоки звертаються до спільних даних без синхронізації. Налагоджувач вносить затримку, через яку потоки встигають синхронізуватися природним чином. Без налагоджувача порядок виконання непередбачуваний.

Timing-залежні помилки — баги, що проявляються тільки за певної швидкості виконання. Наприклад, анімація, яка повинна завершитися до початку наступної операції. У налагоджувачі анімація йде повільніше, і операція встигає початися після завершення анімації. У production — навпаки.

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

Оптимізація компілятора — компілятор (JIT, ART, Kotlin/Native) може перевпорядкувати інструкції для оптимізації. У налагоджувальній збірці (debug build) оптимізації вимкнені, і код виконується «як написано». У release build компілятор змінює порядок операцій, що може виявити приховані припущення в коді.

• ThreadLocal — неправильне використання thread-local змінних, які не видно іншим потокам
• Неініціалізовані змінні — код, що покладається на значення за замовчуванням полів класу
• GCD/dispatch черги — у iOS невизначений порядок виконання блоків у конкурентних чергах
• Буферизований I/O — дані не записуються на диск, доки буфер не заповнений

Стратегії вилову невловимих багів

ThreadSanitizer (TSan) — інструмент Google для виявлення гонок даних у C/C++ і Kotlin/Native. Вбудовується в збірку та детектує будь-який доступ до спільної пам’яті без синхронізації. На відміну від логів, TSan не впливає на timing, тому що працює через instrumented code, а не через I/O.

Детерміновані тести — замініть реальну асинхронність на контрольовану. Використовуйте TestDispatcher (Kotlin), RxJava Plugins або GCD test queues (iOS) для повного контролю над порядком виконання. Задавайте конкретні сценарії: потік A виконується, потім B, потім A знову.

Циклічне логування — логування в кільцевий буфер у пам’яті (не на диск). Коли баг відбувається, буфер зберігається у файл. Оскільки запис у пам’ять займає наносекунди (замість мілісекунд для disk I/O), такий лог не впливає на timing і не маскує 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) } }
    }
}

Логування в production — якщо баг не відтворюється локально, збирайте дані в production. Використовуйте Firebase Crashlytics logs, Sentry Breadcrumbs або кастомний циклічний логер. Важливо: логування має бути асинхронним і мінімально впливати на продуктивність.

Профілактика Heisenbug на рівні архітектури

Ізоляція стану — мінімізуйте shared mutable state. Кожен компонент повинен мати свій ізольований стан, недоступний для прямого запису з інших компонентів. Використовуйте Unidirectional Data Flow (UDF) — стан тече в одному напрямку: Event → Reducer → State → UI.

Функційний підхід — чисті функції без side effects легше тестувати та налагоджувати. Side effects (мережа, БД, файли) ізолюйте в суворо визначених шарах (repository, data source). Потокові помилки у функційному коді практично неможливі.

Strict mode — увімкніть Android StrictMode у debug-збірці. Він детектує порушення threading policy (мережа на main thread, disk I/O на main thread) і кидає виняток. Це перетворює потенційний Heisenbug на детермінований Bohrbug, який видно одразу.

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

Code review з фокусом на асинхронність — обов’язкова частина процесу. Кожен пул-реквест має перевірятися на наявність shared mutable state, не потокобезпечних колекцій, відсутність синхронізації. Використовуйте lint-правила для автоматичної заборони певних патернів (наприклад, доступ до MutableList без synchronized).