网站首页 返回列表像“草根”一样，紧贴着地面，低调的存在，冬去春来，枯荣无恙。

goroutine与panic不得不说的故事

2020-06-10 02:55:03 admin 582

图片发自简书App

>
> 我之前对golang还了解的极其肤浅的时候，就已经对goroutine如雷贯耳了，我相信很多同学跟我一样，会以为在go代码中，goroutine的身影随处可见，事实上并不是这样。

这两天参与了金融部门的一个小项目，把一个老系统中的小模块从php代码重构成golang。因为负责重构的同事之前只有php经验，所以派我和另外一个同事去帮忙。今早总监过来看看进度，无意中看了眼我的代码，立刻给我指出了一个严重bug，让我发现了一个知识盲点，我觉得值得分享一下。

### 过程

昨天下午写了一个`grpc`接口，根据`user_id`从数据库查询一张`user_config`表，拿到一个`city_ids`字段，是个`city_id`组成的字符串，然后`split`处理后查`city`表取城市数据，大概过程类似这样：

说白了就是个`has_many`关系。因为`city`表几乎不会变化，早上来了公司，我觉得可以加个缓存，所以改成了：

func GetCities(userID int64) ([]*cityData, error) {
        var (
            strCityIDs string 
            CityIDs []string
            ret []*cityData
        )
        strCityIDs, _ = userConfig.GetCityIDs(userID) //从user_config表查询city_id字段
        err := cache.Get(prefix+strCityIDs, &ret) //先从缓存拿数据
        if err == nil {
            return ret, nil
        }
        CityIDs = strings.Split(strCityIDs, sep) //处理成id数组
        err = city.Find(CityIDs, &ret) //从city表查出数据
        if err == nil {
            ok := cache.Set(prefix+strCityIDs, &ret, 12*time.Hour) //存入缓存
            if !ok {
                doNothing()
            }
        }
        return ret, err
    }

改完后“灵机”一动，想起自己几乎没在公司项目中看到过`go`关键字的出现，自己也基本没在生产中实际用过`goroutine`，于是把`cache.Set`改成了`go
cache.Set`。我觉得存入缓存成功与否并不影响主流程(即便失败其实我也什么都不做)，所以完全可以交给协程去做，而且这样主`goroutine`可以返回的更快。  
这时总监过来了。  
聊了两句，突然指着代码跟我说：“这里不对，不能用协程！”  
我：“为啥啊？”  
总监：“因为协程里面发生panic会让整个进程crash。”  
我更加迷惑了：“但是我在middleware里加了recover啊，会抓到panic的。”  
`middleware`代码：

func (*Interceptor) Method(ctx context.Context, srvInfo *core.SrvInfo, req interface{}, handler func(context.Context, interface{}) (interface{}, error)) (ret interface{}, err error) {
        defer func() {
            if p := recover(); p != nil {
                err = fmt.Errorf("internal error: %v", p)
            }
        }()
        ret, err = handler(ctx, req) //所有下层逻辑全部在这个函数里分发，所以我错误地认为任何panic都能在这里recover
        return ret, err
    }

总监：“goroutine发生panic，只有自身能够recover，其它goroutine是抓不到的，这是常识啊。”  
我：“......”  
吓的我啥也没敢再说，赶紧把`go`关键字删了，然后等总监走了之后，立马上网研究了一波goroutine、panic、recover之间的关系，下面是结论。

### 结论

首先，要明确一点，`panic`会停止整个进程，不仅仅是当前`goroutine`，也就是说整个程序都会凉凉（我现在认为这就是`goroutine`没有在代码里泛滥的原因之一，另外的原因是，我觉得在`cpu`核全部跑起来的情况下，开再多的`goroutine`也只能并发而不能并行）。  
其次，`panic`是有序的、可控的停止程序，不是啪唧一下就宕掉了，所以我们还可以用`recover`补救。  
然后，`recover`只能在`defer`里面生效，如果不是在`defer`里调用，会直接返回`nil`。  
最后，很重要的一点是：`goroutine`发生`panic`时，只会调用自身的`defer`，所以即便主`goroutine`里写了`recover`逻辑，也无法拯救到其它`goroutine`里的`panic`。  
所以呢，之前的`go cache.Set`写法是很危险的，因为`cache`里没有做任何`recover`，一旦出现`panic`，会影响到整个系统。  
假设我一定装这个逼用`go`关键字实现（显然我不是这样的人），代码可以改成：

go func() {
        defer func() {
            if r := recover(); r != nil {
                fmt.Println("don't worry, I can take care of myself")
            }
        }()
        cache.Set(prefix+strCityIDs, &ret, 12*time.Hour) //存入缓存
    }()

转载文章，原文链接： goroutine与panic不得不说的故事

关键字词goroutine panic

分享到：

上一篇：beego开发轻博客——第五讲文章录入

下一篇：beego开发轻博客——第三讲项目整合(三)

如需留言，请登录，没有账号？请注册

0 条评论 0 人参与

网站首页 返回列表像“草根”一样，紧贴着地面，低调的存在，冬去春来，枯荣无恙。

goroutine与panic不得不说的故事

admin 1年前

zhou 2年前

zhou 2年前

zhou 2年前

zhou 2年前

网站首页 返回列表 像“草根”一样，紧贴着地面，低调的存在，冬去春来，枯荣无恙。

goroutine与panic不得不说的故事

admin 官方 1年前

zhou 2年前

zhou 2年前

zhou 2年前

zhou 2年前

网站首页返回列表像“草根”一样，紧贴着地面，低调的存在，冬去春来，枯荣无恙。

admin 1年前