Kotlin concurrence : threads, coroutines et async/await pour débutants

Kotlin vs Python : qui l'emporte ? La bataille de la concurrence

Si vous lisez ce contenu sur PythonLib, vous connaissez probablement déjà Python et son GIL (Global Interpreter Lock), qui transforme le multithreading en casse-tête. Vous écrivez du threading, vous espérez un gain de vitesse, et vous obtenez… du code synchrone avec un arrière-goût de verrous. Cela vous dit quelque chose ?

Bienvenue dans le monde de Kotlin ! C'est un langage qui a décidé : « Faisons de la concurrence quelque chose de pratique, rapide et sans douleur ». Dans cet article, nous allons explorer trois approches de la concurrence en Kotlin : les threads classiques, les coroutines modernes et le puissant duo async/await. Vous apprendrez à écrire du code asynchrone qui ne vous fera pas exploser la tête, et pourquoi Kotlin est un excellent choix pour le développement backend et Android.

1. Les threads en Kotlin : un vieil ami vaut-il mieux que deux nouveaux ?

Commençons par les bases. Les threads en Kotlin sont les mêmes threads qu'en Java. Kotlin fonctionne sur la JVM, vous avez donc accès à toute la puissance de java.lang.Thread. Mais soyons honnêtes : les threads, c'est comme conduire une voiture sans airbags. Ça marche, mais c'est effrayant.

Comment créer un thread en Kotlin ?

La méthode la plus simple :

fun main() {\n    thread {\n        println("Bonjour depuis le thread : ${Thread.currentThread().name}")\n    }\n    println("Thread principal : ${Thread.currentThread().name}")\n}

Cela vous semble familier, n'est-ce pas ? Mais il y a un hic : les threads sont lourds. Chaque thread est une ressource système distincte. Si vous créez 10 000 threads, votre programme plantera avec une OutOfMemoryError ou ralentira comme un vieil ordinateur sous Windows 95.

Problèmes des threads :

\n
• Consommation mémoire élevée — chaque thread réserve une pile (~1 Mo).
\n
• Complexité de la synchronisation — verrous, interblocages, conditions de concurrence. Souvenez-vous du synchronized en Java et pleurez.
\n
• Changement de contexte — le système d'exploitation perd du temps à basculer entre les threads.
\n

Pour les petits projets, les threads peuvent suffire. Mais si vous construisez un service à forte charge ou une application avec des milliers de tâches parallèles, il est temps de vous tourner vers les coroutines.

2. Les coroutines en Kotlin : légères comme une plume

Les coroutines sont des « threads sous stéroïdes ». Elles ne sont pas liées aux threads système et peuvent s'exécuter sur un seul thread, en basculant entre les tâches sans intervention du système d'exploitation. Cela semble compliqué ? En pratique, c'est simple et élégant.

Première coroutine

Pour travailler avec les coroutines, vous aurez besoin de la dépendance kotlinx-coroutines-core. Mais si vous utilisez Kotlin 1.3+, elle est déjà intégrée.

import kotlinx.coroutines.*\n\nfun main() = runBlocking {\n    launch {\n        delay(1000L)\n        println("Monde après le délai !")\n    }\n    println("Bonjour,")\n}

Que se passe-t-il ici ?

\n
• runBlocking — bloque le thread principal jusqu'à ce que toutes les coroutines à l'intérieur soient terminées. Pour l'apprentissage, c'est ok ; pour la production, utilisez-le avec précaution.
\n
• launch — lance une nouvelle coroutine. Elle ne bloque pas le thread, mais se suspend simplement sur delay.
\n
• delay — équivalent de Thread.sleep(), mais non bloquant. La coroutine « s'endort » et libère le thread pour d'autres tâches.
\n

Résultat : d'abord « Bonjour, » s'affiche, puis une seconde plus tard « Monde après le délai ! ». Sans verrous, sans threads superflus.

Pourquoi les coroutines sont-elles meilleures que les threads ?

\n
• Légèreté — Un million de coroutines ? Facile ! Elles ne créent pas de threads séparés.
\n
• Suspension — Une coroutine peut s'arrêter à tout moment et reprendre plus tard.
\n
• Concurrence structurée — Les coroutines vivent dans une portée (scope) et sont automatiquement annulées si la portée se termine.
\n

Les dispatchers