Thread Pool inom mobilutveckling — grunder, trådpool och funktionsprincip

Vad är Thread Pool?

Thread Pool (trådpool) — är ett arkitekturmönster där ett fast antal trådar skapas i förväg och återanvänds för att utföra flera uppgifter. Istället för att skapa en ny tråd för varje operation (vilket är dyrt: cirka 1 MB stack per tråd i JVM) placeras uppgifter i en kö och utförs av lediga trådar från poolen. Inom mobilutveckling är trådpoolen kritisk för prestanda — Android och iOS begränsar antalet trådar per app.

Varför Thread Pool är viktig inom mobilutveckling

Att skapa en tråd är en dyr operation: stackallokering, registrering i systemet, kontextväxling. På mobila enheter med begränsade resurser leder okontrollerad trådskapning till OOM (OutOfMemoryError) i Android och till throttling i iOS. Thread Pool löser båda problemen: begränsar det maximala antalet samtidigt aktiva trådar och återanvänder redan skapade trådar. Google rekommenderar ExecutorService istället för raw Thread(), Apple rekommenderar OperationQueue istället för Thread.

Hur fungerar Thread Pool inom mobilutveckling?

Trådpoolen fungerar enligt principen Producer-Consumer: uppgifter (Runnable/Callable) placeras i en blockerande kö (BlockingQueue). Trådar från poolen väntar på uppgifter i kön och hämtar dem för utförande. Algoritm: om det finns färre lediga trådar än corePoolSize skapas en ny tråd. Om corePoolSize har uppnåtts placeras uppgiften i kön. Om kön är full och det finns färre trådar än maximumPoolSize skapas en extra tråd. Vid överskridande av maximumPoolSize avvisas uppgiften via RejectedExecutionHandler.

Core Pool Size vs Maximum Pool Size

Core pool size — antalet trådar som behålls i poolen även i viloläge. Maximum pool size — det maximala antalet trådar som kan skapas vid kööverflöde. Skillnaden mellan dem är extra (overflow) trådar som skapas tillfälligt och avslutas efter en inaktivitets-timeout. På mobila enheter rekommenderas att ställa in corePoolSize lika med maximumPoolSize för att undvika toppbelastningar vid trådskapning.

Work Queue och RejectedExecutionHandler

BlockingQueue lagrar uppgifter som väntar på utförande. De mest populära implementeringarna: LinkedBlockingQueue (obegränsad), ArrayBlockingQueue (begränsad) och SynchronousQueue (utan lagring — uppgiften överförs omedelbart till en tråd). När kön och poolen blir fulla aktiveras RejectedExecutionHandler. Standardpolicyer: AbortPolicy (kastar RejectedExecutionException), CallerRunsPolicy (utför i avsändarens tråd), DiscardPolicy och DiscardOldestPolicy.

// Skapa Thread Pool i Android
val threadPool = ThreadPoolExecutor(
    corePoolSize = 2,        // Minst 2 trådar
    maximumPoolSize = 4,     // Högst 4 trådar
    keepAliveTime = 30L,     // Livslängd för overflow-tråd
    unit = TimeUnit.SECONDS,
    workQueue = LinkedBlockingQueue<Runnable>(16),
    threadFactory = Executors.defaultThreadFactory(),
    handler = ThreadPoolExecutor.CallerRunsPolicy()
)

// Skicka uppgifter
threadPool.execute {
    val result = api.fetchData()
    runOnUiThread { showData(result) }
}

// Avsluta poolen
threadPool.shutdown()
// Vänta på att alla uppgifter slutförs
threadPool.awaitTermination(10, TimeUnit.SECONDS)

Thread Pool i Android: ExecutorService

Android tillhandahåller flera implementeringar av trådpooler via java.util.concurrent. Executors — en fabrik med färdiga konfigurationer: newFixedThreadPool(n) (fast pool), newCachedThreadPool() (obegränsad, trådar skapas vid behov), newSingleThreadExecutor() (en tråd — sekventiell utförande). För mobilprojekt rekommenderas newFixedThreadPool med en rimlig gräns (2-4 trådar), eftersom en cachad pool kan skapa för många trådar.

ThreadPoolExecutor i Android

