Heisenbug: mi ez, miért keletkezik és befogásának módszerei

Mi az a Heisenbug a mobilfejlesztésben?

Heisenbug — a hibák egy osztálya, amelyek éles környezetben vagy normál működés közben jelennek meg, de eltűnnek, amikor megpróbáljuk reprodukálni őket debug környezetben. A kifejezést az 1980-as években vezette be Jim Gray programozó az elosztott rendszerek kontextusában, de ma az aszinkron természetük miatt a mobilalkalmazásokra a leginkább releváns.

Fő ok: a szabványos debug eszközök megváltoztatják a végrehajtási környezetet. A Breakpoint több milliszekundumra leállítja a szálat, a naplózás szinkron I/O-t ad hozzá, az extra ellenőrzések megváltoztatják a műveletek sorrendjét. Többszálas környezetben akár egy mikroszekundumos késleltetés is megváltoztathatja a szálak végrehajtási sorrendjét és elrejthet egy adatversenyt.

A Microsoft Research (2022) adatai szerint a többszálas mobilalkalmazásokban előforduló összes hiba körülbelül 15-25%-a Heisenbug-nak minősül. Egy Heisenbug megtalálásának és javításának ideje átlagosan 5-10-szer hosszabb, mint egy szokásos hibáé, a közvetlen reprodukálás lehetetlensége miatt.

Heisenbug példa

Az alkalmazás éles környezetben összeomlik a lista gyors lapozásakor, de amikor a debugger csatlakozik vagy logokat adunk hozzá — tökéletesen működik. Ok: adatverseny az UI szál (RecyclerView frissítése) és a háttérszál (adapter adatainak frissítése) között. A logok késleltetést adnak hozzá, ami véletlenszerűen szinkronizálja a szálakat.

Bohrbug, Mandelbug, Heisenbug: a hibák osztályozása

Bohrbug — kiszámítható, stabilan reprodukálható hiba. Bohr atommodelljéhez hasonlóan nevezték el: mint az atom, a hiba minden megfigyeléskor ugyanúgy viselkedik. Példa: NullPointerException, amikor az adatok betöltése előtt rákattintanak egy gombra. Szabványos egységteszteléssel gyógyítható.

Mandelbug — összetett, kaotikus ok-okozati összefüggésű hiba (a Mandelbrot-halmazhoz hasonlóan nevezték el). Csak bizonyos feltételek kombinációja esetén jelenik meg: operációs rendszer verziója, eszközmodell, hálózati állapot, holdfázis. Abban különbözik a Heisenbug-tól, hogy nem tűnik el debugoláskor — a probléma a reprodukálás nehézségében rejlik, nem az eszközök által okozott viselkedésváltozásban.

Heisenbug — egy hiba, amely pontosan a debug eszközök miatt tűnik el. Ha hozzáadsz egy logot — a hiba eltűnik. Ha breakpointot helyezel el — a hiba nem jelenik meg. Ha mindent eltávolítasz — a hiba visszatér. Fő ok: megváltozott timing debugoláskor.

A Heisenbug keletkezésének fő okai

Race condition — első számú ok a Heisenbug okai között. Két szál szinkronizáció nélkül fér hozzá közös adatokhoz. A debugger késleltetést vezet be, aminek köszönhetően a szálak természetes módon tudnak szinkronizálódni. Debugger nélkül a végrehajtás sorrendje kiszámíthatatlan.

Timing-függő hibák — hibák, amelyek csak bizonyos végrehajtási sebességnél jelennek meg. Például egy animáció, amelynek a következő művelet megkezdése előtt be kell fejeződnie. Debuggerben az animáció lassabban megy, és a művelet az animáció befejezése után kezdődik. Éles környezetben — fordítva.

// Race condition példa — tipikus Heisenbug
class ListViewModel : ViewModel() {
    private var items = mutableListOf<String>()

    fun loadFromNetwork() {
        viewModelScope.launch(Dispatchers.IO) {
            val result = api.fetchItems()
            items.addAll(result) // ❌ Nem szálbiztos
        }
    }

