1. 对创建的gorouting负载

1.1 不要创建一个你不知道何时退出的 goroutine

下面的代码有什么问题? 是不是在我们的程序种经常写类似的代码?


// Week03/blog/01/01.go
package main import (
"log"
"net/http"
_ "net/http/pprof"
) // 初始化函数
func setup() {
// 这里面有一些初始化的操作
} // 入口函数
func main() {
setup() // 主服务
server() // for debug
pprof() select {}
} // http api server
func server() {
go func() {
mux := http.NewServeMux()
mux.HandleFunc("/ping", func(w http.ResponseWriter, r *http.Request) {
w.Write([]byte("pong"))
}) // 主服务
if err := http.ListenAndServe(":8080", mux); err != nil {
log.Panicf("http server err: %+v", err)
return
}
}()
} // 辅助服务,用来debug性能测试
func pprof() {
// 辅助服务,监听了其他端口,这里是 pprof 服务,用于 debug
go http.ListenAndServe(":8081", nil)
}

以上代码有几个问题,是否想到过?

  1. 如果server 是在其他的包里面, 如果没有特殊的说明, 调用者是否知道这是一个异步调用?
  2. main 函数种,最后使用select {} 使整个程序处于阻塞状态,也就是空转, 会不会存在浪费?
  3. 如果线上出现事故,debug服务已经突出,你想要debug这时是否很茫然?
  4. 如果某一天服务突然重启, 你却找不到事故日志, 是否能想到起的这个8801端口的服务呢?

1.1.1 不要帮别人做选择

把是否 并发 的选择权交给你的调用者,而不是自己就直接悄悄的用上了 goroutine

下面做如下改变,将两个函数是否并发操作的选择权留给main函数


package main

