Starvation i mobila applikationer — essens, orsaker och sätt att förebygga trådsvält

Vad är Starvation?

Starvation (trådsvält) — är ett problem inom flertrådad programmering där en tråd inte kan få åtkomst till resursen som krävs för att utföra en uppgift, trots att resursen inte är permanent blockerad av en annan tråd. Tråden befinner sig i RUNNABLE-tillståndet, men schemaläggaren eller synkroniseringsmekanismen skjuter systematiskt upp dess exekvering till förmån för andra trådar.

Inom mobilutveckling manifesterar sig Starvation som ojämn uppgiftsexekvering: vissa operationer utförs omedelbart, andra — med katastrofala förseningar. Till exempel kan en bakgrundstråd som synkroniserar data aldrig få åtkomst till databasen om UI-tråden och animeringshanterare ständigt ligger före. Enligt Android Developer Blog (Performance Matters, 2023) orsakas cirka 12% av missade bildrutor (jank) på Android av Starvation av bakgrundsuppgifter som renderingen är beroende av.

Den viktigaste skillnaden mellan Starvation och Deadlock — reversibilitet. Om systembelastningen minskar eller prioriteringarna omfördelas kan den svältande tråden få resursen och slutföra arbetet. Under ständigt hög belastning kan Starvation dock pågå under obestämd tid och skapa intrycket av en frusen applikation.

Orsaker till trådsvält

Orättvisa lås (Non-Fair Locks)

synchronized i Java och Kotlin — ett klassiskt exempel på en orättvis mekanism. Vid hög konkurrens kan JVM oändligt ge låset till samma aktiva trådar, medan andra trådar ständigt förlorar i racet. Detta är inte en bugg i JVM, utan en implementeringsegenskap: orättvisa lås ger högre genomströmning på bekostnad av enhetlig åtkomst. För mobila applikationer med 4-8 trådar är detta problem särskilt relevant.

Felaktig användning av prioriteter

Inställning av olika trådprioriteter kan leda till Starvation av trådar med låg prioritet. I Android Runtime fördelar Linux CFS-schemaläggaren (Completely Fair Scheduler) processtiden proportionellt mot prioriteterna, och om trådar med hög prioritet är ständigt aktiva kan trådar med låg prioritet aldrig få CPU. Google rekommenderar starkt att inte ändra trådprioriteter i Android — systemet hanterar dem själv.

Långa kritiska sektioner

Om en tråd håller låset för länge (utför tunga beräkningar, nätverksförfrågningar eller filoperationer inuti synchronized-blocket) svälter andra trådar som väntar på detta lås. Detta är särskilt farligt i Android, där långa operationer i UI-tråden orsakar ANR, och att flytta dem till bakgrundstrådar utan optimering av kritiska sektioner överför Starvation-problemet till arbetstrådar.

Exempel på Starvation i Kotlin-kod

Låt oss betrakta ett exempel där en tråd tar låset för ofta på grund av orättvis schemaläggning. Starvation demonstreras genom en oändlig loop av en tråd med hög prioritet, som inte tillåter en tråd med låg prioritet att få åtkomst till den delade resursen.

class SharedResource {
    private val lock = Any()

    fun criticalSection(id: String) {
        synchronized(lock) {
            println("$id fick åtkomst")
            Thread.sleep(10)  // simulering av arbete
        }
    }
}

fun main() {
    val resource = SharedResource()

    // Tråd med hög prioritet — ständigt aktiv
    val highPriority = Thread {
        while (true) {
            resource.criticalSection("High")
        }
    }

    // Tråd med låg prioritet — kan aldrig få åtkomst
    val lowPriority = Thread {
        while (true) {
            resource.criticalSection("Low")
        }
    }

    highPriority.start()
    lowPriority.start()
    // "Low" kanske aldrig skriver ut meddelandet — Starvation!
}

I detta exempel tar highPriority-tråden ständigt låset och släpper det endast i 10 ms. På grund av den orättvisa naturen hos synchronized kommer JVM-schemaläggaren med hög sannolikhet att ge låset igen till samma tråd som precis släppte det — tråden med låg prioritet svälter. Lösningen är att använda ReentrantLock(true) med fair-flaggan, som garanterar ordningen i väntekön.

