J'ai la question de ce code.
https: // kotlinlang. org / docs / reference / coroutines / basics.html
fun main() {
GlobalScope.launch { // launch new coroutine in background and continue
Thread.sleep(1000L)
println("World!")
}
println("Hello,") //
Thread.sleep(2000L) // block main thread for 2 seconds to keep JVM alive
}
Je remplace delay (1000L) par Thread.sleep (1000L). Si le bloc GlobalScope.launch s'exécute dans le même thread, Thread.sleep (1000L) bloquera le thread. Cependant, il semble que non.
fun main() {
GlobalScope.launch { // launch new coroutine in background and continue
delay(1000L) // non-blocking delay for 1 second (default time unit is ms)
println("World!") // print after delay
}
println("Hello,") // main thread continues while coroutine is delayed
Thread.sleep(2000L) // block main thread for 2 seconds to keep JVM alive
}
3 Réponses :
GlobalScope.launch {} ne créera pas nécessairement un nouveau thread, mais il en utilisera un à partir d'un pool partagé car il utilise le code Default répartiteur. Donc, en ce qui concerne votre question, dans votre extrait de code, le blocage passé pour lancer s'exécute dans un fil différent.
Dans la documentation sur répartiteurs et les fils , vous trouverez ce qui suit:
Le répartiteur par défaut, utilisé lorsque les coroutines sont lancées dans GlobalScope, est représenté par Dispatchers.Default et utilise un pool de threads en arrière-plan partagé
Et dans le Dispatchers.Default doc , vous pouvez trouver:
Par défaut, le niveau maximal de parallélisme utilisé par ce répartiteur est égal au nombre de cœurs CPU, mais il est au moins égal à deux. Niveau de parallélisme X garantit que pas plus de X tâches peuvent être exécutées dans ce répartiteur en parallèle.
Notez que vous pouvez modifier le répartiteur en en fournissant un comme paramètre de launch .
"mais il en utilisera un d'une piscine partagée". Voulez-vous dire que GlobalScope.launch {} s'exécute dans un autre thread, si le processeur a au moins 2 cœurs?
Pas vraiment. En fait, le pool contient au moins 2 threads, même pour les processeurs à code unique. C'est ce que dit le doc si j'ai bien compris.
La fonction GlobalScope.launch {..} ne se bloquera pas. Il renvoie un objet Job , que vous pouvez utiliser pour attendre un résultat.
Dans les coulisses, le GlobalScope utilise le répartiteur par défaut Dispatchers.Default . Vous pouvez le voir, par exemple, en imprimant un nom de thread dans une fonction launch {..} .
Vous devrez exécuter plus de coroutines pour les voir se bloquer mutuellement à cause des appels de Thread.sleep .
https://kotlinlang.org/docs/reference /coroutines/coroutine-context-and-dispatchers.html
Le GlobalScope vous permet de démarrer des coroutines qui ont plus ou moins le même comportement que threads démons car ils sont détachés de tout Job Coroutine et s'exécutent essentiellement aussi longtemps que l'application. Leur cycle de vie n'est limité que par l'application elle-même. C'est quelque chose que vous voulez éviter en utilisant " structuré concurrence "ce qui signifie essentiellement que vos coroutines doivent être imbriquées de manière à pouvoir les contrôler sans suivre manuellement leurs références et les joindre par exemple pour attendre leurs calculs. Donc, dans votre code réel, vous devriez éviter autant que possible GlobalScope , car il y a certainement une meilleure solution.
En ce qui concerne votre question, et comme déjà mentionné, le GlobalScope fonctionne sur le pool Dispatchers.Default , ce qui signifie que vous allez bloquer certains threads de travail mais pas celui à partir duquel vous avez généré la coroutine.
D'un autre côté, si vous deviez écrire ce bloc:
fun main() {
runBlocking {
Thread.sleep(1000L)
println("World!")
}
println("Hello,")
Thread.sleep(2000L)
}
vous ' Je vais voir que la coroutine bloque le thread principal et la sortie affichera un résultat différent. En effet, runBlocking s'exécute sur le thread de l'appelant main plutôt que sur l'un des threads du pool de nœuds de calcul.
Je l'ai trouvé. Dans les 2 exemples, GlobalScope.launch s'exécute dans un thread différent.