ThreadPoolExecutor (TPE) — den fullständiga implementeringen av ExecutorService med konfigurerbara parametrar. I Android används TPE inom AsyncTask, IntentService och JobIntentService. Parametrarna corePoolSize, maximumPoolSize, keepAliveTime, BlockingQueue och RejectedExecutionHandler möjliggör finjustering av poolens beteende. Rekommendationer för Android: corePoolSize = antal CPU-kärnor - 1 (för IO-bound uppgifter) eller antal kärnor (för CPU-bound uppgifter). För typiska appar — 2-4 trådar.

// Färdiga Executors-konfigurationer
// 1. Fast pool med 3 trådar
val fixedPool = Executors.newFixedThreadPool(3)

// 2. Cachad pool (rekommenderas inte för mobil)
val cachedPool = Executors.newCachedThreadPool()

// 3. Enkel tråd (serialisering)
val singlePool = Executors.newSingleThreadExecutor()

// 4. Schemaläggare (periodiska uppgifter)
val scheduler = Executors.newScheduledThreadPool(2)

// Användning med Callable och Future
val future: Future<String> = fixedPool.submit(Callable {
    "Result: ${api.call()}"
})
// Hämta resultat (blockerar tråd)
val result = future.get(5, TimeUnit.SECONDS)

// Avsluta poolen
fixedPool.shutdownNow()

CoroutineDispatcher som trådpool

Kotlin-korutiner tillhandahåller CoroutineDispatcher — en abstraktion som liknar en trådpool. Dispatchers.IO använder en pool med 64 trådar (begränsad). Dispatchers.Default — en pool lika med antalet CPU-kärnor. CoroutineDispatcher kräver ingen manuell shutdown och hanteras automatiskt. För finjustering, skapa din egen ExecutorCoroutineDispatcher via Executors.newFixedThreadPool(2).asCoroutineDispatcher(). Korutiner ersätter inte trådpoolen utan omsluter den.

Thread Pool i iOS: OperationQueue och GCD

iOS tillhandahåller två huvudmekanismer för att hantera trådpoolen: OperationQueue (högnivå-API baserat på GCD) och GCD DispatchQueue (lågnivå C-API). OperationQueue kapslar in trådpoolen via egenskapen maxConcurrentOperationCount. Som standard använder OperationQueue system-defined maximum (beroende på systembelastning). DispatchQueue.global() tillhandahåller en samtidig kö med systemets trådpool.

OperationQueue och maxConcurrentOperationCount

OperationQueue hanterar trådpoolen via maxConcurrentOperationCount. Värdet 1 skapar en seriell kö (liknande single thread pool). Värdet större än 1 — en samtidig pool med angiven gräns. Som standard är maxConcurrentOperationCount = NSOperationQueueDefaultMaxConcurrentOperationCount (systemoptimum, vanligtvis 4-8 trådar). Operation stöder beroenden, prioriteter och avbrytning. Varje operation utförs på valfri ledig tråd från systempoolen.

// OperationQueue med pool på 3 trådar
let queue = OperationQueue()
queue.maxConcurrentOperationCount = 3
queue.qualityOfService = .utility

// Skapa operationer
let operation1 = BlockOperation {
    let data = fetchData(from: url1)
    DispatchQueue.main.async { updateUI(data) }
}

let operation2 = BlockOperation {
    let data = fetchData(from: url2)
    DispatchQueue.main.async { updateUI(data) }
}

// Beroende: operation2 väntar på operation1
operation2.addDependency(operation1)

// Lägga till i kö
queue.addOperations([operation1, operation2], waitUntilFinished: false)

// Avbryta alla operationer
queue.cancelAllOperations()

GCD DispatchQueue som trådpool

DispatchQueue — Apples trådpool. En samtidig kö (qos: .utility) använder systemets trådpool, optimerad för enhetens aktuella belastning. Olika QoS (userInteractive, userInitiated, utility, background) mappas till olika pooler med olika prioriteter. DispatchGroup möjliggör synkronisering av flera uppgifter. DispatchWorkItem stöder avbrytning och qualityOfService. För fin kontroll, skapa dina egna samtidiga köer via DispatchQueue(label: qos: attributes: .concurrent).

// GCD DispatchQueue som trådpool
let customQueue = DispatchQueue(
    label: "com.app.background",
    qos: .utility,
    attributes: .concurrent,
    autoreleaseFrequency: .workItem
)

// Skicka uppgifter till poolen
customQueue.async { self.processFile(file1) }
customQueue.async { self.processFile(file2) }

