Explication détaillée du contexte en langage Go-Golang-php.cn

Explication détaillée du contexte en langage Go

1. Qu'est-ce que le contexte ?

Avant Go 1.7, le contexte n'était pas compilé et existait dans le package golang.org/x/net/context.

Plus tard, l'équipe Golang a découvert que le contexte était assez facile à utiliser, elle a donc incorporé le contexte dans la bibliothèque standard de Go 1.7.

Contexte, aussi appelé contexte, son interface est définie comme suit

type Context interface {
    Deadline() (deadline time.Time, ok bool)
    Done() <-chan struct{}
    Err() error
    Value(key interface{}) interface{}
}

Copier après la connexion

Vous pouvez voir que l'interface Contexte possède 4 méthodes au total

Deadline : le premier renvoyé La valeur est Date limite À ce moment-là, le contexte déclenchera automatiquement l'action Annuler. La deuxième valeur renvoyée est une valeur booléenne. True signifie que la date limite est définie, false signifie que la date limite n'est pas définie. Si la date limite n'est pas définie, la fonction d'annulation doit être appelée manuellement pour annuler le contexte.
Done : renvoie un canal en lecture seule (ne sera renvoyé qu'après avoir été annulé), le type est struct{}. Lorsque ce canal est lisible, cela signifie que le contexte parent a initié une demande d'annulation. Sur la base de ce signal, le développeur peut effectuer certaines actions de nettoyage et quitter la goroutine.
Err : Renvoie la raison pour laquelle le contexte a été annulé.
Value : renvoie la valeur liée au contexte, qui est une paire clé-valeur, de sorte que la valeur correspondante peut être obtenue via une clé. Cette valeur est généralement thread-safe.

2. Pourquoi le contexte est-il nécessaire ?

Quand une goroutine est ouverte, on ne peut pas la forcer à se fermer.

Les raisons courantes de fermeture des coroutines sont les suivantes :

goroutine termine son exécution et se ferme tout seul
Le processus principal plante et se ferme, et goroutine est obligé de quitter
Envoyer un signal via le canal pour guider la fermeture de la coroutine.

Le premier type est un arrêt normal et n’entre pas dans le cadre de la discussion d’aujourd’hui.

Le deuxième type est un arrêt anormal et le code doit être optimisé.

La troisième méthode est que les développeurs peuvent contrôler manuellement la coroutine. L'exemple de code est le suivant :

func main() {
    stop := make(chan bool)

    go func() {
        for {
            select {
            case <-stop:
                fmt.Println("监控退出，停止了...")
                return
            default:
                fmt.Println("goroutine监控中...")
                time.Sleep(2 * time.Second)
            }
        }
    }()

    time.Sleep(10 * time.Second)
    fmt.Println("可以了，通知监控停止")
    stop<- true
    //为了检测监控过是否停止，如果没有监控输出，就表示停止了
    time.Sleep(5 * time.Second)

}

Copier après la connexion

Dans l'exemple, nous définissons un stop chan pour lui notifier de mettre fin à l'arrière-plan. goroutine. L'implémentation est également très simple. Dans la goroutine d'arrière-plan, utilisez select pour déterminer si stop peut recevoir la valeur, cela signifie qu'elle peut quitter et s'arrêter si elle n'est pas reçue, la logique de surveillance entre. default sera exécuté. Continuez à surveiller jusqu'à ce que vous receviez une notification stop.

Ce qui précède est un scénario de goroutine. Que se passe-t-il s'il y a plusieurs goroutines et que plusieurs scénarios de goroutine sont ouverts sous chaque goroutine ? Dans le blog de Feixue Qingqing expliquant pourquoi utiliser Context, il a dit ceci :

La méthode chan+select est une manière plus élégante de terminer une goroutine, mais cette méthode a également des limites, et s'il y en avait. beaucoup de goroutines qui doivent être contrôlées pour finir ? Et si ces goroutines engendraient d’autres goroutines ? Et s’il y avait des couches infinies de goroutines ? C'est très compliqué. Même si nous définissons de nombreux chans, il sera difficile de résoudre ce problème, car la chaîne de relations de goroutine rend ce scénario très compliqué.

Je ne suis pas tout à fait d'accord avec ce qu'il a dit ici, car je pense que même l'utilisation d'un seul canal peut atteindre l'objectif de contrôler (annuler) plusieurs goroutines. Utilisons un exemple pour le vérifier.

Le principe de cet exemple est le suivant : après avoir utilisé close pour fermer le canal, si le canal n'est pas tamponné, il passera du blocage d'origine au non bloquant, c'est-à-dire lisible, mais la lecture le sera toujours zéro, donc sur la base de cette fonctionnalité, vous pouvez déterminer si la goroutine propriétaire du canal doit être fermée.

package main

import (
    "fmt"
    "time"
)

func monitor(ch chan bool, number int)  {
    for {
        select {
        case v := <-ch:
            // 仅当 ch 通道被 close，或者有数据发过来(无论是true还是false)才会走到这个分支
            fmt.Printf("监控器%v，接收到通道值为：%v，监控结束。\n", number,v)
            return
        default:
            fmt.Printf("监控器%v，正在监控中...\n", number)
            time.Sleep(2 * time.Second)
        }
    }
}

func main() {
    stopSingal := make(chan bool)

    for i :=1 ; i <= 5; i++ {
        go monitor(stopSingal, i)
    }

    time.Sleep( 1 * time.Second)
    // 关闭所有 goroutine
    close(stopSingal)

    // 等待5s，若此时屏幕没有输出 <正在监控中> 就说明所有的goroutine都已经关闭
    time.Sleep( 5 * time.Second)

    fmt.Println("主程序退出！！")

}

Copier après la connexion

Le résultat est le suivant

监控器4，正在监控中...
监控器1，正在监控中...
监控器2，正在监控中...
监控器3，正在监控中...
监控器5，正在监控中...
监控器2，接收到通道值为：false，监控结束。
监控器3，接收到通道值为：false，监控结束。
监控器5，接收到通道值为：false，监控结束。
监控器1，接收到通道值为：false，监控结束。
监控器4，接收到通道值为：false，监控结束。
主程序退出！！

Copier après la connexion

L'exemple ci-dessus montre que lorsque nous définissons un canal sans tampon, si nous voulons fermer toutes les goroutines, nous pouvons utiliser close pour fermer le canal, puis dans toutes les goroutines Vérifiez en permanence si le canal est fermé (le principe est que vous devez conclure un accord selon lequel vous fermerez uniquement le canal et n'enverrez pas d'autres données, sinon l'envoi de données une fois fermera une goroutine, ce qui ne répondra pas à nos attentes, donc il est préférable que vous décidiez si vous souhaitez mettre fin à la goroutine.

Donc, comme vous le voyez ici, en tant que débutant, je n'ai toujours pas trouvé une certaine raison d'utiliser Context, je peux seulement dire que Context est une chose très utile. Son utilisation nous facilite la tâche. avec quelques problèmes en matière de concurrence, mais ce n'est pas indispensable.

En d'autres termes, cela ne résout pas le problème de savoir si peut être utilisé, mais le problème de savoir si est préférable d'utiliser.

3. Utilisez simplement Context

Si vous n'utilisez pas la méthode de fermeture de canal ci-dessus, existe-t-il un autre moyen plus élégant d'y parvenir ?

Oui, c'est de cela que parle cet article Context

J'ai utilisé Context pour modifier l'exemple ci-dessus.

package main

import (
    "context"
    "fmt"
    "time"
)

func monitor(ctx context.Context, number int)  {
    for {
        select {
        // 其实可以写成 case <- ctx.Done()
        // 这里仅是为了让你看到 Done 返回的内容
        case v :=<- ctx.Done():
            fmt.Printf("监控器%v，接收到通道值为：%v，监控结束。\n", number,v)
            return
        default:
            fmt.Printf("监控器%v，正在监控中...\n", number)
            time.Sleep(2 * time.Second)
        }
    }
}

func main() {
    ctx, cancel := context.WithCancel(context.Background())

    for i :=1 ; i <= 5; i++ {
        go monitor(ctx, i)
    }

    time.Sleep( 1 * time.Second)
    // 关闭所有 goroutine
    cancel()

    // 等待5s，若此时屏幕没有输出 <正在监控中> 就说明所有的goroutine都已经关闭
    time.Sleep( 5 * time.Second)

    fmt.Println("主程序退出！！")

}

Copier après la connexion

Le code clé ici ne comporte que trois lignes

第一行：以 context.Background() 为 parent context 定义一个可取消的 context

ctx, cancel := context.WithCancel(context.Background())

Copier après la connexion

第二行：然后你可以在所有的goroutine 里利用 for + select 搭配来不断检查 ctx.Done() 是否可读，可读就说明该 context 已经取消，你可以清理 goroutine 并退出了。

case <- ctx.Done():

Copier après la connexion

第三行：当你想到取消 context 的时候，只要调用一下 cancel 方法即可。这个 cancel 就是我们在创建 ctx 的时候返回的第二个值。

cancel()

Copier après la connexion

运行结果输出如下。可以发现我们实现了和 close 通道一样的效果。

监控器3，正在监控中...
监控器4，正在监控中...
监控器1，正在监控中...
监控器2，正在监控中...
监控器2，接收到通道值为：{}，监控结束。
监控器5，接收到通道值为：{}，监控结束。
监控器4，接收到通道值为：{}，监控结束。
监控器1，接收到通道值为：{}，监控结束。
监控器3，接收到通道值为：{}，监控结束。
主程序退出！！

Copier après la connexion

4. 根Context 是什么？

创建 Context 必须要指定一个父 Context，当我们要创建第一个Context时该怎么办呢？

不用担心，Go 已经帮我们实现了2个，我们代码中最开始都是以这两个内置的context作为最顶层的parent context，衍生出更多的子Context。

var (
    background = new(emptyCtx)
    todo       = new(emptyCtx)
)

func Background() Context {
    return background
}

func TODO() Context {
    return todo
}

Copier après la connexion

一个是Background，主要用于main函数、初始化以及测试代码中，作为Context这个树结构的最顶层的Context，也就是根Context，它不能被取消。

一个是TODO，如果我们不知道该使用什么Context的时候，可以使用这个，但是实际应用中，暂时还没有使用过这个TODO。

他们两个本质上都是emptyCtx结构体类型，是一个不可取消，没有设置截止时间，没有携带任何值的Context。

type emptyCtx int

func (*emptyCtx) Deadline() (deadline time.Time, ok bool) {
    return
}

func (*emptyCtx) Done() <-chan struct{} {
    return nil
}

func (*emptyCtx) Err() error {
    return nil
}

func (*emptyCtx) Value(key interface{}) interface{} {
    return nil
}

Copier après la connexion

5. Context 的继承衍生

上面在定义我们自己的 Context 时，我们使用的是 WithCancel 这个方法。

除它之外，context 包还有其他几个 With 系列的函数

func WithCancel(parent Context) (ctx Context, cancel CancelFunc)
func WithDeadline(parent Context, deadline time.Time) (Context, CancelFunc)
func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc)
func WithValue(parent Context, key, val interface{}) Context