    fun getItems(): List<String> = items.toList()
    // Race condition: a getItems olvasás átfedhet a loadFromNetwork írással
}

Fordító optimalizálása — a fordító (JIT, ART, Kotlin/Native) optimalizálás céljából átrendezheti az utasításokat. Debug buildben az optimalizálások ki vannak kapcsolva, és a kód „úgy fut, ahogy megírták“. Release buildben a fordító megváltoztatja a műveletek sorrendjét, ami felfedhet rejtett feltételezéseket a kódban.

• ThreadLocal — a thread-local változók helytelen használata, amelyek más szálak számára nem láthatók
• Nem inicializált változók — kód, amely az osztálymezők alapértelmezett értékeire támaszkodik
• GCD/dispatch sorok — iOS-ben a blokkok végrehajtási sorrendjének meghatározatlansága concurrent sorokban
• Pufferelt I/O — az adatok nem íródnak lemezre, amíg a puffer meg nem telik

Stratégiák a megfoghatatlan hibák elkapására

ThreadSanitizer (TSan) — a Google eszköze adatversenyek észlelésére C/C++-ban és Kotlin/Native-ban. Beépül a buildbe és észlel minden szinkronizáció nélküli hozzáférést a megosztott memóriához. A logokkal ellentétben a TSan nem befolyásolja a timingot, mert instrumented code-on keresztül működik, nem I/O-n keresztül.

Determinisztikus tesztek — cserélje ki a valódi aszinkronitást ellenőrzöttre. Használjon TestDispatcher-t (Kotlin), RxJava Plugins-t vagy GCD test queues-t (iOS) a végrehajtási sorrend teljes ellenőrzéséhez. Állítson be konkrét forgatókönyveket: az A szál fut, majd B, majd A újra.

Ciklikus naplózás — naplózás ciklikus pufferbe a memóriában (nem lemezre). Amikor a hiba bekövetkezik, a puffer egy fájlba mentődik. Mivel a memóriába írás nanoszekundumokig tart (a lemez I/O milliszekundumai helyett), az ilyen napló nem befolyásolja a timingot és nem maszkolja a Heisenbug-ot.

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

Naplózás éles környezetben — ha a hiba nem reprodukálható lokálisan, gyűjtsön adatokat éles környezetben. Használjon Firebase Crashlytics logs-ot, Sentry Breadcrumbs-ot vagy egyedi ciklikus naplózót. Fontos: a naplózás aszinkron legyen és minimális hatással legyen a teljesítményre.

Heisenbug megelőzése architektúra szinten

Állapot elkülönítése — minimalizálja a megosztott változtatható állapotot. Minden komponensnek saját elkülönített állapottal kell rendelkeznie, amely más komponensek számára nem írható közvetlenül. Használjon Unidirectional Data Flow-t (UDF) — az állapot egy irányba áramlik: Event → Reducer → State → UI.

Funkcionális megközelítés — a mellékhatások nélküli tiszta függvényeket könnyebb tesztelni és debugolni. A mellékhatásokat (hálózat, adatbázis, fájlok) szigorúan meghatározott rétegekben (repository, data source) izolálja. Szálkapcsolatos hibák funkcionális kódban gyakorlatilag lehetetlenek.

Strict mode — kapcsolja be az Android StrictMode-ot a debug buildben. Észleli a threading policy megsértését (hálózat a fő szálon, lemez I/O a fő szálon) és kivételt dob. Ez egy potenciális Heisenbug-ot determinisztikus Bohrbug-gá alakít, amely azonnal látható.

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

Code review az aszinkronitásra fókuszálva — a folyamat kötelező része. Minden pull request-et ellenőrizni kell megosztott változtatható állapot, nem szálbiztos kollekciók, szinkronizáció hiánya szempontjából. Használjon lint szabályokat bizonyos minták automatikus tiltására (pl. MutableList elérése synchronized nélkül).