Pourquoi « recover » ne parvient-il pas à gérer les plantages de modifications simultanées de la carte dans Go ?

Gestion des modifications simultanées de la carte : un dilemme de récupération ou de crash d'exécution

Lorsqu'il s'agit d'un accès simultané à la carte, on peut rencontrer une situation particulière où se remettre d'une panique de type "lecture et écriture de carte simultanées" semble futile. En effet, le comportement du runtime dans de tels cas n'est pas une panique mais un crash délibéré.

Dans Go 1.6, le runtime a introduit un mécanisme de détection d'une utilisation abusive simultanée des cartes. Si plusieurs goroutines tentent de modifier une carte simultanément, le runtime déclenche un crash, imprimant un message de diagnostic. Ce comportement découle du danger inhérent d'un comportement potentiel non défini lorsque les cartes sont consultées simultanément pour des opérations d'écriture.

Malheureusement, l'approche typique consistant à utiliser defer avec recovery pour gérer les paniques est inefficace dans ce scénario. La fonction de récupération ne peut pas intercepter le crash déclenché par le runtime. La solution recommandée est d'empêcher complètement l'utilisation abusive simultanée des cartes.

Dans l'exemple fourni :

package main

import "time"

var m = make(map[string]string)

func main() {
    go func() {
        for {
            m["x"] = "foo"
        }
    }()
    go func() {
        for {
            m["x"] = "foo"
        }
    }()

    time.Sleep(1 * time.Second)
}

Les écritures simultanées sur la carte "m" déclencheront le crash d'exécution. Pour éviter cela, il faudrait utiliser des mécanismes de synchronisation, tels que l'utilisation d'un mutex ou d'un canal, pour garantir un accès exclusif à la carte pendant les opérations d'écriture.

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!