Copier après la connexion

这四个函数有一个共同的特点，就是第一个参数，都是接收一个父context。

通过一次继承，就多实现了一个功能，比如使用 WithCancel 函数传入根context ，就创建出了一个子 context，该子context 相比父context，就多了一个 cancel context 的功能。

如果此时，我们再以上面的子context（context01）做为父context，并将它做为第一个参数传入WithDeadline函数，获得的子子context（context02），相比子context（context01）而言，又多出了一个超过 deadline 时间后，自动 cancel context 的功能。

接下来我会举例介绍一下这几种 context，其中 WithCancel 在上面已经讲过了，下面就不再举例了

例子 1：WithDeadline

package main

import (
    "context"
    "fmt"
    "time"
)

func monitor(ctx context.Context, number int)  {
    for {
        select {
        case <- ctx.Done():
            fmt.Printf("监控器%v，监控结束。\n", number)
            return
        default:
            fmt.Printf("监控器%v，正在监控中...\n", number)
            time.Sleep(2 * time.Second)
        }
    }
}

func main() {
    ctx01, cancel := context.WithCancel(context.Background())
    ctx02, cancel := context.WithDeadline(ctx01, time.Now().Add(1 * time.Second))

    defer cancel()

    for i :=1 ; i <= 5; i++ {
        go monitor(ctx02, i)
    }

    time.Sleep(5  * time.Second)
    if ctx02.Err() != nil {
        fmt.Println("监控器取消的原因: ", ctx02.Err())
    }

    fmt.Println("主程序退出！！")
}

