go之context上下文分析

context初始

之前在使用gin框架的时候就看到过它的出现，当时只是好奇为什么主流程的过程中会出现这么个奇怪的身影，乍一看它并没有参与到业务互动中来，今在go使用mongo的过程中，由于需要自己拓展pool，参考实现过程中发现又出现了它的身影，这回我是要塑造自己的pool，所以再容不得它不清不楚的出现了，上一段代码：

package main

import (
    "context"
    "fmt"
    "log"
    "os"
    "time"
)

const (
    GOLABLE_KEY = "test123"
)

func main() {
    //父context控制子context
    controlAllConrrent()
}

func controlAllConrrent() {

    logg := log.New(os.Stdout, "", log.Ltime)
    handleSome()
    logg.Println("over ")
}

//父协程
func handleSome() {
    //ctx, cancelFunc := context.WithCancel(context.Background())
    //ctx, cancelFunc := context.WithTimeout(context.Background(), time.Second*2)
        
    ctx, cancelFunc := context.WithDeadline(context.Background(), time.Now().Add(time.Second*15)) //@1

    ctx = context.WithValue(ctx, GOLABLE_KEY, "1234")

    go workerFunc(ctx, "str1")
    go workerFunc(ctx, "str2")
    time.Sleep(time.Second * 5)
    
    cancelFunc()
    


}

//子协程
func workerFunc(ctx context.Context, showStr string) {
    for {
        fmt.Println(999)
        time.Sleep(time.Second * 1)
        select {
        case <-ctx.Done():
            log.Println("done")
            return
        default:
            val123 := ctx.Value(GOLABLE_KEY).(string)
            log.Println(val123, showStr)
        }
    }
}

这里简单但有点绕，但其实最想表达的是，如果一个 goroutine (A) 在完成某个任务的时候需要创建10个goroutine (B)共同作业，那么问题来了，A如何控制创建的B们关闭，最直接的方式就是A如果能跟B发生通讯就好了，那么只要A告诉所有的B你们停止，都别运行了，然后B全部停止就完美了，怎么通讯？ context的作用就出现了，在A创建的每一个goroutine(B) 的时候都传一个参数,然后A如果想要跟所有B通讯，只要“作用”这个传进的参数就行了，然后所有B里面整一个机制实时监控参数的动态（一旦变化能够捕获），于是你便发现他们之间真的能够通讯了。

上面的代码就是在表达上面文字表达的意思,但是诈一看吧，我就在想场景，我要它干嘛啊，你看整个select不断的在那监控着，除了保持当前的这个协程执行的函数workerFunc 没有被退出，我没看出它还干了嘛，没有半点实际业务处理啊，那要这样我觉着还真没啥监控的必要，但是：

1. 超时监控:如果 A函数按工厂模式，应该返回我一个结果A，但是返回的这个结果A可能花费时间1S，2S，3S，100S等，出于服务的稳定性我只能告诉你，我不敢用A函数了，虽然你能给我想要的结果，但是时间也太不稳定了，

package main

import (
    "context"
    "fmt"
    "log"
    "os"
    "time"
)

func main() {
    var maxWorkTime time.Duration = 5

    //父context控制子context
    ctx, cancelFunc := context.WithDeadline(context.Background(), time.Now().Add(time.Second * maxWorkTime))
    go workerFunc(ctx, "str1")
}


type result struct {
    Data string
}

//子协程
//对于 workerFunc 这个函数来说是对任务负责，完成了还是没完成
//完成的唯一标准是在  1.规定时间内;2.做完了事情，才叫完成  规定时间由上层安排任务的控制  本处demo是 maxWorkTime为最大任务时间
func workerFunc(ctx context.Context, showStr string) {

    ext :=make(chan result)

    go work(ext)
    
    for {
        time.Sleep(time.Second * 1)
        select {
        case <-ctx.Done():
            log.Println("超时了，没有完成")
            return      
        case t :=<-ext:
            log.Println("在规定时间内出色的完成了 nice")
            log.Println(t.Data,"这是完成任务的结果数据，你可以定制json")
            return
        default:
            log.Println("为了避免select卡住，所以要整一个无return的出口", showStr)
        }
    }
}

func work(ext chan result){
    //耗时者
    time.Sleep(time.Second * 6)
    
    res := new(result)
    res.Data = "终于完成了这个任务，花了我整整6S不知道还来得及及不..."
    ext <- *res
}

归根结底还是思路，context能够让我们的主协程具备与 一次性通知所有 子协程轻松通讯的能力

参考文章:
context介绍分析
总结context作用
我有go写的mongo的资源池就用到了context,有兴趣可以看下,获取mongo客户端时超3s作为超时处理