Thread dans le développement mobile — qu'est-ce que c'est, types et gestion des threads

Qu'est-ce qu'un Thread

Thread (fil d'exécution) — est une séquence d'instructions indépendante que le système d'exploitation peut planifier sur un cœur de CPU. Chaque processus (application) contient au moins un thread — le Main Thread. Des threads supplémentaires sont créés pour l'exécution parallèle des tâches. Chaque thread possède sa propre pile logicielle (avec des variables locales), un compteur ordinal (PC) et des registres. La mémoire tas (heap) est partagée par tous les threads du processus.

Dans les systèmes d'exploitation mobiles, les threads sont planifiés par multitâche préemptif (preemptive multitasking) : l'OS peut interrompre l'exécution d'un thread à tout moment et passer la main à un autre (context switch). Le changement de contexte est une opération coûteuse (1-10 microsecondes), car elle nécessite la sauvegarde et la restauration des registres du CPU, la mise à jour du TLB et la vidange des caches. C'est pourquoi un nombre excessif de threads (centaines ou milliers) dégrade les performances — l'OS consacre plus de temps aux changements de contexte qu'à l'exécution.

Thread et processus — sont des concepts différents. Un processus est une instance d'application avec une mémoire virtuelle dédiée. Un thread à l'intérieur d'un processus partage cette mémoire avec d'autres threads. Sous Android, chaque composant d'application (Activity, Service, BroadcastReceiver) fonctionne dans un seul processus, mais peut s'exécuter sur différents threads. Une application iOS est également un seul processus avec la possibilité de créer des threads supplémentaires via GCD ou Thread.

Cycle de vie d'un thread : états et transitions

Chaque thread en Java/Kotlin (Android) et NSThread (iOS) passe par cinq états : New (créé), Runnable (prêt à s'exécuter), Running (s'exécute sur le CPU), Blocked/Waiting (attend une ressource ou une notification), Terminated (terminé). Les transitions entre les états sont gérées par l'ordonnanceur de l'OS et les primitives de synchronisation. Le développeur peut influencer la priorité du thread (Thread.setPriority()) et son état (sleep, join, interrupt).

Sous Android, un thread passe à l'état Blocked lors d'une tentative d'acquisition d'un moniteur occupé (synchronized), d'un appel à Object.wait() ou Thread.sleep(). Sous iOS — lors d'un appel à NSCondition.wait(), pthread_cond_wait() ou dispatch_semaphore_wait(). Dans l'état Blocked, le thread ne consomme pas de CPU, mais occupe de la mémoire (pile). Un thread peut être interrompu (interrupted) depuis un autre thread, recevant InterruptedException (Java) ou vérifiant isCancelled (Kotlin Coroutines).

Context Switch et son coût

Context switch (changement de contexte) — opération par laquelle l'OS sauvegarde l'état du thread actuel (registres, PC, TLB) et charge l'état sauvegardé d'un autre. Dans les systèmes mobiles (Linux + ART, XNU pour iOS), un context switch prend 1 à 10 microsecondes. Si un thread exécute une tâche en 100 microsecondes et que le context switch en prend 5, alors 5 % du temps est perdu. Pour minimiser les context switches, iOS utilise GCD avec vol de travail (work stealing), Android — des pools avec fixedThreadCount.

Thread sous Android : de Thread à Coroutines

Android a évolué du java.lang.Thread bas niveau aux coroutines modernes. Chaque niveau d'abstraction offre plus de possibilités avec moins de frais généraux. Thread est la classe de base, mais sa création directe n'est pas recommandée : un nouveau thread n'est pas géré par un pool, il est difficile à surveiller et à annuler. AsyncTask (déprécié depuis l'API 30) était un pas en avant, mais souffrait de fuites mémoire et d'une gestion maladroite des configurations.

HandlerThread est une sous-classe spéciale de Thread avec Looper, qui peut traiter une file d'attente de messages. Il est utilisé pour l'exécution séquentielle de tâches sur un thread d'arrière-plan, par exemple pour écrire des données dans Room ou des fichiers. HandlerThread est créé en appelant start(), après quoi via Handler(handlerThread.looper) on peut envoyer des messages et des Runnable. L'appel handlerThread.quit() arrête le Looper et termine le thread.

// Android : Thread, HandlerThread et Executors
import android.os.Handler
import android.os.HandlerThread
import java.util.concurrent.Executors

class ThreadExample {

    // 1. Création directe de Thread (non recommandée)
    fun directThread() {
        val thread = Thread(Runnable {
            Thread.sleep(1000)
            print("Direct thread executed")
        })
        thread.start()
    }