Den korrigerade versionen med fair lock säkerställer rättvis fördelning av åtkomst till resursen.

class FairSharedResource {
    private val fairLock = ReentrantLock(true)  // fair = true

    fun criticalSection(id: String) {
        fairLock.lock()
        try {
            println("$id fick åtkomst (fair)")
            Thread.sleep(10)
        } finally {
            fairLock.unlock()
        }
    }
}

Starvation vs Deadlock vs Livelock

Tre klassiska problem inom flertrådad programmering — Starvation, Deadlock och Livelock — kombineras ofta, men deras mekanismer och sätt att eliminera skiljer sig åt. Starvation — tråden är redo men får inte resursen. Deadlock — trådar är blockerade av cyklisk väntan. Livelock — trådar är aktiva men gör inga framsteg.

Starvation anses mindre kritiskt än Deadlock, eftersom det inte är dödligt — när belastningen minskar kommer den svältande tråden så småningom att exekveras. Under verkliga användningsförhållanden för Android-applikationer, där minne och CPU är begränsade, kan Starvation dock pågå i minuter och skapa en oacceptabel användarupplevelse.

Hur man upptäcker Starvation

Thread Dump med upprepade avbildningar med korta intervall — grundmetoden för att upptäcka svält. Om en tråd konsekvent är i RUNNABLE-tillståndet, men dess anropsstack inte ändras under flera avbildningar — är detta ett klassiskt tecken på Starvation. I Android Studio används Android Profiler med inspelning av trådtillstånd över tid.

Automatiserad detektering är möjlig genom övervakning av exekveringstid för uppgifter. Om en uppgift med förutsägbar exekveringstid (t.ex. 50 ms) exekveras i 5 sekunder eller mer — finns det hög sannolikhet för Starvation. I mobila applikationer gör Firebase Performance Monitoring det möjligt att konfigurera anpassade spår (custom traces) för kritiska sektioner och få aviseringar när tröskelvärden överskrids.

För diagnos av Starvation orsakad av synchronized-block, använd Java Flight Recorder (JFR) (tillgänglig på Android via OpenJDK API) eller Async Profiler. Dessa verktyg visar vilka monitorer som har längst väntetid och vilka trådar som tävlar om varje monitor. JFR-data integreras med IntelliJ IDEA Ultimate via den inbyggda profilern.

Metoder för att förebygga trådsvält

Fair Lock (ReentrantLock med true-flagga)

ReentrantLock(true) garanterar att trådar får låset i köordning (FIFO). Till skillnad från synchronized tillåter inte fair lock att en tråd som precis har släppt låset omedelbart tar det igen. Detta eliminerar Starvation helt, även om det minskar den totala genomströmningen med 10-20% på grund av overhead för att upprätthålla kön.

Låsfria atomära strukturer

Lock-free datastrukturer (ConcurrentHashMap, AtomicReference, LongAdder) utesluter Starvation per definition, eftersom de inte innehåller lås som kan hållas av en enda tråd. Alla operationer använder processorns CAS-instruktioner, som garanterar framsteg för minst en tråd inom ett begränsat antal steg. För mobilutveckling, föredra ConcurrentLinkedQueue för uppgiftsköer.

Korta kritiska sektioner

Minimering av tiden som ett lås hålls — ett universellt sätt att minska risken för Starvation. Flytta tunga operationer (nätverk, disk I/O, komplexa beräkningar) utanför synchronized-blocket. Använd ReadWriteLock för scenarier där läsare inte borde svälta på grund av sällsynta skrivare. Kotlin Coroutines-biblioteket tillhandahåller Mutex med en suspending-mekanism som inte blockerar OS-tråden.

Villkorsvariabler och signaler

Condition.await() och signal() bör användas försiktigt: en tråd som väntar på Condition vaknar tillsammans med andra trådar (spurious wakeup) och alla tävlar om låset. Om en tråd efter await omedelbart återgår till väntan, medan andra lyckas ta låset — kan den svältande tråden vakna och somna oändligt. Kontrollera alltid villkoret i en while-loop, inte i en if, för att garantera omkontroll.