// DispatchGroup för synkronisering
let group = DispatchGroup()
let pool = DispatchQueue.global(qos: .utility)

pool.async(group: group) { fetchData() }
pool.async(group: group) { processImage() }

group.notify(queue: .main) {
    self.showResult() // Båda uppgifterna slutförda
}

// Begränsa samtidighet via semaphore
let semaphore = DispatchSemaphore(value: 3)
for url in urls {
    pool.async {
        semaphore.wait()
        download(url)
        semaphore.signal()
    }
}

Konfigurationsparametrar för Thread Pool

Konfigurationen av trådpoolen påverkar direkt appens prestanda. Felaktiga parametrar leder till underutnyttjande av CPU (för få trådar) eller överbelastning av systemet (för många). I mobilappar skiljer sig de optimala värdena från servervärden på grund av begränsade resurser och energiförbrukning. Huvudparametrar: corePoolSize, maxPoolSize, queue capacity och keepAliveTime.

Beräkning av optimal poolstorlek

Formel för IO-bound uppgifter: corePoolSize = antal CPU-kärnor × 2 (trådar väntar på in-/utdata). För CPU-bound uppgifter: corePoolSize = antal CPU-kärnor (trådar är ständigt upptagna med beräkningar). På moderna mobila enheter (6-8 kärnor) ger detta 6-8 trådar för CPU-bound och 12-16 för IO-bound. Praktiska tester visar att för en typisk mobilapp är 3-4 trådar optimala — fler trådar ökar energiförbrukningen utan att förbättra prestandan.

Queue Capacity och beteende vid överflöde

Storleken på uppgiftskön (work queue) avgör hur många uppgifter som kan vänta på utförande. Obegränsad kö (LinkedBlockingQueue utan gräns) kan leda till OOM vid snabb ankomst av uppgifter. Begränsad kö (ArrayBlockingQueue med fast storlek) avvisar uppgifter vid överflöde. För mobilappar rekommenderas ArrayBlockingQueue med en kapacitet på 16-32 uppgifter. CallerRunsPolicy — den bästa RejectedExecutionHandler för mobila enheter: saktar ner avsändaren (pressure back) istället för att förlora uppgiften.

Vanliga misstag vid arbete med trådpoolen

Mobilapputvecklare gör ofta misstag vid användning av trådpoolen, vilket leder till krascher, minnesläckor och instabil funktion. Vanligast: att inte anropa shutdown() för ExecutorService, att skapa en ny pool för varje operation, en för stor pool, deadlock mellan uppgifter, att använda CachedThreadPool i Android.

Deadlock i Thread Pool

Deadlock uppstår när en uppgift i poolen väntar på resultatet av en annan uppgift från samma pool, men alla trådar är upptagna med att vänta. Exempel: uppgift A skickar uppgift B till samma pool och anropar future.get() — om poolen är uttömd väntar uppgift A på uppgift B och uppgift B kan inte utföras eftersom det inte finns några lediga trådar. Lösning: använd separata pooler för olika uppgiftsnivåer eller asynkron callback istället för blockerande .get().

// Deadlock i Thread Pool
val pool = Executors.newFixedThreadPool(1)

// Uppgift A väntar på uppgift B — deadlock!
val futureA = pool.submit {
    // Denna uppgift kommer aldrig att utföras
    val futureB = pool.submit { 42 }
    futureB.get() // Blockerad för evigt
}

// Åtgärd: separata pooler
val workerPool = Executors.newFixedThreadPool(2)
val callbackPool = Executors.newSingleThreadExecutor()

workerPool.submit {
    callbackPool.submit {
        // Utförs i separat pool — deadlock omöjlig
    }
}

// Eller använd CompletableFuture
workerPool.submit {
    CompletableFuture
        .supplyAsync { 42 }
        .thenAccept { result ->
            println(result)
        }
}

Oavslutad pool och läckor

ExecutorService skapad i Activity måste avslutas i onDestroy(). Om detta inte görs kommer trådarna att finnas kvar i minnet även efter att Activity förstörts. Lösning: förvara poolen i Application scope eller ViewModel, inte i Activity. För korutiner, använd viewModelScope eller lifecycleScope. Om poolen skapades inuti Activity, se till att anropa pool.shutdown() i onDestroy(). För testning, använd es.shutdownNow() för omedelbar stopp.