Copier après la connexion

输出如下

监控器5，正在监控中...
监控器1，正在监控中...
监控器2，正在监控中...
监控器3，正在监控中...
监控器4，正在监控中...
监控器3，监控结束。
监控器4，监控结束。
监控器2，监控结束。
监控器1，监控结束。
监控器5，监控结束。
监控器取消的原因:  context deadline exceeded
主程序退出！！

Copier après la connexion

例子 2：WithTimeout

WithTimeout 和 WithDeadline 使用方法及功能基本一致，都是表示超过一定的时间会自动 cancel context。

唯一不同的地方，我们可以从函数的定义看出

func WithDeadline(parent Context, deadline time.Time) (Context, CancelFunc)

func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc)

Copier après la connexion

WithDeadline 传入的第二个参数是 time.Time 类型，它是一个绝对的时间，意思是在什么时间点超时取消。

而 WithTimeout 传入的第二个参数是 time.Duration 类型，它是一个相对的时间，意思是多长时间后超时取消。

package main

import (
    "context"
    "fmt"
    "time"
)

func monitor(ctx context.Context, number int)  {
    for {
        select {
        case <- ctx.Done():
            fmt.Printf("监控器%v，监控结束。\n", number)
            return
        default:
            fmt.Printf("监控器%v，正在监控中...\n", number)
            time.Sleep(2 * time.Second)
        }
    }
}