    // 2. HandlerThread pour les tâches de fond séquentielles
    fun handlerThreadExample() {
        val handlerThread = HandlerThread("BackgroundQueue")
        handlerThread.start()

        val handler = Handler(handlerThread.looper)
        handler.post {
            // Exécution séquentielle sur un thread d'arrière-plan
            Thread.sleep(500)
            print("HandlerThread : tâche terminée")
        }

        // Arrêt du thread (s'exécute lorsque les tâches sont terminées)
        handlerThread.quitSafely()
    }

    // 3. Executors — pool de threads
    fun executorExample() {
        val executor = Executors.newFixedThreadPool(4)
        for (i in 1..10) {
            executor.execute {
                print("Task $i on thread ${Thread.currentThread().getName()}")
            }
        }
        executor.shutdown()
    }

    // 4. Kotlin Coroutines — le standard moderne
    suspend fun coroutineExample() = kotlinx.coroutines.withContext(
        kotlinx.coroutines.Dispatchers.Default
    ) {
        print("Coroutine on thread: ${Thread.currentThread().getName()}")
    }
}

L'exemple ThreadExample montre les quatre niveaux d'abstraction des threads sous Android. La création directe de Thread est l'approche la plus bas niveau et la moins efficace. HandlerThread est utile pour les tâches séquentielles en arrière-plan. Executors.newFixedThreadPool(4) crée un pool de 4 threads pour l'exécution parallèle de jusqu'à 10 tâches. Kotlin Coroutines avec Dispatchers.Default est une méthode moderne, efficace et sûre.

HandlerThread : tâches séquentielles en arrière-plan

HandlerThread est une sous-classe spécialisée de Thread avec un Looper intégré et une file d'attente de messages. Il est créé en appelant start(), après quoi via Handler(handlerThread.looper) on peut envoyer des Runnable et des messages. HandlerThread exécute les tâches strictement séquentiellement — la tâche suivante ne commence pas avant la fin de la précédente. C'est pratique pour écrire des données dans Room ou des fichiers, où l'ordre des opérations est critique. L'appel quitSafely() arrête le Looper après la fin de la tâche en cours.

import Foundation

class ThreadManager {

    // 1. Thread (bas niveau)
    func createThread() {
        let thread = Thread {
            // Le code s'exécute sur un nouveau thread
            print("Current thread: \(Thread.current)")
        }
        thread.name = "com.app.worker"
        thread.qualityOfService = .utility
        thread.start()
    }

    // 2. GCD — DispatchQueue
    func gcdExample() {
        // File d'attente parallèle
        let queue = DispatchQueue(label: "com.app.concurrent",
                                 qos: .utility,
                                 attributes: .concurrent)

        queue.async {
            print("GCD async task")
        }

        // Barrier pour la synchronisation d'écriture
        queue.async(flags: .barrier) {
            // Accès exclusif pendant l'écriture
            print("Barrier write: exclusive access")
        }
    }

    // 3. OperationQueue avec dépendances
    func operationQueueExample() {
        let queue = OperationQueue()
        queue.maxConcurrentOperationCount = 2
        queue.qualityOfService = .background

        let download = BlockOperation {
            print("Downloading...")
        }
        let process = BlockOperation {
            print("Processing...")
        }
        let save = BlockOperation {
            print("Saving...")
        }

        // Dépendances : download -> process -> save
        process.addDependency(download)
        save.addDependency(process)

        queue.addOperations([download, process, save], waitUntilFinished: false)
    }
}

// Collection thread-safe via GCD barrier
class ThreadSafeArray<T> {
    private var array: [T] = []
    private let queue = DispatchQueue(label: "com.app.concurrent",
                                       attributes: .concurrent)

    var count: Int {
        return queue.sync { array.count } // concurrent read
    }

    func append(_ element: T) {
        queue.async(flags: .barrier) { // exclusive write
            self.array.append(element)
        }
    }
}

// Synchronisation dans Android/Kotlin
import java.util.concurrent.atomic.AtomicInteger
import kotlinx.coroutines.sync.Mutex
import kotlinx.coroutines.sync.withLock

class Counter {

    // 1. AtomicInteger — pour les compteurs simples
    private val atomicCount = AtomicInteger(0)
    fun incrementAtomic() = atomicCount.incrementAndGet()

    // 2. synchronized — pour les sections critiques
    @Synchronized
    fun synchronizedOperation() {
        // Un seul thread à la fois
        doWork()
    }

    // 3. Mutex des coroutines — suspend-safe
    private val mutex = Mutex()
    suspend fun mutexOperation() {
        mutex.withLock {
            // protected code — thread-safe
            doWork()
        }
    }

    private fun doWork() { /* critical section */ }
}

// Exemple de deadlock : A verrouille B, B verrouille A
class DeadlockExample {
    private val lockA = Any()
    private val lockB = Any()

    fun methodA() = synchronized(lockA) {
        Thread.sleep(100)
        synchronized(lockB) { print("OK") }
    }

    fun methodB() = synchronized(lockB) {
        Thread.sleep(100)
        synchronized(lockA) { print("OK") }
    }
}