Le programme Go se termine avant la fin du travail de goroutine

Dans cet article, l'éditeur php Xiaoxin présentera un problème important concernant les programmes Go : la situation de sortie avant que le travail de goroutine ne soit terminé. Dans le langage Go, goroutine est un thread léger qui peut exécuter des tâches simultanément. Cependant, lorsque notre programme peut se terminer avant la fin du travail goroutine, nous devons comprendre comment gérer cette situation pour garantir que notre programme peut terminer la tâche correctement. Dans le contenu suivant, nous explorerons ce problème et proposerons quelques solutions pour le résoudre.

Contenu de la question

J'ai du mal à comprendre comment bloquer et fermer correctement les chaînes. Je démarre un nombre arbitraire de travailleurs et je constate que ma fonction principale se termine avant la fin des travailleurs ou se bloque en raison de canaux non fermés. J'ai besoin d'un meilleur moyen d'empêcher le travailleur de lire le canal sans quitter le canal principal, puis de fermer gracieusement le canal une fois terminé pour mettre fin à la boucle. Toutes mes tentatives aboutissent à une impasse.

J'ai essayé plusieurs choses, notamment utiliser un groupe d'attente, mais le problème persiste. J'ai remarqué qu'en ajoutant time.sleep le programme fonctionne comme prévu, mais le commenter n'entraîne aucun travail.

time.sleep(time.duration(10 * time.second))

Voici un exemple fonctionnel https://go.dev/play/p/qhqnj-ajqbi avec sleep préservé. Il s'agit du code cassé avec le délai d'attente de mise en veille commenté.

package main

import (
    "fmt"
    "sync"
    "time"
)

// some complicated work
func do(num int, ch chan<- int) {
    time.sleep(time.duration(500 * time.millisecond))
    ch <- num
}

func main() {

    results := make(chan int)

    // for some number of required complicated work
    for i := 0; i < 53; i++ {
        go do(i, results)
    }

    var wg sync.waitgroup

    // start 3 workers which can process results
    for i := 0; i < 3; i++ {
        wg.add(1)
        go func(id int) {
            defer wg.done()
            worker(id, results)
        }(i)
    }

    // handle closing the channel when all workers complete
    go func() {
        wg.wait()
        close(results)
    }()

    //time.sleep(time.duration(10 * time.second))

    fmt.println("donezo")
}

// process the results of do() in a meaningful way
func worker(id int, ch <-chan int) {
    fmt.println("starting worker", id)

    for i := range ch {
        fmt.println("channel val:", i)
    }
}

J'ai aussi essayé de mettre defer wg.done() 移动到 worker() à l'intérieur de func mais c'est le même problème et ne fonctionne pas sans dormir.

// process the results of do() in a meaningful way
func worker(wg *sync.WaitGroup, id int, ch <-chan int) {
    fmt.Println("starting worker", id)

    defer wg.Done()

    for i := range ch {
        fmt.Println("channel val:", i)
    }
}

Ai-je choisi le mauvais paradigme, ou est-ce que j'utilise simplement le mauvais paradigme ?

Solution de contournement

J'ai initialement demandé "Puis-je apporter quelques petits ajustements à mon code pour le faire fonctionner ? Ou dois-je repenser cela ? " La réponse que j'ai trouvée est, oui, il y a un petit ajustement.

J'ai dû apprendre un concept de base intéressant sur les canaux : on peut lire les données d'un canal fermé, c'est-à-dire vider le canal. Comme mentionné dans mon exemple d'origine, range ne se termine jamais car je ne trouve pas de bon endroit pour fermer la chaîne, et même lorsque je la force d'une autre manière créative, le programme présente un mauvais comportement

• Quitter sans traiter tout le contenu de la chaîne
• Interblocage ou envoi sur canal fermé

Cela est dû à une différence subtile dans le code "real", où le temps nécessaire pour traiter le contenu de la chaîne est plus long que le temps nécessaire pour remplir la chaîne et les choses sont désynchronisées.

Comme il n'y a pas de moyen pratique et clair dans mon expéditeur pour fermer la chaîne (ce qui est recommandé dans 99 % des didacticiels de chaîne), lorsque plusieurs travailleurs lisent la chaîne et que les travailleurs ne le savent pas, par goroutine dans C'est en fait Il est acceptable de le faire dans main où la dernière valeur est lue.

Solution

J'ai enveloppé le travailleur dans son propre sync.waitgroup et j'ai utilisé worker.wait() pour sync.waitgroup 中，并使用 worker.wait() 来阻止程序退出，从而允许工作“完成” ”。当没有更多数据要发送时，我独立地 close()

empêcher

le programme de se fermer, permettant ainsi au travail de "se terminer". ". Lorsqu'il n'y a plus de données à envoyer, je ferme() les canaux indépendamment, c'est à dire que je bloque en attendant que l'écrivain ait fini d'utiliser son propre groupe d'attente. close fournit une terminaison pour le cas des boucles de plage , car lorsque la valeur par défaut du canal est renvoyée, c'est-à-dire que le type eof est renvoyé lorsque la fin du canal est atteinte, il cessera de bloquer le canal d'intersection jusqu'à sa fermeture . workers.wait()Mon point de vue est que si vous ne savez pas combien de valeurs seront poussées en parallèle, go n'a aucun moyen de connaître la longueur du canal sans tampon car il est dans la portée,

jusqu'à ce que vous le fermiez.

. Puisqu'il est fermé, cela signifie lire tout ce qui reste jusqu'à la valeur de terminaison ou la fin. bloquera jusqu'à ce qu'il soit terminé.

Exemples d'opérations résolues

https://www.php.cn/link/2bf0ccdbb4d3ebbcb990af74bd78c658

Exemple de lecture d'une chaîne fermée

https://www.php.cn/link/d5397f1497b5cdaad7253fdc92db610b

🎜 🎜Sortie🎜

filling 0
filling 1
filling 2
filling 3
filling 4
filling 5
filling 6
filling 7
filling 8
filling 9
closed
empyting 0
empyting 1
empyting 2
empyting 3
empyting 4
empyting 5
empyting 6
empyting 7
empyting 8
empyting 9

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!