func main() {
    ctx01, cancel := context.WithCancel(context.Background())

      // 相比例子1，仅有这一行改动
    ctx02, cancel := context.WithTimeout(ctx01, 1* time.Second)

    defer cancel()

    for i :=1 ; i <= 5; i++ {
        go monitor(ctx02, i)
    }

    time.Sleep(5  * time.Second)
    if ctx02.Err() != nil {
        fmt.Println("监控器取消的原因: ", ctx02.Err())
    }

    fmt.Println("主程序退出！！")
}

Copier après la connexion

输出的结果和上面一样

监控器1，正在监控中...
监控器5，正在监控中...
监控器3，正在监控中...
监控器2，正在监控中...
监控器4，正在监控中...
监控器4，监控结束。
监控器2，监控结束。
监控器5，监控结束。
监控器1，监控结束。
监控器3，监控结束。
监控器取消的原因:  context deadline exceeded
主程序退出！！

Copier après la connexion

例子 3：WithValue

通过Context我们也可以传递一些必须的元数据，这些数据会附加在Context上以供使用。

元数据以 Key-Value 的方式传入，Key 必须有可比性，Value 必须是线程安全的。

还是用上面的例子，以 ctx02 为父 context，再创建一个能携带 value 的ctx03，由于他的父context 是 ctx02，所以 ctx03 也具备超时自动取消的功能。

package main

import (
    "context"
    "fmt"
    "time"
)

func monitor(ctx context.Context, number int)  {
    for {
        select {
        case <- ctx.Done():
            fmt.Printf("监控器%v，监控结束。\n", number)
            return
        default:
              // 获取 item 的值
            value := ctx.Value("item")
            fmt.Printf("监控器%v，正在监控 %v \n", number, value)
            time.Sleep(2 * time.Second)
        }
    }
}

func main() {
    ctx01, cancel := context.WithCancel(context.Background())
    ctx02, cancel := context.WithTimeout(ctx01, 1* time.Second)
    ctx03 := context.WithValue(ctx02, "item", "CPU")

    defer cancel()

    for i :=1 ; i <= 5; i++ {
        go monitor(ctx03, i)
    }

    time.Sleep(5  * time.Second)
    if ctx02.Err() != nil {
        fmt.Println("监控器取消的原因: ", ctx02.Err())
    }

    fmt.Println("主程序退出！！")
}

Copier après la connexion

输出如下

监控器4，正在监控 CPU 
监控器5，正在监控 CPU 
监控器1，正在监控 CPU 
监控器3，正在监控 CPU 
监控器2，正在监控 CPU 
监控器2，监控结束。
监控器5，监控结束。
监控器3，监控结束。
监控器1，监控结束。
监控器4，监控结束。
监控器取消的原因:  context deadline exceeded
主程序退出！！

Copier après la connexion

6. Context 使用注意事项

通常 Context 都是做为函数的第一个参数进行传递（规范性做法），并且变量名建议统一叫 ctx
Context 是线程安全的，可以放心地在多个 goroutine 中使用。
当你把 Context 传递给多个 goroutine 使用时，只要执行一次 cancel 操作，所有的 goroutine 就可以收到取消的信号
不要把原本可以由函数参数来传递的变量，交给 Context 的 Value 来传递。
当一个函数需要接收一个 Context 时，但是此时你还不知道要传递什么 Context 时，可以先用 context.TODO 来代替，而不要选择传递一个 nil。
当一个 Context 被 cancel 时，继承自该 Context 的所有子 Context 都会被 cancel。

推荐教程：《Go教程》

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!