runBlocking — définition, pont bloquant et fonctionnement

Qu'est-ce que runBlocking?

runBlocking est une fonction Kotlin qui crée un nouveau CoroutineScope et exécute la coroutine passée, bloquant le thread actuel jusqu'à son achèvement complet. Contrairement à tous les autres Coroutine Builders, runBlocking n'est pas une fonction suspend et peut être appelé depuis du code synchrone ordinaire. La signature de runBlocking prend un CoroutineContext et un bloc suspend, retournant un résultat de type T.

public fun <T> runBlocking(
    context: CoroutineContext = EmptyCoroutineContext,
    block: suspend CoroutineScope.() -> T
): T

runBlocking lance une nouvelle event-loop sur le thread actuel. Lorsque la coroutine appelle une fonction suspend (par exemple, delay() ou await()), runBlocking bloque le thread et exécute d'autres coroutines planifiées sur le même thread jusqu'à ce que la coroutine suspendue reprenne. C'est ce qu'on appelle le blocage coopératif — le thread n'est pas inactif mais traite d'autres coroutines.

Comment fonctionne runBlocking

Le mécanisme interne de runBlocking est basé sur une event-loop: lors de l'appel d'une fonction suspend, runBlocking met en pause l'exécution du bloc actuel et exécute d'autres coroutines de la file d'attente. Lorsque la fonction suspend se termine, l'exécution reprend. Ce cycle continue jusqu'à ce que toutes les coroutines soient terminées.

Event-loop sous le capot

runBlocking utilise son propre pool mono-thread pour exécuter les coroutines. Contrairement à Dispatchers.IO ou Default, runBlocking ne change pas de thread — il traite toutes les coroutines sur le thread actuel, en entrelaçant leur exécution. C'est le seul constructeur qui garantit l'exécution sur le même thread.

fun main() {
    val threadName = Thread.currentThread().getName()
    println("Avant runBlocking sur $threadName")

    val result = runBlocking {
        println("À l'intérieur de runBlocking sur ${Thread.currentThread().getName()}")
        delay(500L)
        "Done"
    }

    println("Après runBlocking: $result")
}

La sortie montrera que les trois instructions println s'exécutent sur le même thread. runBlocking ne change pas de thread mais organise du multitâche coopératif au sein d'un seul thread à l'aide d'une event-loop.

Quand utiliser runBlocking

runBlocking est justifié dans trois scénarios: le point d'entrée main() dans les applications console, les tests unitaires de fonctions suspend et le pont — appeler du code suspend depuis des bibliothèques basées sur des callbacks ou bloquantes. Dans le code Android de production, son utilisation sur le thread principal est strictement interdite.

Pour les tests Android, utilisez kotlinx-coroutines-test avec TestDispatcher au lieu de runBlocking. Cela offre un contrôle du temps, un nettoyage automatique et un isolement des tests.

Alternatives à runBlocking

Dans la plupart des scénarios, runBlocking peut et doit être remplacé par des alternatives asynchrones. Pour Android, ce sont viewModelScope, lifecycleScope ou CoroutineScope avec le dispatcher approprié. Pour les tests — TestCoroutineDispatcher et runTest.

    // Mauvais: runBlocking sur le thread principal Android
runBlocking(Dispatchers.Main) {
    val result = networkApi.fetchData()
    textView.setText(result)
}

// Bon: lifecycleScope
lifecycleScope.launch {
    val result = withContext(Dispatchers.IO) { networkApi.fetchData() }
    textView.setText(result)
}

Pour les tests, le remplacement est runTest de la bibliothèque kotlinx-coroutines-test. Il crée un TestCoroutineScope avec un temps virtuel, permettant de tester les délais sans attente réelle. Cela accélère les tests et les rend déterministes.

Exemples d'utilisation de runBlocking

Le scénario le plus courant est le test des fonctions suspend. runBlocking dans les tests permet d'attendre de manière synchrone un résultat de coroutine sans changer l'architecture. Le deuxième scénario concerne les bibliothèques avec API de callbacks, où les fonctions suspend sont appelées depuis un contexte bloquant via runBlocking.

// Tester la fonction suspend avec runBlocking
class RepositoryTest {
    @Test
    fun `fetchUser returns correct data`() {
        val repository = UserRepository(FakeApi())

        val result = runBlocking {
            repository.fetchUser("123")
        }

        assertEquals("John", result.name)
        assertEquals("john@test.com", result.email)
    }
}

Pour le pont entre les mondes callback et suspend, utilisez CompletableDeferred en combinaison avec runBlocking au lieu de callbacks — cela simplifie les chaînes d'opérations asynchrones et améliore la lisibilité du code.

Dangers d'une mauvaise utilisation

L'utilisation inappropriée de runBlocking est l'une des erreurs fréquentes lors de la transition d'une approche bloquante vers les coroutines. Principaux problèmes: appel sur le thread principal Android, imbrication de runBlocking, utilisation dans des fonctions asynchrones et exécution d'opérations longues via runBlocking.

• ANR — runBlocking sur le thread principal Android bloque le rendu UI pendant plus de 5 secondes
• Deadlock — runBlocking imbriqué dans une coroutine sur le même thread entraîne un blocage mutuel
• Confusion de dispatchers — Dispatchers.Main dans runBlocking sur un thread d'arrière-plan n'a pas de Looper et lève une exception
• Fuite mémoire — runBlocking n'est pas automatiquement annulé lors de la destruction d'Activity/Fragment

Règle d'or: runBlocking est un pont, pas un remplacement. Utilisez-le uniquement pour connecter les mondes bloquant et non bloquant. Pour toutes les autres tâches, utilisez launch, async ou lifecycleScope.