import (
"log"
"net/http"
_ "net/http/pprof"
) func setup(){
// 初始化操作
} func main(){ setup() // for debug
go pprof() // 主服务,http api
go server() select{}
} func server(){ mux := http.NewServerMux()
mux.HandleFunc("ping", func(w http.ResponseWriter, r * http.Request){
w.Write([]byte("pong"))
} // 主服务
if err := http.ListerAndServer(":8080",mux); err != nil{
log.panic("http server launch error: %v", err)
return
} } func pprof(){
// 辅助服务 监听其他端口,这里是pprof服务,拥有debug
http.ListerAndServer(":8081",nil)
}

1.1.2 不要作为一个旁观者

一般情况下,不要让 主进程称为一个无所事事的旁观者, 明明可以干活,但是最后使用一个select在那儿空跑,而且这种看着也怪,在没有特殊场景下尽量不要使用这种阻塞的方式


package main

import (
"log"
"net/http"
_ "net/http/pprof"
) func setup() {
// 这里面有一些初始化的操作
} func main() {
setup() // for debug
go pprof() // 主服务, http本来就是一个阻塞的服务
server()
} func server() {
mux := http.NewServeMux()
mux.HandleFunc("/ping", func(w http.ResponseWriter, r *http.Request) {
w.Write([]byte("pong"))
}) // 主服务
if err := http.ListenAndServe(":8080", mux); err != nil {
log.Panicf("http server err: %+v", err)
return
}
} func pprof() {
// 辅助服务,监听了其他端口,这里是 pprof 服务,用于 debug
http.ListenAndServe(":8081", nil)
}

1.1.3 不要创建不知道什么时候退出的 goroutine

很多时候我们在创建一个 协程(goroutine)后就放任不管了,如果程序永远运行下去,可能不会有什么问题,但实际情况并非如此, 我们的产品需要迭代,需要修复bug,需要不停进行构建,发布, 所以当程序退出后(主程序),运行的某些子程序并不会完全退出,比如这个 pprof, 他自身本来就是一个后台服务,但是当 main退出后,实际 pprof这个服务并不会退出,这样 pprof就会称为一个孤魂野鬼,称为一个 zombie, 导致goroutine泄漏。

所以再一次对程序进行修改, 保证 goroutine能正常退出


package main

import (
"context"
"fmt"
"log"
"net/http"
_ "net/http/pprof"
"time"
) func setup() {
// 这里面有一些初始化的操作
} func main() {
setup() // 用于监听服务退出, 这里使用了两个 goroutine,所以 cap 为2
done := make(chan error, 2) // 无缓冲的通道,用于控制服务退出,传入同一个 stop,做到只要有一个服务退出了那么另外一个服务也会随之退出
stop := make(chan struct{}, 0) // for debug
go func() {
// pprof 传递一个 channel
fmt.Println("pprof start...")
done <- pprof(stop)
fmt.Printf("err1:%v\n", done) }() // 主服务
go func() {
fmt.Println("app start...")
done <- app(stop)
fmt.Printf("err2:%v\n", done)
}() // stopped 用于判断当前 stop 的状态
var stopped bool // 这里循环读取 done 这个 channel
// 只要有一个退出了,我们就关闭 stop channel
for i := 0; i < cap(done); i++ { // 对于有缓冲的chan, chan中无值会一直处于阻塞状态
// 对于app 服务会一直阻塞状态,不会有 数据写入到done 通道,只有在5s后,模拟的 pprof会有err写入chan,此时才会触发以下逻辑
if err := <-done; err != nil {
log.Printf("server exit err: %+v", err)
} if !stopped {
stopped = true
// 通过关闭 无缓冲的channel 来通知所有的 读 stop相关的goroutine退出
close(stop)
}
}
} // http 服务
func app(stop <-chan struct{}) error {
mux := http.NewServeMux()
mux.HandleFunc("/ping", func(w http.ResponseWriter, r *http.Request) {
w.Write([]byte("pong"))
}) return server(mux, ":8080", stop)
} func pprof(stop <-chan struct{}) error {
// 注意这里主要是为了模拟服务意外退出,用于验证一个服务退出,其他服务同时退出的场景
// 因为这里没有返回err, 所以done chan中无法接收到值, 主程序中会一直阻塞住
go func() {
server(http.DefaultServeMux, ":8081", stop)
}() time.Sleep(5 * time.Second)
// 模拟出错
return fmt.Errorf("mock pprof exit")
} // 启动一个服务
func server(handler http.Handler, addr string, stop <-chan struct{}) error { s := http.Server{
Handler: handler,
Addr: addr,
} // 这个 goroutine 控制退出,因为 stop channel 只要close或者是写入数据,这里就会退出
go func() {
// 无缓冲channel等待,写入或者关闭
<-stop
log.Printf("server will exiting, addr: %s", addr)
// 此时 httpApi 服务就会优雅的退出
s.Shutdown(context.Background())
}() // 没有触发异常的话,会一直处于阻塞
return s.ListenAndServe()
}

查看以下运行结果

D:\gopath\controlGoExit>go run demo.go
app start...
pprof start...
err1:0xc00004c720
2021/09/12 22:48:37 server exit err: mock pprof exit
2021/09/12 22:48:37 server will exiting, addr: :8080
2021/09/12 22:48:37 server will exiting, addr: :8081
err2:0xc00004c720
2021/09/12 22:48:37 server exit err: http: Server closed

虽然我们已经经过了三轮优化,但是这里还是有一些需要注意的地方:

  1. 虽然我们调用了 Shutdown 方法,但是我们其实并没有实现优雅退出
  2. 在 server 方法中我们并没有处理 panic的逻辑,这里需要处理么?如果需要那该如何处理呢?

1.1.4 不要创建都无法退出的 goroutine

永远无法退出的 goroutine, 即 goroutine 泄漏

下面是一个例子,可能在不知不觉中会用到


package main

import (
"log"
_ "net/http/pprof"
"net/http" ) func setup() {
// 这里面有一些初始化的操作
log.Print("服务启动初始化...")
} func main() {
setup() // for debug
go pprof() // 主服务, http本来就是一个阻塞的服务
server()
} func server() {
mux := http.NewServeMux()
mux.HandleFunc("/ping", func(w http.ResponseWriter, r *http.Request) {
w.Write([]byte("pong"))
}) mux.HandleFunc("/leak", LeakHandle) // 主服务
if err := http.ListenAndServe(":8080", mux); err != nil {
log.Panicf("http server err: %+v", err)
return
}
} func pprof() {
// 辅助服务,监听了其他端口,这里是 pprof 服务,用于 debug
http.ListenAndServe(":8081", nil)
} func LeakHandle(w http.ResponseWriter, r *http.Request) {
ch := make(chan bool, 0)
go func() {
fmt.Println("异步任务做一些操作")
<-ch
}() w.Write([]byte("will leak"))
}

复用一下上面的 server 代码,我们经常会写出这种类似的代码

  • http 请求来了,我们启动一个 goroutine 去做一些耗时一点的工作
  • 然后返回了
  • 然后之前创建的那个 goroutine 阻塞了(对于一个无缓冲的chan,如果没有接收或关闭操作会永远阻塞下去)
  • 然后就泄漏了

绝大部分的 goroutine 泄漏都是因为 goroutine 当中因为各种原因阻塞了,我们在外面也没有控制它退出的方式,所以就泄漏了

接下来我们验证一下是不是真的泄漏了

服务启动之后,访问debug访问网址,http://localhost:8081/debug/pprof/goroutine?debug=1.

当请求两次 http://127.0.0.1/leak后查看 goroutine数量,如图

继续请求三次后,如图

1.1.5 确保创建出的goroutine工作已经完成

这个其实就是优雅退出的问题,程序中可能启动了很多的 goroutine 去处理一些问题,但是服务退出的时候我们并没有考虑到就直接退出了。例如退出前日志没有 flush 到磁盘,我们的请求还没完全关闭,异步 worker 中还有 job 在执行等等。

看一个例子,假设现在有一个埋点服务,每次请求我们都会上报一些信息到埋点服务上

// Reporter 埋点服务上报
type Reporter struct {
} var reporter Reporter // 模拟耗时
func (r Reporter) report(data string) {
time.Sleep(time.Second)
fmt.Printf("report: %s\n", data)
} mux.HandleFunc("/ping", func(w http.ResponseWriter, r *http.Request) {
// 在请求中异步调用
// 这里并没有满足一致性
go reporter.report("ping pong")
fmt.Println("ping")
w.Write([]byte("pong"))
})

在发送一次请后之后就直接退出了, 异步上报的逻辑是没有执行的

$ go tun demo.go
ping
^C signal:interrupt

有两种改法:

  • 一种是给 reporter 加上 shutdown 方法,类似 http 的 shutdown,等待所有的异步上报完成之后,再退出
  • 另外一种是我们直接使用 一些 worker 来执行,在当然这个 worker 也要实现类似 shutdown 的方法。

一般推荐后一种,因为这样可以避免请求量比较大时,创建大量 goroutine,当然如果请求量比较小,不会很大,用第一种也是可以的。

第二种方法代码如下:


// 埋点上报
package main import (
"context"
"fmt"
"log"
"net/http"
"sync"
) // Reporter 埋点服务上报
type Reporter struct {
worker int
messages chan string
wg sync.WaitGroup
closed chan struct{}
once sync.Once
} // NewReporter NewReporter
func NewReporter(worker, buffer int) *Reporter {
return &Reporter{
worker: worker,
messages: make(chan string, buffer),
closed: make(chan struct{}),
}
} // 执行上报
func (r *Reporter) Run(stop <-chan struct{}) {
// 用于执行错误
go func() {
// 没有错误时
<-stop
fmt.Println("stop...")
r.shutdown()
}() for i := 0; i < r.worker; i++ {
r.wg.Add(1) go func() {
defer r.wg.Done()
for {
select {
case <-r.closed:
return
case msg := <-r.messages:
fmt.Printf("report: %s\n", msg)
}
}
}()
} r.wg.Wait()
fmt.Println("report workers exit...")
} // 这里不必关闭 messages
// 因为 closed 关闭之后,发送端会直接丢弃数据不再发送
// Run 方法中的消费者也会退出
// Run 方法会随之退出
func (r *Reporter) shutdown() {
r.once.Do(func() { close(r.closed) })
} // 模拟耗时
func (r *Reporter) Report(data string) {
// 这个是为了及早退出
// 并且为了避免我们消费者能力很强,发送者这边一直不阻塞,可能还会一直写数据
select {
case <-r.closed:
fmt.Printf("reporter is closed, data will be discarded: %s \n", data)
default:
} select {
case <-r.closed:
fmt.Printf("reporter is closed, data will be discarded: %s \n", data)
case r.messages <- data:
}
} func setup3() {
// 初始化一些操作
fmt.Println("程序启动...")
} func main() {
setup3() // 用于监听服务完成时退出
done := make(chan error, 3) // 实例化一个 reporter
reporter := NewReporter(2, 100) // 用于控制服务退出,传入同一个 stop,做到只要有一个服务退出了那么另外一个服务也会随之退出
stop := make(chan struct{}, 0) // for debug
go func() {
done <- pprof3(stop)
}() // http主服务
go func() {
done <- app3(reporter, stop)
}() // 上报服务,接收一个监控停止的 chan
go func() {
reporter.Run(stop)
done <- nil
}() // 这里循环读取 done 这个 channel
// 只要有一个退出了,我们就关闭 stop channel
for i := 0; i < cap(done); i++ { // 对于有缓冲的chan, chan中无值会一直处于阻塞状态
// 对于app 服务会一直阻塞状态,不会有 数据写入到done 通道,只有在5s后,模拟的 pprof会有err写入chan,此时才会触发以下逻辑
if err := <-done; err != nil {
log.Printf("server exit err: %+v", err)
}
// 通过关闭 无缓冲的channel 来通知所有的 读 stop相关的goroutine退出
close(stop)
}
} func pprof3(stop <-chan struct{}) error { // 辅助服务,监听了其他端口,这里是 pprof 服务,用于 debug
err := server3(http.DefaultServeMux, ":8081", stop)
return err
} func app3(report *Reporter, stop <-chan struct{}) error { mux := http.NewServeMux()
mux.HandleFunc("/ping", func(w http.ResponseWriter, r *http.Request) {
// 在请求中异步调用
// 这里并没有满足一致性
go report.Report("ping pong")
fmt.Println("ping") _, err := w.Write([]byte("pong"))
if err != nil {
log.Println("response err")
}
}) return server3(mux, ":8080", stop)
} // 启动一个服务
func server3(handler http.Handler, addr string, stop <-chan struct{}) error { s := http.Server{
Handler: handler,
Addr: addr,
} // 这个 goroutine 控制退出,因为 stop channel 只要close 或者是写入数据,这里就会退出
go func() {
// 无缓冲channel等待,写入或者关闭
<-stop
log.Printf("server will exiting, addr: %s", addr)
// 此时 httpApi 服务就会优雅的退出
err := s.Shutdown(context.Background())
if err != nil {
log.Printf("server exiting occur error, %s", err.Error())
}
}() // 没有触发异常的化,会一直处于阻塞
return s.ListenAndServe()
}
  • 上面代码应该还有问题,等日后再做优化

第一种方法参考:reporter 添加shutdown方法

2. 总结

在使用go语言初期, 使用一个go关键字轻松开启一个异步协程,再加上chan很容易实现 生产者---》消费者 设计模型,但是在使用过程中往往忽略了 程序退出时资源回收的问题,也很容易写成一个数据使用一个go来处理,虽然官方说明了 创建一个goroutine的占用资源很小,但是再小的 占用空间也敌不过一个死循环啊。 所以在使用gorouine创建协程除了注意正确规定线程数以为,也要注意以下几点。

  1. 将是否异步调用的选择泉交给调用者, 不然很有可能使用者不知道所调用的函数立使用了go

  2. 如果要启动一个goroutine, 要对他负责

    • 不用启动一个无法控制他退出或者无法知道何时退出的goroutine
    • 启动goroutine时加上 panic recovery机制,避免服务直接不可用,可以使用如下代码
    // DeferRecover defer recover from panic.
    func DeferRecover(tag string, handlePanic func(error)) func() {
    return func() {
    if err := recover(); err != nil {
    log.Errorf("%s, recover from: %v\n%s\n", tag, err, debug.Stack())
    if handlePanic != nil {
    handlePanic(fmt.Errorf("%v", err))
    }
    }
    }
    } // WithRecover recover from panic.
    func WithRecover(tag string, f func(), handlePanic func(error)) {
    defer DeferRecover(tag, handlePanic)() f()
    } // Go is a wrapper of goroutine with recover.
    func Go(name string, f func(), handlePanic func(error)) {
    go WithRecover(fmt.Sprintf("goroutine %s", name), f, handlePanic)
    }
    • 造成 goroutine 泄漏的主要原因就是 goroutine 中造成了阻塞,并且没有外部手段控制它退出
  3. 尽量避免在请求中直接启动 goroutine 来处理问题,而应该通过启动 worker 来进行消费,这样可以避免由于请求量过大,而导致大量创建 goroutine 从而导致 oom,当然如果请求量本身非常小,那当我没说

3. 参考

  1. https://dave.cheney.net/practical-go/presentations/qcon-china.html
  2. https://lailin.xyz/post/go-training-week3-goroutine.html#总结
  3. https://www.ardanlabs.com/blog/2019/04/concurrency-trap-2-incomplete-work.html
  4. https://www.ardanlabs.com/blog/2014/01/concurrency-goroutines-and-gomaxprocs.html

Go并发编程--正确使用goroutine的更多相关文章

  1. 转: 【Java并发编程】之十八:第五篇中volatile意外问题的正确分析解答(含代码)

    转载请注明出处:http://blog.csdn.net/ns_code/article/details/17382679 在<Java并发编程学习笔记之五:volatile变量修饰符-意料之外 ...

  2. Golang并发编程优势与核心goroutine及注意细节

    Go语言为并发编程而内置的上层API基于CSP(communication sequential processes,顺序通信进程)模型.这就意味着显式锁都是可以避免的,比如资源竞争,比如多个进程同时 ...

  3. golang并发编程goroutine+channel(一)

    go语言的设计初衷除了在不影响程序性能的情况下减少复杂度,另一个目的是在当今互联网大量运算下,如何让程序的并发性能和代码可读性达到极致.go语言的并发关键词 "go" go dos ...

  4. Go中的并发编程和goroutine

    并发编程对于任何语言来说都不是一件简单的事情.Go在设计之初主打高并发,为使用者提供了goroutine,使用的方式虽然简单,但是用好却不是那么容易,我们一起来学习Go中的并发编程. 1. 并行和并发 ...

  5. Go part 8 并发编程,goroutine, channel

    并发 并发是指的多任务,并发编程含义比较广泛,包含多线程.多进程及分布式程序,这里记录的并发是属于多线程编程 Go 从语言层面上支持了并发的特性,通过 goroutine 来完成,goroutine ...

  6. Go并发编程实践

    前言 并发编程一直是Golang区别与其他语言的很大优势,也是实际工作场景中经常遇到的.近日笔者在组内分享了我们常见的并发场景,及代码示例,以期望大家能在遇到相同场景下,能快速的想到解决方案,或者是拿 ...

  7. 11 go并发编程-上

    其他编程语言并发编程的效果 并发编程可以让开发者实现并行的算法以及编写充分利用多核处理器和多核性能的程序.在当前大部分主流的编程语言里,如C,C++,java等,编写维护和调试并发程序相比单线程程序而 ...

  8. Go并发编程(四)

        并发基础   多进程  多线程 基于回调的非阻塞/异步IO     协程  协程  与传统的系统级线程和进程相比,协程的最大优势在于其“轻量级”,可以轻松创建上百万个而不会导致系统资源衰竭, ...

  9. Go语言 7 并发编程

    文章由作者马志国在博客园的原创,若转载请于明显处标记出处:http://www.cnblogs.com/mazg/ Go学习群:415660935 今天我们学习Go语言编程的第七章,并发编程.语言级别 ...

  10. Go并发编程

    概述 简而言之,所谓并发编程是指在一台处理器上"同时"处理多个任务. 随着硬件的发展,并发程序变得越来越重要.Web服务器会一次处理成千上万的请求.平板电脑和手机app在渲染用户画 ...

随机推荐

  1. 出现 cannot be resolved or is not a field 错误

    删除R.Java文件,这时,系统会重新生成一个R.java; 删除java代码中的"import Android.R"文件. 重新导入正确的包.

  2. spring 事务问题

    今天碰到一个奇怪的问题,在service中执行方法,调用了两次dao,前面是save,在save后面抛错,竟然没回滚,难道不是一个事务? 后来网上查资料,发现spring的事务回滚必须是运行时异常Ru ...

  3. java中进程与线程的三种实现方式

    一:进程与线程 概述:几乎任何的操作系统都支持运行多个任务,通常一个任务就是一个程序,而一个程序就是一个进程.当一个进程运行时,内部可能包括多个顺序执行流,每个顺序执行流就是一个线程. 进程:进程是指 ...

  4. Rest中的XML与JSON的序列化与反序列化

    #region 获取XML的序列化和反序列化 /// <summary> /// 对象进行序列化生成XML /// </summary> /// <typeparam n ...

  5. KEIL简单实例

    好久都没有用KEIL了,突然想动手,一时还真不知道从哪开始写,所以先弄个小实例,以便参考:#include <reg52.h>  //加载包括一个52标准内核的头文件,里面主要是一些寄存器 ...

  6. Android高效内存之让你的图片省内存

    Android高效内存之让你的图片省内存 在做内存优化的时候,我们发现除了解决内存泄露问题,剩下的就只有想办法减少真实的内存占用.而在App中,大部分内存可能被我们图片占用了,所以减少图片的内存占用可 ...

  7. 对Jquery中的ajax再封装,简化操作

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/ ...

  8. 使用bower init创建bower.json文件

    使用bower init 可以快速创建bower.json文件 bower init 回答一系列问题后就可以了,其中大部分问题可以按enter跳过.

  9. Hanlp中N最短路径分词详细介绍

    N-最短路径 是中科院分词工具NLPIR进行分词用到的一个重要算法,张华平.刘群老师在论文<基于N-最短路径方法的中文词语粗分模型>中做了比较详细的介绍.该算法算法基本思想很简单,就是给定 ...

  10. 在Ubuntu上更新Chrome到最新的版本

    本操作只限于已经安装了Chrome的Ubuntu系统: Step 1: sudo apt-get update Step 2: sudo apt-get install google-chrome-s ...